On Nov 20, 9:54 am, Gremlin <nilm...@googlemail.com> wrote:
> On 20 Nov., 08:56, Gadget/Steve <GadgetSt...@live.co.uk> wrote:
> > On 19/11/2011 12:52 PM, Gremlin wrote:
> > > Hello,
> > > well, the title says it already, how do I catch the ActivateEvent from
> > > a window that has been disabled?
> > > I want to accomplish that I am able to register if a user has tried to
> > > activate the toplevel frame so I can inform him that something is
> > > still processing and has to be finished first. To be exact, my
> > > application opens another application and the window from this one
> > > should act like a modal dialog.
> > > I did already the stuff to get this external window act like a modal
> > > dialog and also some sort of "workaround" for my initial question
> > > (panel freezed, disabled, etc), but now I ran into some difficulties
> > > with preventing the main frame from being minimized and maximized, so
> > > I hope someone can tell me if there is a possibility to disable the
> > > toplevel frame and still catching the ActivateEvents, which would
> > > extremely simplify the entire task...
> > > Best Regards
> > This sounds like you are doing things the hard way - by having something
> > on the screen that the user is not supposed to click on - some always
> > will and then will complain. Why not follow the more usual pattern of
> > displaying a progress from your top level form that always informs the
> > user that the other task is working and needs to finish - if you can
> > cancel the other task then I would include a cancel button on the
> > progress - possibly with a handler that pops up a modal are you sure
> > dialogue warning of the consequences of aborting the other task.
> > The reason that I suggest this is not just that is easier to do but also
> > it is more familiar to the users and most important it will avoid the
> > user frustrations in the cases where they start the other task and then
> > realise a) one of the inputs is wrong and needs to be changed or b) it
> > is going home time and they need to shut down the machine.
> > Gadget/Steve
> Hello Steve.
> Actually I already have such a display of progression, including a
> cancel button. The entire form is used for many purposes where the
> user has to wait, but most of the time he can still navigate through
> the rest of the application. The reason why I am going to do it the
> "unusual" way is that the third party application is doing some work
> that my own application needs to continue. Additionally the user does
> not know how this third party application is named, so if my
> application does not move it in the foreground how should the user
> know which application has to be closed? Sure, I could display this
> information somewhere in my form but, to be honest, I do not have much
> space left for this and it requires some "extra" effort from the user.
> (I try to keep the UI simple.) So I thought it would be good idea to
> design this like a standard modal dialog, so the user really sees that
> this "dialog" is mandatory to continue. I think that is a more direct
> way of notifying the user about the need to close the third party
> application, or really not?
> Best Regards
> PS: I am developing for Windows (xp, vista, 7), if someone has still
> an idea how to get this to work properly. 
Instead of completely disabling your window, maybe it would be better
to show the progress information (as you are doing), and just disable
the controls that would let the user do something that they're not
meant to? That way you can still process all the usual events and you
avoid having to work around the fact that you're doing things oddly.
Does the third-party app not close by itself when its task is
complete, or provide some way for your program to realise that (such
as outputting a message on stdout or stderr)?
