Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On 06/19/2011 06:48 AM, Tom Davies wrote:
Hi :)
Hopefully this is in Base rather than Calc.
Good guess...since I didn't exactly say. Sorry.
The 2 tables need to be connected
by some sort of relationship.
One would think. Yet, use of the Tools > Relationship functionality makes no difference at all to my results. I find that amazing. I guess Frieder got it right when he said that list boxes in LO simply supply contents, and NOT record keys. Not good, if true, although that IS what appears to be happening. It would also account for the non-persistence of my list box selection. A text field placed into an integer field should die a quick death, and it appears to be doing that. I THOUGHT I was getting the key field for the selected record. Not happening though.
I don't think spreadsheets work as relational
databases?
Agreed. Spreadsheets don't have record keys, so no relation is possible. They can be used as read-only data sources in LO, though, I believe. Haven't tried this yet.
One of the 'obvious' 'easy answers' (and therefore most commonly
missed)  is if the relationship is not defined in Base.
Well, it's not defined in Access either until done explicitly, and that is certainly possible also in Base. Doing this doesn't affect the problem at all, though.

The more I think about it, the more I become convinced that Frieder nailed it. I have to test this, but I think what's happening is that the list box selection I make simply produces the contents of the selected record. That shows up briefly in the text box, but cannot go from there to the record field underlying it, as THAT is an interger (to hold a key field's contents), and the list box selection is a text string.

OK...if so, then I need a macro to write the key of the selected record into the appropriate record field of my main table. oh, I'm not looking forward to this...I don't even know where to go to learn about LO Basic's object model, nor do I know where the language reference is. But if it's the only way then...

I'm afraid there NO documentation anywhere on this.

Thanks for your thoughts!

(and I'm still going to show up on the Base documentation list, probably tomorrow)

t.
It might be defined in
Access but it's worth checking that Base shows the same thing.

Thanks and regards from
Tom :)




________________________________
From: Frieder<delorfr@googlemail.com>
To: users@global.libreoffice.org
Sent: Sun, 19 June, 2011 12:53:44
Subject: Re: [libreoffice-users] List box not updating field with bound value

Am 19.06.2011 11:07, schrieb Tom Cloyd:
I know this is complicated, but I'll try to be simple and clear.

I'm building a form that displays a single record at a time from a table, as a
set of text boxes. The form displays all data in the table by moving
successively to each record. Every field except the primary key field can be
edited.

Are you using Calc or Base??
And do you automatic initialise the form ore do you use a macro to initialise
the form and fill it with contents?
I have a list box bound to one of the fields. It displays a field from another
table (which has only a key field and a data field - text). That table has only
a few records. It's sole purpose is to contain the list to be display in the
list box.

My intention is that selecting a value from the list box will cause the field
in the main table to be updated by the key of the record containing the selected
list item in the list table. That key is field #1 in that table, so my bound
value is 1.

The list is displaying perfectly. However, in the form, the field to which the
list box is bound displays nothing, ever. It DOES initially have a value, and
certainly should after I make a list box selection. It just never shows any
value, however. Moreover, looking at the main table's record outside of the form
shows that it contains only "0", regardless of which list item I select.

So...

1. Why is no value ever displayed in the form, even though there IS a value in
the record? In MS Access, it would show, I believe.
2, Why is the selected list item's key never updated into the master table
field. It IS bound, according to the property dialog.

It would bee much easier to help you if you put the document online, so
everybody can test it and see what is the best solution for your problem
1.There is a big difference between MS Listboxes and LO-Listboxes.
In MS you can address items in a list-box by there key number, in LO only by
there name.
2.You can connect a simple macro to the "list-box-change"  event that updates
the master table field.
I don't see my error, I'm afraid. Any suggestions would be appreciated.


I'm not sure, if my suggestion is really what you want.

-- 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


--
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.