Messagebox disables my Textbox unless I click away from VCX and back. 1

[dantheinfoman]

Hi All,

My first post. I have a .vcx form where if the user clicks the "Save As New" button, they need to have put a name for the new record in the Textbox. If the textbox is empty, it tells them that they need to put something in there and it should go straight to that textbox. What it does instead is nothing after the messagebox closes. In fact, you can't click in or type in the text box unless you click on the main exe program's screen and click back into the form. Then it's happy again!

my offending code below:

WITH THISFORM
	
	IF EMPTY(.TBMyRpt.Text) THEN
		*WAIT WINDOW "Please choose a name for your report in the textbox!" nowait
		MESSAGEBOX("Please choose a name for your report in the textbox!", 4096)
		.Refresh
		.tbmyRpt.SetFocus
		RETURN		
	ENDIF
	
        ***blah blah other stuff here
        *********
ENDWITH

I had success with the wait window, but I'm curious why the messagebox is being such a jerk to me.

Yours,

Dan

 

[EzLogic]

Its the timeout of the msgbox

Ez Logic
Michigan

 

[TamarGranor]

Try with a different value than 4096 for the second messagebox parameter. That's "system modal" and it's never a good choice unless you're using it for the equivalent of a fire alarm.

Tamar

 

[dantheinfoman]

Thank you Ez Logic! What should I do to resolve this?

Thanks!
Dan

 

[dantheinfoman]

Hi TamarGranor,

I'm using 4096 because it's the only thing that will make the messagebox popup appear in front of the VCX form, which disappears unless I make the VCX form be always on top. If you have solutions to those, I'd be much obliged!

Thanks
Dan

 

[Olaf Doschke]

To say it clearer: The Messagebox is modal, it "disables" anything, while it runs. 4096 should only be used in conjunction with a timeout (which you'd specify in the next parameter).
No matter how you set this or the third parameter, a Messagebox is modal, system modal is even more modal, not only modal to your application, but to the whole system, for very urgent "fire alarms" needing attention.

To be clear, modal always means nothing else can be used.

Your users (and you yourself) should know, that a messagebox first needs confirmation, clicking OK or closing it, then you can use anything else again. This is true for any messagebox, not only in VFP.

If you just want to show an info the Windows UX offer status bar or ballon tip. Both won't show at the place the user should pay attention. I'd set the backcolor of the textbox red or yellow, to focus attention to it. A Messagebox also isn't wrong, it may just be too nagging for such a small mistake of forgetting to enter a mandatory information.

Bye, Olaf.

 

[dantheinfoman]

Vielen Dank, Olaf. I will stick with the wait window.

If, however I do a Yes/No type messagebox, would there be a way to then activate the textbox that won't allow me to click in it or am I kind of stuck?

Thanks, thanks and more thanks!!

Dan

 

[Dan Freeman]

I'm using 4096 because it's the only thing that will make the messagebox popup appear in front of the VCX form, which disappears unless I make the VCX form be always on top. If you have solutions to those, I'd be much obliged!

There is absolutely no difference between a VCX form and a SCX form. None.

I'm a little confused about the visibility problem you mention. You may have made set ShowWindow to "As Top Level" perhaps? Set Desktop=.t.? A messagebox() will not disappear a running form on its own, unless you've done something to cause that. You haven't told us what that might be.

As others have said, ditch 4096.

 

[Olaf Doschke]

If, however I do a Yes/No type messagebox, would there be a way to then activate the textbox ...

I already said

No matter how you set this or the third parameter, a Messagebox is modal...

It doesn't matter, if it's a standard MessageBox with just OK or with any other buttons. Any MessageBox works modal, to be clear in this context any MesageBox means every MessageBox. Also any messagebox appears in front of anything else, even top level or alwaysontop forms.

So, any MessageBox is modal and a) disables the user to use anything else while running and b) no further code runs, until it's confirmed, closed, answered. Your .tbmyRpt.SetFocus runs after the MessageBox is closed, you may do that before displaying the MessageBox, if you want to go back there, but a MessageBox is no side by side message you could display as an instruction while the user works, you'll need to design your own non modal form for that. Another thing, that comes to mind is making use of the Microsoft Agents, but that's also legacy. The infamous "clippy" paper clip of Office 97.

Bye, Olaf.

 

[Dan Freeman]

One thing about System Modal and MessageBox has been sticking in my craw but I couldn't put my finger on it yesterday and didn't have time to look it up until just now. It doesn't mean what you think it means and doesn't do what you think it does, so it's probably best not used anyway.

First, note that it is not documented in the VFP help file. It's in the tooltip, but not in help.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms645505%28v=vs.85%29.aspx[/URL]]Same as MB_APPLMODAL except that the message box has the WS_EX_TOPMOST style. Use system-modal message boxes to notify the user of serious, potentially damaging errors that require immediate attention (for example, running out of memory). This flag has no effect on the user's ability to interact with windows other than those associated with hWnd.

I'd heard ages ago that "system modal" (as we used to know it) has ceased to be a thing supported by Windows itself. This comment from the WinAPI function definition seems to support that, and a quick test just now pretty much confirms it. With system modal, a user can click on and activate any other window and take focus away from the messagebox while the messagebox remains topmost.

 

[Olaf Doschke]

Hi Dan,

OK, so it could be used, if it could be positioned. I wouldn't use it nevertheless, if it's deprecated.
Informal messages could also be shown on the form itself, adding a container or label where you want to show a message.
You can also add controls at runtime:

[pre]Thisform.AddObject("infolabel","label")
With Thisform.infolabel
.top = ...
.left= ...
.caption="please enter this"
.visible = .T.
Endwith[/pre]

Maybe you design a label class vanishing after a timeout.

But I'd rather set back colors. Not so easy for some controls.

Bye, Olaf.

 

[dantheinfoman]

You guys are all Jedi masters. I thank you for your time and explanations. I will keep playing with this. Tentatively, I agree, messageboxes are too invasive for this. So Wait Window wins.

Thanks much!!

Dan

 

[Olaf Doschke]

Just one final thing: Any window would take focus away, when it starts. That's the way the Windows OS works in general.

Bye, Olaf.

 

[Mike Lewis]

Tentatively, I agree, messageboxes are too invasive for this. So Wait Window wins.

When I want to notify the user of something, but don't want the notification to be to intrusive, I use my patented "fade form". This is a small message box that appears, say, in a corner of the screen. It gradually fades into view; stays visible for a few seconds; and fades out again.

If you would like to consider that approach, see Add a fading effect to your forms.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads