if a form is created from a table and then the table is added to, is not the form automatically updated with the added data? I have tried this and the form does not update itself
what am I doing wrong? advice please
Table to form
Table to form
if a form is created from a table and then the table is added to, is not the form automatically updated with the added data? I have tried this and the form does not update itself
what am I doing wrong? advice please
OOo 2.3.X on Mandriva + windows xp
Re: table to form
Form "Cuboids" in http://user.services.openoffice.org/en/ ... hp?id=1266 has a form (grey boxes) and a subform showing one value calculated from the main form (white box). Without writing any macros (adding some "spreadsheet functionality") to the form, you need to store the data to disk and then refresh the subform in order to let the subform re-read the data from disk. You can do this by means of the two buttons or by switching to another record (which writes to disk if required and possible) and then back to the changed one.
Please, edit this topic's initial post and add "[Solved]" to the subject line if your problem has been solved.
Ubuntu 18.04 with LibreOffice 6.0, latest OpenOffice and LibreOffice
Ubuntu 18.04 with LibreOffice 6.0, latest OpenOffice and LibreOffice
Re: table to form
thanks, but this is a bit complicated for me!! I guess the answer to my question is that the table and the form are not linked
so once I have created the form from the table the 2 become divorced - this seems a bit cumbersome to me, surely the 2 sets of data are related and should therefore synchronise with each other?
so once I have created the form from the table the 2 become divorced - this seems a bit cumbersome to me, surely the 2 sets of data are related and should therefore synchronise with each other?
OOo 2.3.X on Mandriva + windows xp
Re: Table to form
Don't guess, watch!
You can open any databse object in edit mode and for working. In edit mode you can design the object but you can't work with it. In working mode you can not manipulate the design or the way how it works but you can work with your data.
Note: Do not try to open a form twice (in edit and working mode). It's a known bug that the application goes in a limbo then. Close the opened view, then open again. No problem with tables and queries.
Open the working "Cuboids" form from my database in edit mode.
Get the "Form Design" toolbar.
Call the "Form Navigator" from that toolbar's 5th button
You see a hierarchy of objects.
One abstract container of forms, with one element I named "MainForm".
Rightclick "MainForm", "Properties", tab "Data". It is bound to the database's only table called "Table1". The binding gets lost when you rename that table.
The properties (tab "Data") of the grey boxes reflect the fields they are bound to. The binding gets lost when you rename that fields.
The names of the form with it's controls are independent from the names of the bound data fields. The visibly attached label-fields are independent as well.
In the design view of the underlying "Table1" you see that it consists of 5 fields:
- ID: a meaningless, automatically generated, unique number which makes up the primary key of that table.
- A name field
- 3 numeric dimensions
A table without primary key would not not editable (it lacks an distinguishable tag for the records). A form that is bound to an editable recordset is an editable form in principle (unless you decide to make the form itself read-only). So the form remains editable even if you would remove the grey ID-box (you can not edit and save the ID-number anyway, just give a try).
While in working mode You can edit all data in the grey controls, which are bound to the respective fields of the source table. The save-button ("Main form to disk") gets enabled, indicating that there are "dirty data" in the form. Once you push that button or switch to another record, the form tries to write those data into the database and the save-button becomes greyed out again. The single record behind the last existing record allows you to enter a new record (leave out the auto-id. Better: try out to set one, you will fail for various reasons). Notice the tools on the navigation toolbar where you can navigate, sort,and filter the recordset, store the current record, delete the current record and reset the current record to previously stored status (for instance if the update fails).
For now I leave out the explanation for the sub-form with the calculated field "Volume" (Length*Height*Width).
You can open any databse object in edit mode and for working. In edit mode you can design the object but you can't work with it. In working mode you can not manipulate the design or the way how it works but you can work with your data.
Note: Do not try to open a form twice (in edit and working mode). It's a known bug that the application goes in a limbo then. Close the opened view, then open again. No problem with tables and queries.
Open the working "Cuboids" form from my database in edit mode.
Get the "Form Design" toolbar.
Call the "Form Navigator" from that toolbar's 5th button
You see a hierarchy of objects.
One abstract container of forms, with one element I named "MainForm".
Rightclick "MainForm", "Properties", tab "Data". It is bound to the database's only table called "Table1". The binding gets lost when you rename that table.
The properties (tab "Data") of the grey boxes reflect the fields they are bound to. The binding gets lost when you rename that fields.
The names of the form with it's controls are independent from the names of the bound data fields. The visibly attached label-fields are independent as well.
In the design view of the underlying "Table1" you see that it consists of 5 fields:
- ID: a meaningless, automatically generated, unique number which makes up the primary key of that table.
- A name field
- 3 numeric dimensions
A table without primary key would not not editable (it lacks an distinguishable tag for the records). A form that is bound to an editable recordset is an editable form in principle (unless you decide to make the form itself read-only). So the form remains editable even if you would remove the grey ID-box (you can not edit and save the ID-number anyway, just give a try).
While in working mode You can edit all data in the grey controls, which are bound to the respective fields of the source table. The save-button ("Main form to disk") gets enabled, indicating that there are "dirty data" in the form. Once you push that button or switch to another record, the form tries to write those data into the database and the save-button becomes greyed out again. The single record behind the last existing record allows you to enter a new record (leave out the auto-id. Better: try out to set one, you will fail for various reasons). Notice the tools on the navigation toolbar where you can navigate, sort,and filter the recordset, store the current record, delete the current record and reset the current record to previously stored status (for instance if the update fails).
For now I leave out the explanation for the sub-form with the calculated field "Volume" (Length*Height*Width).
Please, edit this topic's initial post and add "[Solved]" to the subject line if your problem has been solved.
Ubuntu 18.04 with LibreOffice 6.0, latest OpenOffice and LibreOffice
Ubuntu 18.04 with LibreOffice 6.0, latest OpenOffice and LibreOffice
Re: Table to form
thanks, I've got it now, it worked, I updated the table and that was reflected in the form
now - when I first designed my form I chose not to display the ID field, so if I try to add a new record using the form view I cannot save it because the ID is not added - so how can I show the ID on my form, I tried to do this in Design mode but could not find how to display fields I had previously chosen not the display
OOo 2.3.X on Mandriva + windows xp