When I use:
Edit->Entry->Edit
or double click (both in table and tree view), I can
open the edit window only once. After closing it,
double clicking or activating the menu entry above does
nothing
This is not a regular behaviour! I surmise there is some
Exception thrown before you get to this behaviour.
Can you give more details about the environment you are
running in and what leads up to reproduce this error? Does it
always happen or only occasionally? - If you can get hold of
the console window output of the program, give a note whether
there is some error/exception text visible. Thanks!
- Wolfgang
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am running java 1.5.0_04 on Windows XP with SP2. 512 Mb of
memory.
It looks like the problem starts when you try to double
click on an entry. Using the menu works fine before your
first double click.
This is the exeception in the console:
C:\Documents and
Settings\hugob\Desktop\jpws-prog-0-1-0\jpws\bin>java -jar jpws.
jar
# JPWS-F INITIAL SEQUENCE ...
# JPWS-F start, 1124612856
- attempting OPTION FILE: C:\Documents and
Settings\hugob\jpws.ini
# Locale: ,
[jpws-b] log: (Global) Standard Application: Local Files
[jpws-b] log: (Global) Global initialized
# JPWS-F System initialized
Exception in thread "AWT-EventQueue-0"
java.lang.IllegalStateException: double e
dit attempt
at org.jpws.front.PwsFileContainer.editEntry(Unknown
Source)
at
org.jpws.front.PwsFileContainer$ViewportMouseAdapter.mouseClicked(Unk
nown Source)
at java.awt.AWTEventMulticaster.mouseClicked(Unknown
Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown
Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown
Source)
at
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown
Source)
at java.awt.EventDispatchThread.run(Unknown Source)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks for the input! I have found the problem. It arises if
you close an entry edit dialog by a shortcut-key (e.g. ALT-F4).
The program does not recognize this as termination and thinks
the dialog is still active. Therefore you cannot open a "second"
dialog.
To avoid the problem, please always close the dialogs by
using the buttons. I will try to correct this for the next release.
Thanks again, and keep on testing! ;)
- Wolfgang
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that the key to the problem is that your program
does not recognize the termination of the Edit dialog.
But I never used ALT-F4
I just did some tests: apart from ALT-F4, the behaviour is
also introduced by using the close window button. That is
the X button on the upper right corner. Many users will use
this button when they want get rid of a window.
Hugo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting observation! The point is that window widgets are
not present in every environment. I for one don't see any
closing decorations on my dialog windows. This is left to "look
& feel" organization.
I have arranged for a solution for all these cases. All "external"
user triggered window closings will be treated equivalent to
"Cancel" button, if one exists, or "Ok" button else.
This seems best solution. The alternative, namely to forbid
external closing, appears undue stress to users who are in
habit of closing by X button. This issue may get reviewed
again in the light of future experience.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=551242
This is not a regular behaviour! I surmise there is some
Exception thrown before you get to this behaviour.
Can you give more details about the environment you are
running in and what leads up to reproduce this error? Does it
always happen or only occasionally? - If you can get hold of
the console window output of the program, give a note whether
there is some error/exception text visible. Thanks!
- Wolfgang
Logged In: YES
user_id=1117076
I am running java 1.5.0_04 on Windows XP with SP2. 512 Mb of
memory.
It looks like the problem starts when you try to double
click on an entry. Using the menu works fine before your
first double click.
This is the exeception in the console:
C:\Documents and
Settings\hugob\Desktop\jpws-prog-0-1-0\jpws\bin>java -jar jpws.
jar
# JPWS-F INITIAL SEQUENCE ...
# JPWS-F start, 1124612856
- attempting OPTION FILE: C:\Documents and
Settings\hugob\jpws.ini
# Locale: ,
[jpws-b] log: (Global) Standard Application: Local Files
[jpws-b] log: (Global) Global initialized
# JPWS-F System initialized
Exception in thread "AWT-EventQueue-0"
java.lang.IllegalStateException: double e
dit attempt
at org.jpws.front.PwsFileContainer.editEntry(Unknown
Source)
at
org.jpws.front.PwsFileContainer$ViewportMouseAdapter.mouseClicked(Unk
nown Source)
at java.awt.AWTEventMulticaster.mouseClicked(Unknown
Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown
Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown
Source)
at
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown
Source)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown
Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Logged In: YES
user_id=551242
Many thanks for the input! I have found the problem. It arises if
you close an entry edit dialog by a shortcut-key (e.g. ALT-F4).
The program does not recognize this as termination and thinks
the dialog is still active. Therefore you cannot open a "second"
dialog.
To avoid the problem, please always close the dialogs by
using the buttons. I will try to correct this for the next release.
Thanks again, and keep on testing! ;)
- Wolfgang
Logged In: YES
user_id=1117076
I agree that the key to the problem is that your program
does not recognize the termination of the Edit dialog.
But I never used ALT-F4
I just did some tests: apart from ALT-F4, the behaviour is
also introduced by using the close window button. That is
the X button on the upper right corner. Many users will use
this button when they want get rid of a window.
Hugo
Logged In: YES
user_id=551242
Interesting observation! The point is that window widgets are
not present in every environment. I for one don't see any
closing decorations on my dialog windows. This is left to "look
& feel" organization.
I have arranged for a solution for all these cases. All "external"
user triggered window closings will be treated equivalent to
"Cancel" button, if one exists, or "Ok" button else.
This seems best solution. The alternative, namely to forbid
external closing, appears undue stress to users who are in
habit of closing by X button. This issue may get reviewed
again in the light of future experience.