On 06/23/2011 06:21 AM, Andreas Säger wrote:
Am 22.06.2011 09:59, Tom Cloyd wrote:
My list box disaster just don't quit.
To this point, I've learned that the only quick, simple way to get a
list box onto a form is to use the list box wizard. Last night it
worked. Tonight it worked. Then, it stopped.
I now have a form with 5 list boxes. Three have spontaneously, quite
without reason, disabled themselves. They passively display the value in
their source table pointed to by the key value in the linked main table
fie.d. BUT, the display is now a ghostly gray. I have had to change the
background color just to see it at all. They also no longer are a part
of the tab order and you cannot click into them at all. Also, the drop
down no longer works at all. It is now just a data display field, not a
list box. Worthless. I have poured over their properties for over an
hour, trying to find the problem. No luck.
Another formerly working list box appears still to work, but will not
update the main record field to which it is linked (this is the problem
I was having last night, before I started using only the wizard to make
list boxes).
Finally, I find that I can no longer CREATE functioning list boxes,
using the wizard, which puts me out of the list box business altogether.
I just rebooted, hoping it might help, but it didn't (small chance!).
You can download this troubled database for examination HERE
<http://www.tomcloyd.com/misc/storage_containers.zip>. Look at the
"storage containers > items" form.
You'll see that my subform is working fine, The three brown-background
list boxes are now duds. The "quadrant" list box appears to work but
actually does nothing to the main table. The "macro-container" list box
is recently created, and does exactly what the brown boxes do: nothing.
Any ideas, anyone?
This type of database uses to work very well for me, particularly the
list boxes use to work flawlessly.
Your relations appear somewhat messed up (at least unclear to me).
This may impose some difficulties entering valid data.
Each container is of one type, thus the 1-n relation.
Each of the items belongs to one container, but the form design
indicates that you want many of the same items distributed in
different containers. So you need a list of containers, a list of
items and an inventory list mapping many item-IDs to many
container-IDs. The mapping table constitutes the subform with a column
filled by list boxes so you fill many different items into the main
form's selected container (see my example file linked in the other post).
Each room belongs to one container, I think. But why does it share the
same foreign key with a location table? Is there a location (place) in
the room or is it the geographical location of the whole container?
The main cause of your list box problem is that your main form is
based on a view. Views are always read-only.
[Tutorial] Read-Only in Base :
http://user.services.openoffice.org/en/forum/viewtopic.php?f=83&t=26448
Base is very picky in this respect. But with the given tool set it is
always(?) possible to get a writable main form from one table and as
many writable subforms as needed so you can edit arbitrary complex
relations across table boundaries.
Andreas,
I am grateful for your post, which I encountered at a particularly
interesting time.
Considering the possibility that the suggestion made by someone else
that LO base had become corrupted (in other words, that regressions had
appeared) as a result of the transition from Open office to LibreOffice,
and that with no dedicated Base programmer on board with Libreoffice we
weren't likely to get a fix quickly, I just installed OpenOffice on
another computer, and verified that I COULD get a view to supply data to
a list box, as long as the main table involved was not a view. I took
this to be the behavior BEFORE the transition to LibreOffice.
I was preparing to have both LO and OO installed on all 3 of my
computers, and use the latter for Base work. Not an entirely happy prospect.
Then I saw your post, and verified that the behavior I just saw in OO is
also in LO: I CAN have sorted tables (views) supply data to list boxes,
as long as the underlying main form is a table, not a view. Sorted list
boxes are a necessity for my database applications.
So...I can now simply go ahead with using LO. A great relief.
Now the priority is to get the documentation to be specific as to how to
make this thing work. That said documentation did not so spell things
out was the cause of my great chase through the wilderness in recent
days. This need not have happened.
We don't need to fix the program - just the documentation.
Andreas, thanks again (and thanks too for all others who have stuck with
me through this journey).
Tom Cloyd, MS MA
tc@tomcloyd.com
(435) 272-3332
St. George/Cedar City, Utah
--
Unsubscribe instructions: E-mail to users+help@global.libreoffice.org
In case of problems unsubscribing, write to postmaster@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.