[jdjlist] RE: modal,but not dialog

[Greg Nudelman]

I know that might not be what you're looking for, but I hope this helps.    We had the same problem.  When the user clicks "Go" we start a fake progress bar so they know something is happening (ours is an HTML marquee) and we disable all the buttons except one, "Cancel" so the user can cancel out and try again (if the network is slow, whatever).   We found that disabling everything did not sit well with the users, and was not very practical for anything >30 seconds even in testing.   Greg -----Original Message----- From: mzperx [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 10:27 PM To: jdjlist Subject: [jdjlist] modal,but not dialog 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] --- 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]