messagebox with timeout weirdness

Do this:

MESSAGEBOX('message',16,'title',100000)

Which causes a messagebox to be displayed with a 100 second timeout.
Look at your taskbar, notice the extra icon on it. It has a fox icon,
and it's caption is the title of your messagebox. Now click on the VFP
desktop wihle the messagebox is still displayed. Notice that the
messagebox is no longer visible because it is now behind VFP. You
can't do anything in VFP while the messagebox is active - but you
can't see the messagebox either.

So, my question - how can I use messagebox with a timeout and prevent
it from being hidden by my app? If you don't use the timeout
parameter, it works as expected. If you use the timeout parameter, it
can be hidden by the app, the user does not see it, their app is non-
responsive, and the next thing you know you have data losses because
they alt-ctrl-del and killed the app because they didn't notice the
message box hiding behind the app.

This appears to be how messageboxes have worked since VFP7, but I've
never had the need to use the timeout parameter until now. Making the
current form or _screen modal doesn't change this.

Dan
Fri Dec 21 12:33:46 CST 2007

Add 4096 to the 2nd parameter. That makes the MessageBox() "system modal" --
it'll be on top of everything.

Dan

Ook wrote:
> Do this:
>
> MESSAGEBOX('message',16,'title',100000)
>
> Which causes a messagebox to be displayed with a 100 second timeout.
> Look at your taskbar, notice the extra icon on it. It has a fox icon,
> and it's caption is the title of your messagebox. Now click on the VFP
> desktop wihle the messagebox is still displayed. Notice that the
> messagebox is no longer visible because it is now behind VFP. You
> can't do anything in VFP while the messagebox is active - but you
> can't see the messagebox either.
>
> So, my question - how can I use messagebox with a timeout and prevent
> it from being hidden by my app? If you don't use the timeout
> parameter, it works as expected. If you use the timeout parameter, it
> can be hidden by the app, the user does not see it, their app is non-
> responsive, and the next thing you know you have data losses because
> they alt-ctrl-del and killed the app because they didn't notice the
> message box hiding behind the app.
>
> This appears to be how messageboxes have worked since VFP7, but I've
> never had the need to use the timeout parameter until now. Making the
> current form or _screen modal doesn't change this.

Ook
Fri Dec 21 13:23:03 CST 2007

Yup, that works, thanks Dan :). It still appears to be it's own top
level window, with a seperate icon, etc., but at least it doesn't hide
behind the main app.

Gotta wonder why Microsoft did it this way - was it that hard to make
the messagebox function work with a timeout without making it it's own
top level window? I don't think the Windows messagebox api supports a
timeout, so I'm guessing they have it like this so that some timer
runs in the main VFP app window that hooks into the msgbox window, and
terminates it when the time expires. If they left the timeout code in
the main VFP window, it would not run, and would not terminate the
messagebox. So they kluged it instead of figuring out how to make it
function the same as a messagebox with no timeout. <shrug>



On Dec 21, 10:33 am, "Dan Freeman" <s...@microsoft.com> wrote:
> Add 4096 to the 2nd parameter. That makes the MessageBox() "system modal" --
> it'll be on top of everything.
>
> Dan
>
> Ook wrote:
> > Do this:
>
> > MESSAGEBOX('message',16,'title',100000)
>
> > Which causes a messagebox to be displayed with a 100 second timeout.
> > Look at your taskbar, notice the extra icon on it. It has a fox icon,
> > and it's caption is the title of your messagebox. Now click on the VFP
> > desktop wihle the messagebox is still displayed. Notice that the
> > messagebox is no longer visible because it is now behind VFP. You
> > can't do anything in VFP while the messagebox is active - but you
> > can't see the messagebox either.
>
> > So, my question - how can I use messagebox with a timeout and prevent
> > it from being hidden by my app? If you don't use the timeout
> > parameter, it works as expected. If you use the timeout parameter, it
> > can be hidden by the app, the user does not see it, their app is non-
> > responsive, and the next thing you know you have data losses because
> > they alt-ctrl-del and killed the app because they didn't notice the
> > message box hiding behind the app.
>
> > This appears to be how messageboxes have worked since VFP7, but I've
> > never had the need to use the timeout parameter until now. Making the
> > current form or _screen modal doesn't change this.

Dan
Fri Dec 21 13:30:17 CST 2007

It's not a feature I use. To me, MessageBox is to give the user a message
they *must* see and/or respond to so a timeout doesn't make any sense. If
it's optional that they see/respond, why put it up in the first place? ;-)

Dan

Ook wrote:
> Yup, that works, thanks Dan :). It still appears to be it's own top
> level window, with a seperate icon, etc., but at least it doesn't hide
> behind the main app.
>
> Gotta wonder why Microsoft did it this way - was it that hard to make
> the messagebox function work with a timeout without making it it's own
> top level window? I don't think the Windows messagebox api supports a
> timeout, so I'm guessing they have it like this so that some timer
> runs in the main VFP app window that hooks into the msgbox window, and
> terminates it when the time expires. If they left the timeout code in
> the main VFP window, it would not run, and would not terminate the
> messagebox. So they kluged it instead of figuring out how to make it
> function the same as a messagebox with no timeout. <shrug>
>
>
>
> On Dec 21, 10:33 am, "Dan Freeman" <s...@microsoft.com> wrote:
>> Add 4096 to the 2nd parameter. That makes the MessageBox() "system
>> modal" -- it'll be on top of everything.

Ook
Fri Dec 21 13:57:51 CST 2007

I've never used timing out message boxes before, I've just never
needed them. However, the requirements for this particular app is that
a messagebox appear at certain intervals telling the user how much
time before certain events occur. After a certain amount of time, I
have to update the time left. So, we 1) have to give the user a
message that they have to acknowledge sooner or later and 2) The
message changes periodically while waiting for them to acknowledge it.
My first choice was to use a messagebox, timeout and close, update
message, and call messagebox again. This would have worked perfectly
if not for the funky behavior of messagebox when you use a timeout.

I ended up using my own home-rolled message box function, with timeout
- got the job done, didn't take too much time to code it.

Thomas
Sat Dec 22 07:35:32 CST 2007

> However, the requirements for this particular app is that
> a messagebox appear at certain intervals telling the user how much
> time before certain events occur. After a certain amount of time, I
> have to update the time left. So, we 1) have to give the user a
> message that they have to acknowledge sooner or later and 2) The
> message changes periodically while waiting for them to acknowledge it.

Sounds a bit like the half automatic kick out function I had to write a
couple of years ago needing to run before data was exchanged with big
iron updates.

If a user was present he was told to save his work and and certain
cutoffpoints first unaltered data screens were released, later even
those with data changes - these were thrown away and the systems across
the network closed down.

From what I interpret you seem to be working in a loop - I went with a
timer based approach showing the current status in a wait wind nowait
noclear leaving each thread clear to work on something else if the
operator was not manually closing things down.

my 0.02 EUR

thomas

Cy
Mon Dec 24 15:52:28 CST 2007

Ook wrote:
> I've never used timing out message boxes before, I've just never
> needed them. However, the requirements for this particular app is that
> a messagebox appear at certain intervals telling the user how much
> time before certain events occur. After a certain amount of time, I
> have to update the time left. So, we 1) have to give the user a
> message that they have to acknowledge sooner or later and 2) The
> message changes periodically while waiting for them to acknowledge it.
> My first choice was to use a messagebox, timeout and close, update
> message, and call messagebox again. This would have worked perfectly
> if not for the funky behavior of messagebox when you use a timeout.
>
> I ended up using my own home-rolled message box function, with timeout
> - got the job done, didn't take too much time to code it.
Why use a timeout on the messagebox (the one you rolled) when you could
just use your screen and have a timer to updated it's contents as long
as it's still up until the user inputs.

--
Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com