MESSAGEBOX() with Timeout parameter

[Mike Lewis]

I just noticed something unexpected. If you do something like this:

MESSAGEBOX("Hello", 0, "My App", 10000)

(in other words, any messagebox with a timeout parameter), the message appears with its own button on the Windows taskbar.

Anyone else notice this, or is it something peculiar in my setup? Is it by design? Why?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Mike Gagnon]

Must be be design, although I cannot see the purpose, other than if everything is minimized, you would notice that the messagebox has kicked-in.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[Scott24x7]

Mike,
Yes, thre reason is to alert you that a message has "Come Up". You can also set a message as "SYSTEM MODAL" by including the value 4096 in the nDialogBoxType parameter, which is probably where this really comes from... Doing so forces the message box to the front of ANY application you have running on your system at the time.
I guess the intent of the separete taskbar entry is that it is assumed if you have a "Timeout" associated with an app, and you have something over the top of it, it assumes if you "notice" it you may want to proceed before the timer has completed... I have used this on a few occasions when I've given a 1 to 2 minute pause, though I typically do use it with the 4096 value, to make it modal, and force it to the front, but I can see how that could be considered "Intrusvie" programming, and in some cases should be avoided. This is more the "Gentle Reminder" type... in any case, I like it.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

I guess you're both right, but it seems a but curious.

Scott, you say that's it to show you that the message has come up, but I can't see why that should be relevant for messages with timeouts as opposed to any other kind -- although it's true you'd probably want them with a system modal message.

It's just one of those curious little quirks that makes VFP what it is.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

Mike,
Well, it does make sense to me... if you are away working on another program, and you have a message "come up", you don't have many "clues" that it has happened, unless you program some in (like a bell). At least this way, if you are watching for them, you know when the message box comes up, and it can alert you... I think its kind of a cool feature actually. If you wanted to do it otherwise, there'd be no capability to do so, and I see that with lots of things these days, like when an ICQ message comes in, if you are away, or not looking, it puts a flashing window alert in your task bar.
But yes, in general, I find timeouts best used with System Modal parameter, but if you want something that is less impact, and you don't care, then just a timeout will do, and processing goes on with or without you.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott,

I see your point. With a non-timeout message, you have plenty of time to switch back to the application and see the message; it will always be there until you dismiss it. But if the message has a timeout, you need to be sure to see it before it disappears.

You said, "If you wanted to do it otherwise, there'd be no capability to do so". You could, of course, use a VFP form, set to always on top and top-window, but of course that's a lot more effort than a simple message box.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[TamarGranor]

Scott - Just want to point out that from a UI point of view, system modal dialogs should be reserved for critical situations ("Unless you make nice right now, I'm going to crash and destroy all your data").

For an application to block the whole system just to give you a message is pretty rude. It's also not very helpful because it prevents you from checking other things on your system before you dismiss it.

I think very, very few VFP apps ever have a reason to use system modal. (I also think most VFP apps, and most apps in general, way overuse message boxes, but that's another conversation.)

Tamar

 

[Scott24x7]

Tamar,
While I agree that "Over messaging" is a common problem in applications, one of the beauties of the Timeout is at least it will keep going after a period of time. One thing you mention above though is not quite right...

For an application to block the whole system just to give you a message is pretty rude. It's also not very helpful because it prevents you from checking other things on your system before you dismiss it.

That's not actually how VFP handles this situation. System Modal simply forces the message window to an "Always on top state", and suspends your VFP processing, but does NOT stop you from doing anything else on your system. Do something like:

MESSAGEBOX('My Message',4096,'MESSAGE',1000000)

Now feel free to poke about your OS, and other appliations running... start Outlook, and press SEND/RECIEVE. You'll find all these things execute, but the message remains on top.

Again, I have VERY few applications of needing this... I use it when I want to do some BIG number crunching, but at intervals I want it to stop and ask me if I want to continue, so I can take a peek at the progress, and if it's running and I'm not around, after 90 seconds, it just keeps going. (I have some things that run for weeks, when doing heavy number analysis, and from time to time, its good to see how it's going). I sometimes run these in short segments so I can get some processing done... I use this method so I don't have screen updates taking place at intervals, and needing to use precious screen time to report back progress.



Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

As far as I can see, the "system modal" message box isn't really system modal at all. I take "system modal" to mean that you have to dismiss the messagebox before you can do anything else at all, anywhere in your system. As Scott points out, that isn't the case. In VFP, it appears to just means "always on top".

But, in any case, a system modal messagebox is not necessarily the same as a messagebox with a timeout. Despite what the Intellisense tip says, the two are not mutually inclusive.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

Mike,
Yes, for total clarity, the behavior is this:

Including a Timeout in the Timeout clause creates the instance of a "Window Bar" in the Windows task bar, but does not "Force it to the front". Using System Modal will Force it to the front, and create a Windows Task Bar item, regardless of inclusion of a TIMEOUT clause.

Now, if only there was some way we could make money off that...



Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[TamarGranor]

You guys are right. Since I don't use system modal, I hadn't looked at it in a long time. I see that in 32-bit Windows, it's not really system modal. (It was in Win3.1 when my impression of it was formed.)

Nonetheless, I'd use it pretty rarely. Scott, in your situation, it seems to me that a progress bar that updates very rarely (once an hour roughly) would be more useful. Then, you don't have to stop the process to see where you are.

Tamar

 

[Scott24x7]

Tamar,
Well, the % of the process complete is not what is of interest... I have used things like ? or MESSAGEBOX() (with a time out LOL!) to "Show" particular values. It's presence isn't based on time, rather some point in the process... 1,000,000 records, or 10,000,000 iterations, that kind of thing. It is then I use system modal, so that it pops to the front of what ever I'm doing, and if I'm not interested, I just click "No" (for continue processing, as opposed to "Yes" for stop processing). I suppose an SET ESCAPE ON and then forcing a MESSAGEBOX() from the command window would work too, but then I have to type, and remember what's what, and with a SUSPEND if record pointers get move accidentally... it gets ugly.

Anyway, certainly know what you mean by the Win3.1 I must admit, I was really surprised by its behavior when I noticed the "System Modal" description as well, and am glad that it works the way that it does...


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."