I have a couple of forms where I display a list view form, with more than one field stacked vertically via a tabpanel. All of the fields are of the type combobox and have list attached to them.
If the drop down is selected at the same time a new record is created the list persist. Switching to a new form the list will still sit in front of the application or at times this part of the screen will just appear greyed out. The only way to get rid of the list is to close and re-open the application. Some of my users are having to do this 3-10 times daily. It is a major problem with the interface!!! This problem has been present at least since version 2.2.1.
John McCann
Windows XP
Windows Server 2003
Java 1.4.x
Here is a sample solution showing the problem. I have included the mini-database containing enough information to replicate the problem. The problem only manifests itself when a portal is also on the page. The problem seems to lie in the fact that the focused record is changing at the same time, and some level of confusion is introduced. If I first select the record by clicking on the grey area, it does not happen. Note that the data does not matter, nor is the relation I’ve provided meaningful. It is all just to get these elements on the same page. If the portal is not present, the problem does not occur.
Instructions to replicate problem:
Run and load the StickyBox solution.
There should be three records available on the page, and several drop downs using the database as their value list.
Click on the bottom record entry, on the left most combo box arrow on the top of the row, of the database record list view. Select any value, it does not matter.
Next click on the top list view entry, on the middle combo box arrow of the record list view.
The leftmost drop down will be displayed instead of the middle one and will now never go away. Even if you are running in designer and switch to design view. The only option is to close Servoy completely.
So right now I can see no way around this. Adding requestFocus() commands and such makes the problem far worse, not better in any way.
This occurs on 2.2.2, 2.2.3, and 2.2.4 as tested by myself.
i can’t reproduce sticky behaviour at my place.
Also the behaviour you describe doesn’t happen with me
If i click first on the left most top row combo of the last record
then on the middle combo (on the top row) of the first record
The large combo of the bottom row of the first record is collapse
instead of the middel combo.
When i click for a second time on the middle combo of the top row of the first record then the large bottom row collapses and the right combo list pops up.
I switched all of the problematic comboboxes to not editable and it resolves the problem. I am still able to edit the boxes when they are set to not editable as has been mentioned previosly on the forum. Thanks for giving me a work around.
which post is that? Can you still TYPE into the combobox? Is it still an textfield?
I think i have a fix for you problem, at least i hope it also fixes the thing you see because it does fix my problem i see with the list but that is not exactly what you see.
I also noted the work around does not really work. It gets rid of the sticky box problem but setting a combobox to not editable prevents users from typing data into the combobox if they do not desire anything in the picklist. This is appropriate behavior but prevents the workaround from working in many conditions.
Have you tried running it under Java 1.4.2? I’ve tried the same script on the above solution using the new jars, and it does indeed fix it. But, if you switch the second step to utilize the middle row of records, and the middle combo box, the box again sticks and will not go away.
Do you need any help with this somemore?
I couldn’t reproduce it at all even under 1.4 with the sample solution you did give me.
But i can give it another shot.
The best thing would be in the case to upgrade to java 5 because it does seem to be a problem in the java 1.4 code base.
This is strange because we have not problem reproducing it with Java 1.4 I agree that the problem goes away in Java 5. We have upgraded to Java 5 but are having probems because the file plug in does not reliably delete files. I have a post on this for many many months. Can you fix the problem with deleting files so that Java 5 can work for us? Everything else about Java 5 seems great. It looks better and it runs faster but the file plug in does not reliably delete files.
That focus problem really seems to be a bug of 1.4 that is fixed in 1.5. The only thing is if you want ediable dropdowns then you could use the TypeAhead field for this if you want to use 1.4. Because this one has our own list and focus handling.
I fixed the problem with file deletes (after you read them) that is a bug in 1.5 and or windows that sun won’t or can’t? fix. I worked around it by not using the specific methods that has that problem under windows.
This fix will be in 2.2.5 and the the next beta of 3.0.