Messagebox for a specific time, asynchrony 1

[sashaDG]

Good afternoon everyone. There is a situation when I copy data to excel using SCAN. Question: How can I do, for example, at the beginning of the MESSAGEBOX with the message ("Data transfer has begun") and so that it closes when the SCAN ends.
I guess it's called async?

 

[Chris Miller]

You have WAIT WINDOW "Message" NOWAIT to do what you want. And WAIT CLEAR at the end. The message will display as a small simple window (no titlebar etc.) near the upper right corner of the screen. The other natural place for status messages is the statusbar at the bottom of the display. Provided you don't turn it off SET MESSAGE sets what it displays.

You can't do the same with the Messagebox. The Messagebox will wait for a user reaction. In part because you can choose more than just the OK button as reaction and the further code could branch depending on the choice.

Chriss

 

[Mike Lewis]

A message box is not the appropriate mechanism to use here, partly for the reason that Chris has explained, but also because it might be considered too intrusive: it dominates the screen, partly hiding what is underneath, and possibly confusing the user because it appears to require a button click to close.

Although a Wait window is a better choice, my preference would be to display the message on the same form that launched the process. Presumably you have a form which lets the user initiate the copying. I would add a label to that form; initially set its Visible to .F. When the process starts, set its Caption to the required message, and its Visible to .T. When the process has finished, set its Visible back to .F.

This has the advantage of being easily visible without being intrusive. It also lets you update the message as the transfer progresses, for example so that you can tell the user what percent of the process is complete.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I agree, this is another idea. Especially since both the wait window and the statusbar text are small/normal sized texts. Status bar texts are a more general standard, WAIT WINDOW messages are only commonly known to people used to FoxPro applications.

But indeed Mike has almost made the point about the messagebox I forgot to mention: Even using the Common Dialogs standard MsgBox, this is a modal dialog that stops until the user reacts, it's not the common ground vehicle for status messages, though there are the standard icons that go from information icon to stop sign for severity levels of the message, also the information messages won't run asynchronous. VFP has introduced a timeout to enable continuing if the user does not react, but using that the MessageBox just assumes the default response after the timeout. If you set the timeout very low, you can continue fast, but the user won't be able to read the message.

As On the other demand for a larger text font I also recommended what's possible instead: You can esily make up a form yourself, that displays non-modal in your case and thus your processing can continue and you can release that form when the process is done. If you want to go by standards you should choose the status bar mechanism, and furthermore, it would be common to display a progresss bar that is normally quite large and noticeable without that being obstrusive, as you can still bring other windows on top or move that progress bar away. Internet browsers also show progress typically in the upper right or lower left, not only big and central.

Chriss

 

[Manuch]

Please read all they have written and listen to them before reading my reply.

Just for knowledge, if you want to close a MESSAGEBOX after x milliseconds are passed the fourth argument

MESSAGEBOX(eMessageText [, nDialogBoxType ][, cTitleBarText][, nTimeout])

will make your messagebox disappear after this number of ms, but please as they pointed out don't use a messagebox for your case, you can't even know how much time your SCAN will take and also it would be blocky and messy, as they pointed out in wiser words.

 

[Mike Lewis]

Manuch clearly agrees with us about the use of MessageBox() in this situation.

Regarding the nTimeout parameter: I note that Manuch is not recommending you to use that, which is good. But I would go further, and argue that you should never use a timeout with a message box, for the following reasons:

1. When you use the timeout parameter, the message box opens with a separate button on the Windows taskbar. If the user then clicks anywhere else in your application, the application's window will come to the front, hiding the message box. But the message box is still active at this point, and the application is still in a modal state. So if the user doesn't realise what is happening, they will assume the application has frozen.

2. When a message box with a timeout is active, any timers in your application will fail to fire.

3. Most importantly, it's a lousy user interface. You're saying to your user: "Here's some important information you need to read. Oops. Too late. You didn't read it in time, so I'm going to take it away." It's not exactly going to endear you to your users.

As far as I remember, the only time I have ever used a timeout with a messagegox is when the program needed to force a user out of the system when they left it running overnight and the admin needed to close it down so that they could get exclusive use. Even then, a custom form with a timer might have been a better option.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[sashaDG]

Thanks for the extensive answers

 

[Chris Miller]

Mike, it's good to know that a MessageBox with a Timeout stops all timers from working. I didn't realize it.

A Messagebox without a Timeout parameter does not stop timer events to happen. And that could be used as the poor man's emulation of parallel threads. Timers never really run in parallel, they interrupt code, so you still only have one main thread that runs.

But with or without a messagebox, a timer can of course process "slices" of something. However you partition it, say one record per timer event. It won't give any good performance, even if you minimize the timer interval, you mainly just reduce the performance of the main application code. The only way to do processing with a timer in a decent manner is balance what you do within one timer event so that it don't become blocking the responsiveness of the rest of the application. And it's no good idea to do background tasks that way. For something done in parallel the easiest way is to put it into a separate exe and run that, as that can really run in parallel. It just won't work within your main session and its _screen and forms, it's then a completely separate process. You just have to start it so you don't wait for it to end, RUN will wait, RUN /N will not, and then there are a lot of further ways to start another exe with ShellExecute and other Windows API functions.

Chriss

 

[Mike Lewis]

Yes, I agree with that, Chris. In the past, I've considered using timers to achieve a degree of parallel processing, but decided it wouldn't give enough benefit. But I have successfully used a separate EXE for background tasks (with no user interface), including communicating with the main program via DBF reads and writes. I was pleasantly surprised at how good the performance was.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads