Why not use OnEvent code?

[vrocco]

Can one of you gurus explain to me why it seems hardly anyone uses the OnEvent code when writing GUI scripts?

To me it seems much easier to make something happen when a button is clicked than to constantly monitor the program state for something to happen. I understand doing this if you have no GUI.

Please understand, I am not knocking anyone's code. I am a n00b. I simply want to learn if I could be doing things better by not making all my code "OnEvent"

Thanks in advance for the explaination!

Vito

[big_daddy]

I personally prefer OnEvent over loops.

[Valuater]

I found at times when working with more than two GUI's on event can create problems. While loops ( as in more than one ) can be controlled to listen for specific messages

8)

[FreeFry]

I found at times when working with more than two GUI's on event can create problems. While loops ( as in more than one ) can be controlled to listen for specific messages

8)

Yeah, I agree with this, though imo. OnEvent mode is so much easier I'd almost always use it, even if I would have two GUI's

[PsaltyDS]

I prefer OnEventMode, too. All my older scripts that were coded with GuiGetMsg() loops are (slooowwly) being updated to use OnEventMode.

[Zacharot]

OnEvent is technically a 'better' way to handle many things, but I've found that it requires more code to determine the state of the program. I wouldnt want someone clicking stop>start>stop with my code still hanging somewhere in the middle. I have tried using OnEvent during databasing and the like, but find it's actually a lot Easier to just have the person wait till I'm ready for them, rather than the other way around.

[bhoar]

OnEvent is technically a 'better' way to handle many things, but I've found that it requires more code to determine the state of the program. I wouldnt want someone clicking stop>start>stop with my code still hanging somewhere in the middle. I have tried using OnEvent during databasing and the like, but find it's actually a lot Easier to just have the person wait till I'm ready for them, rather than the other way around.

I had some of the same concerns and thought that an event queue might be the best way to handle it. Each event gets put into a queue by *every* OnEvent handler, then the events are processed serially. Perhaps certain events would clear the queue (e.g. a STOP or CANCEL button or key combo) before being placed in the queue themselves?

-brendan

[FreeFry]

OnEvent is technically a 'better' way to handle many things, but I've found that it requires more code to determine the state of the program. I wouldnt want someone clicking stop>start>stop with my code still hanging somewhere in the middle. I have tried using OnEvent during databasing and the like, but find it's actually a lot Easier to just have the person wait till I'm ready for them, rather than the other way around.

That's an excellent example of a case where message polling(GuiGetMsg()) is better than the OnEvent mode!

Edit:

I mostly use OnEvent mode whenever I create a progam that has a GUI, that's supposed to do something else than handling the GUI, but at the same time I want it to respond to a users request to, for example, quit the script.

Edited June 21, 2007 by FreeFry