Apache OpenOffice (AOO) Bugzilla – Issue 109081
Drop down menus do not display values/erase on focus
Last modified: 2017-05-20 10:24:10 UTC
When using a form in Base (OOo 3.2 RC5, but this bug also appears in all prior release candidates for 3.2) the values of dropdown menus are not shown after focuc is removed. Further, when focus is first put onto one of these menus, the value is apparently set to null until a new selection is made. This means that if you tab from field to field, you literally erase the value of each dropdown field to which you tab. In the database I am using, the field values are drawn from tables. The syntax in the LIST CONTENT field looks like this for one such field: SELECT "CaseType", "ID" FROM "CaseTypes" "CaseTypes" It looks like this for another: select "DispDesc", "ID" from "DispositionTypes" Both work perfectly well in OOo 3.1 (i.e., the values are always shown and they are not reset as soon as you tab onto the field) but create the problems described above in OOo 3.2.
Could not reproduce using Ubuntu, 3.2_RC5, embedded database w/ check on xp to be sure @steven This is an embedded database or a mysql?
It's neither. It's a HSQL database using the Java connector. I do have an embedded version, but I haven't tried that one in OOo 3.2 RC5 yet. I'll try to remember to do so when I'm back in the office tomorrow.
Checked it this morning with the embedded version of the same database, and I get the same problem. This is on a Windows XP SP3 box. I also confirmed that both versions of the database work just peachy in OOo 3.1 and in StarOffice 8.
Checked with XP (sp3), 3.2 RC5 I can not reproduce this problem with list box or combo box controls.
I've been trying to attach the embedded version of the file, and it seems to be too big. Would it help if I uploaded it to my server and provided a hyperlink?
If there is no confidential data in it, sure - or - you can send the link to my direct email address.
I'm uploading it now to here: http://www.sheltonlegal.net/OOoLawLaw/ I took all of the confidential data out. You can specifically see the problem on the CASE DETAILS form. If you look at the Disposition, Type of Case, and Referral Source fields in OOo 3.1, they work fine. However, what I consistently get in OOo 3.2 is that the values revert to NULL when the field is taken out of focus. (The same happens on the CLIENT DETAILS form under the client name.) If you scroll down to the Litigation section of the CASE DETAILS form, however, you'll see that the court designations work fine. The difference is (and this seems consistent throughout) that the court designation is selected from a list contained within the menu itself (right-click > CONTROL) whereas the fields experiencing the problems have their options drawn from another table. So the problem seems to involve dropdown menus where the options are populated from tables within the database. Again: works fine in SO8 and OOo 3.1. Driving me insane in OOo 3.2!
Created attachment 67754 [details] Sample file showing OOo 3.2 form bug
well yes I see it now and it looks like http://www.openoffice.org/issues/show_bug.cgi?id=106643 Which is supposedly fixed in 3.2 final. Come to think of it I checked earlier my files had all been created under 3.2 - will try another older file and see.
I have the same problem, running OOo 3.2 RC5. I have a form which feeds a table control based upon two dropdown list boxes, one for year and one for month. This worked perfectly until I upgraded to 3.2 a few days ago.
Checking some other files it seems that some listboxes work properly and some don't - assigning to developer set initial target
phhh .... that's a somewhat strange setup here: CaseInfo.CaseNature is of type VARCHAR. Nonetheless, it seems to contain numeric values, which are expected to match CaseTypes.ID, which in turn is an INTEGER field. So, what the respective list box in the "Case Details" form is asked for is to match the *string value* in CaseInfo.CaseNature with the *numeric value* in CaseTypes.ID. This indeed worked in OOo 3.1.1, since list boxes where more type-tolerant there. However, because of this tolerance they had other problems, for instance the mentioned issue 106643. I need to investigate this in more detail, whether this can reasonably fixed without re-introducing other bugs.
fixed in CWS dba321a find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba321a
So it look like this is sloppy code on my end (which I have no qualms with; I'm a completely noob to database design) and it appears that this is probably something that will eventually break again in a future update when it becomes necessary for the forms to require stricter compliance. Out of curiosity: what would be the proper way to "fix" the file so that it would be technically correct and work in a strict-compliance type environment?
Steven - sent you a direct email regarding this.
ah - didn't mean to close that..doesn't look like there is anyway to undue that, so just leave it I suppose.
re-opening, since the closing was in error
back to FIXED
*** Issue 110274 has been marked as a duplicate of this issue. ***
fs->msc: please verify in CWS dba321a
verified in CWS dba321a find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fdba321a
Not fixed in the March 26 2010 build of OOO320_m14. Downloaded and installed, and exhibits the same problem. The EIS doesn't tell me which build this is integrated into; if it was supposed to be the March 26 build, this bug needs to be re-opened.
@steven - right, the EIS does not show it as being integrated to the main code line yet - so it would not have been in that dev snapshot build. There is another one being done later this week, I don't know but I wouldn't bet on this being in that either.