Apache OpenOffice (AOO) Bugzilla – Issue 6235
Data source form - highlight fails to display field contents
Last modified: 2006-05-31 14:29:06 UTC
OOo 1.0 on Win98 Created a small dBase-5 table (in Corel Paradox v9) with a char(56) field; added sequential items 01 through 20. Also exported the data to a CSV file and imported to a mysql table with a char(56) field. In OOo, made data sources and used File > AutoPilot > Form to make forms for each table. When either mouse or arrow keys are used to move the highlight from record to record in the form, the highlight does not always display the current field contents correctly. E.g., items 14-20 actually look like this: item-14-+-123456789-123456789 item-15-+-123456789-123456789- item-16-+-123456789-123456789-1 item-17-+-123456789-123456789-12 item-18-+-123456789-123456789-123 item-19-+-123456789-123456789-1234 item-20-+-123456789-123456789-12345 but display like this when the cursor is moved down from item 14 to item 19: item-14-+-123456789-123456789 item-15-+-123456789-123456789- item-16-+-123456789-123456789-1 item-17-+-123456789-123456789-12 item-18-+-123456789-123456789-123 item-15-+-123456789-123456789- (highlighted) item-20-+-123456789-123456789-12345 See attached screenshot.
Created attachment 2130 [details] Data source form - highlight fails to display field contents correctly
Daniel, can you supply the dBase file as attachement here? Would spare me some time creating it manually :). Thanks. Frank
Created attachment 2185 [details] highlight in form does not display field contents correctly
This may be related: <message> 5407 on the users list: Changing a field in database (db) 2002-07-11 http://www.openoffice.org/servlets/ReadMsg?msgId=354222&listName=users ... when I try to type in, or paste in, past 30 characters it will not allow me to do so. It stops at 30 characters (for new data entries). I have nearly 1500 entries but am dead in the water as far as adding new data. </message> (I noticed this message because it was exactly at 30 characters that the highlight began to fail to display field contents correctly.)
I think I know what's going. When you create a table-like form with the auto pilot, it creates a control with a text column for your text field, and it sets the max text length to 30. You both may check this: Open the form, press the "Edit File" button in the function bar (if necessary). If the form is still loaded (i.e. if you still see your data), go to the form toolbar ("Form Function" in the left-hand-side toolbar), and therein, switch on the design mode ("Design Mode On/Off"). You now are in a mode where you could potentially change your form .... Select the column of your text (it is painted like it is pressed down then). In it's context menu, select "column". This should give you a pop up window with the column's properties (the so-called property browser). There you see a line labeled "Max. text length". The value there is 30 - this is what you need to change. You may set it to 0 - this means the value from your dBase table's column (56) is used. You may set it to -1, then there is no limit. Both solutions should solve your problem. Daniel, can you please try this? If you can confirm that this is the problem, the I would assign this bug to the man who is responsible for the auto pilot. Frank
Thanks. Tried both 0 and -1 in both forms for dBase and for MySQL tables. That fixes the problem. Maybe zero should be the default for that property. (-1 would, wrongly, allow me enter data that would not fit in the column.) I would like the form to adjust automatically if I change the size of a column in the database table, which I would do using outside software (Paradox v9 in my case for dBase and MySQL-Gui for MySQL).
When the max_text_length is set to zero, the form correctly picks up the fact that I changed the size of the column in the dBase table from char(56) to char(51) (using Paradox). (Also, the form correctly limits data entry to 51 characters.) However, the zero value in max_text_length sometimes reverts to the actual size of the column (hard to reproduce). E.g., 56 appeared in the max_text_length slot in the column dialog box instead of zero; and after I changed the column size to 51, and set max_text_length to 0, a 51 appeared there the next time I opened the form. This would prevent the form from detecting future changes in the size of the column in the dBase table. The value of max_text_length should remain at zero after I set it to zero.
Dan, thanks for confirming the 0 and -1. I assign this issue to Berend Cornelius, he is responsible for the AutoPilot. Berend, I think Dans suggestion does make sense: when creating text fields, you should set the MaxTextLengt property to 0. Dan, for the wrong reset of the property: You indeed found another error here, thanks. Beeing pointed to it by you, I could confirm and reproduce it (after suspecting it, it wasn't that difficult as I know what's going on internally :), and I filed an issue for this: issue 6434. Frank
assigning to Berend
Fixed in 644d
fixed in the next version
close
re-opening. According to http://www.openoffice.org/issues/bug_status.html, a bug has to be closed when the version where it's fixed is _shipped_, which is not yet the case here.
resolved fixed, but not yet closed.
set target
fixed in public 644 m build see http://www.openoffice.org/dev_docs/source/644/
change subcomponent to 'none'