On Windows XP SP 3, in a Swing database application (Eclipselink 2., Oracle jdbc) I call a method that creates a thread at the end of my populateAll() method to hold down the Control key and tap the SPACE BAR twice. This fires the "toggleAndAnchor" of a single column JTable containing a list of names, to repeat the JPA queries that loaded all the tables linked to the names. From a JPA perspective, it's unpredictable how many of the 16 tables will load as each name is selected (the real problem), but pressing control space first to deselect a row, and again to reselect it populates ALL the tables as expected(by rerunning all the queries again, no cache). The JTables populated, one after the other, are made from JPA TypedQuery List<E> results mapped to a JTable using BeansBinding 1.2.1 - They are in JXTaskPanes within JXTaskPaneContainers, and sometimes JSplitPanes.
e.g. See a simple example here:
Beans Binding Via The Road Less Travelled By (Part 1)
By Geertjan on Feb 11, 2008
except that BindingGroup is not used (provided byJTableBinding) and my JTables are reused (by unbind()), change the List, then bind()
For now I just want to get this workaround stable enough for a production application. So far, it works, but (1) seriously degrades performance (2) prevents scrolling backward through the name list, and (3) lingers after the application has closed (as though the same keystrokes were being applied to everything in Windows afterwards). Here's the code for the workaround:
Am I missing any shutdown needed by Robot? Is there a bug that leaves events in a Windows queue that should be removed?
Any suggestions welcome.
On the JPA side, has anyone had a problem of too many tables to load at once?
Is this what you had in mind? The first thing I tried (varying the target object), but it never did exactly what the manual keystrokes did. Essentially, it was always as though I had never used the Control+SPACE at all, though you could see it happening, it had no effect in the end; in some cases the GUI became unstable, or looping rapidly between two states "fibrillation!"