|
Hi, I have a gui-related problem with a legacy-application, and
I ask for your advice. I have an applet-client, where client-server comm. might
take pretty long. Now, the communication doesn’t run on a separate
(worker-) thread, but on the main one, which makes unwanted clicks on the
buttons possible, without the user knowing it, as gui
is not updated till the comm. ends, because they are all on the main event
dispatching thread. As the gui isn’t updated,
the user might think, nothing has happened, and clicks again.And again. Unfortunately I am not allowed to disable all buttons,
fields, etc. as state-handling is not implemented, so after the comm. ends I
don’t know in which state I should update the gui
automatically. What I was thinking about as a solution to prevent
subsequent actions easily is to throw up a modal dialog telling the user that
the communication has started. Since it would be modal, user would not be able to click on
anything else till the modal dialog is open. Then, when comm. ends, it would make
the dialog disappear. The problem is the natural way of working of the modal dialog:
till it’s closed, code execution halted. Do you have any idea how could I throw up a “modal
something” which is not a dialog or achive the goal, so that: -
gui components should not be
disabled and -
user would not be able to send
actions (clicks, selection, whatever) and -
inform user of the
running communication. To summarize it, I think it would be a temporarily
non-responsive gui. We use jdk 1.3.1, so indeterminate progress bars and
monitors are not available and as far as I know, they are not modal anyway. Thanks for the help in advance, Peter You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk To unsubscribe from all mailing lists, click: http://sys-con.com/[EMAIL PROTECTED] |
