VFP8 - Modal form off screen locks application 3

[stuartmckay99]

I am curious how developers are handling the situation where a user drags a top level form off the screen so that most of the form is off screen with the exception of a button that launches a modal form. The modal form launched is centered on the screen and hence not visible.

The result is that the app is hung since the top level form can not be moved while the modal form is active unless the user is smart enough to right click on the title bar and use the move option.

Any ideas?

thanks,

Stuart

 

[MrDataGuy]

Boy, other than some smart-aleck remark answer, I do not know.

Seems like VFP is doing the same thing that Excel and Word etc is doing, just waiting for the user. E.g. if the user is ‘smart’ enough to set up the situation, they should be able to get themselves out of it.

I suppose a timer could be set to close an application after so long of no use, but that seems overkill.

To be honest I have never seen this situation in the real world (obviously you have. ) maybe the real answer is user training?

Is this really happening so much that it is an issue?

Of course someone else may answer your question with the perfect answer and I will learn something new.


BTW IMO "the app is hung" is not true, it is just waiting for the user. 0.001 seconds vs 1000 seconds is the same to the app. IN a sense it is the user that is 'hung', again IMO

Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[Dan Freeman]

The easy answer is that EVERY FORM MUST RESPOND TO THE ESC KEY.

I'm curious, though, how they're clicking on a button to fetch up a modal form if the form containing the button has been slid off the screen?

 

[Mike Lewis]

I can't say that this is something that has ever concerned me, although I suppose it's possible that it could happen.

In general, in all modal forms, I set the Cancel property of the Cancel or Close button to .T. This ensures that the form will close when the user hits ESC - which is probably one of the first things a user does when the program seems not to be responding.

Personally, I don't do that with every form, as Dan suggests - just with modal forms. But there might be a reason to do it with modeless forms as well.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

You can always position the application window, eg the screen. There is always the task bar with it's context menu items, eg to move an application window. Mouse cursor changes to an arrow cross and you can use arrow keys to move a form.

If all else fails, there is the taks manager...

Bye, Olaf.

 

[ChrisRChamberlain]

One option would be to put something like

[COLOR=blue]WITH THIS
	IF .Top < 0
		.Top = 1
	ENDI	
	IF .Left < 0
		.Left = 1
	ENDIF
ENDWITH[/color]

in the .Moved() event of the top-level form, and then the user cannot drag it off the screen.

What will happen under Windows 7 is if you 'hit' the top of the screen too hard, the form will maximize, (default behaviour), but that might easier to manage than the scenario described.

FAQ184-2483​

Chris
PDFcommander.com
motrac.co.uk

 

[Mike Lewis]

What about setting the modal form's Desktop property to .T. Doesn't that mean you can position the form outside the parent (top-level) form? If that's right, you could always programmatically centre the modal form within the physical screen.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

Personally, I don't do that with every form, as Dan suggests - just with modal forms. But there might be a reason to do it with modeless forms as well.

I built it into the first form class hierarchy I built in VFP (because that's the way "forms" worked in FPW) and never saw any reason to remove it. There's a predictability that users get comfortable with: when they see a form, it will respond to ESC. Doesn't matter what "kind" of form.

If only some forms respond to ESC, how are users to know which ones are which?

 

[stuartmckay99]

I will give the ESC as well as checking if the form is outside the screen area a try.

thanks for the input.

Stuart

 

[TamarGranor]

If only some forms respond to ESC, how are users to know which ones are which?

In my apps, modal forms respond to ESC, but modeless forms do not. Since modal forms have other behaviors that differ from modeless forms, there is a way for a user to build a mental model.

Tamar

 

[Dan Freeman]

In my apps, modal forms respond to ESC, but modeless forms do not. Since modal forms have other behaviors that differ from modeless forms, there is a way for a user to build a mental model.

Really? When someone uses a phrase like "build a mental model" I wonder why users NEED to build a mental model. ;-)

When users see a thing, it should behave like that thing. It shouldn't behave differently on Tuesdays, or because the month has an R in it, or because of some arbitrary condition that exists in a developer's head that may not map to the way the user sees the world.

(Note to the world: Tamar and I are dear friends and have discussed interface issues for many years! We both go back and forth over time.)

 

[TamarGranor]

Really? When someone uses a phrase like "build a mental model" I wonder why users NEED to build a mental model. winky smile

When users see a thing, it should behave like that thing. It shouldn't behave differently on Tuesdays, or because the month has an R in it, or because of some arbitrary condition that exists in a developer's head that may not map to the way the user sees the world.

So your apps don't have both modal and modeless forms? <g>

After all, the user has to build a mental model (whether it's easy or hard to do so) that helps him understand why some forms can be used in parallel and others insist on attention before moving on. If the user can handle that, I think he can get used to the idea that ESC works for the latter, but not the former.

Tamar

 

[Dan Freeman]

So your apps don't have both modal and modeless forms? <g>

Of course I do, but they all respect the ESC key. <g>

After all, the user has to build a mental model (whether it's easy or hard to do so) that helps him understand why some forms can be used in parallel and others insist on attention before moving on.

Actually, they don't. Modal forms enforce their own modalness without regard to a user's "mind map". (Contrary to it in some designs, truth be told.) In fact, most of my users DON'T create any sort of mapping.

Sorry, this sounds like an arbitrary programmer's "I did it this way and it's already done, so here's the reason I made up after it was done already". <g>

JOMO

 

[TamarGranor]

Quote:
After all, the user has to build a mental model (whether it's easy or hard to do so) that helps him understand why some forms can be used in parallel and others insist on attention before moving on.


Actually, they don't. Modal forms enforce their own modalness without regard to a user's "mind map". (Contrary to it in some designs, truth be told.) In fact, most of my users DON'T create any sort of mapping.

I agree that modal forms enforce their behavior, but if users don't build a mental model about it, they're going to view it as arbitrary: "Gee, some forms let me jump back and forth, and others don't, and I never know what to expect."

I'll bet somebody has done some research on this, so we can stop guessing, but no time to look for it now.

Tamar

 

[Dan Freeman]

"Gee, some forms let me jump back and forth, and others don't, and I never know what to expect."

Yep. I hear that from users ALL THE TIME <g>, and about a variety of mainstream applications.

I tend to stick with Apple's original HIG which eschew modal forms at all unless absolutely necessary and never for extended tasks.

I feel a U/I design rant coming on having spent some time comparing iOS apps to the current HIG and noting how many of them are WRONG but clearly able to see the lazy programmer syndrome behind *why* they're the way they are.

 

[Olaf Doschke]

Looking at Apples Guidelines I found this:

http://developer.apple.com/library/...Windows.html#//apple_ref/doc/uid/20000961-TP9

So Alerts (Messageboxes) and other modal forms have none of the close,minimze,maximize buttons and thus can be identified as such.

In MS Windows, Messageboxes do have the close button.

In regard to this thread what's more important is, that such forms should never be off screen. And you know how it is with messageboxes in multple display situations. Most graphic card drivers do support showing the messagebox on the same screen as the applicaition creating it is.

Autocenter already is a good choice, keeping the _screen or top level form on screen, too. Let modal forms have Desktop = .t. is another helpful setting.

Bye, Olaf.

 

[Dan Freeman]

In MS Windows, Messageboxes do have the close button.

Yes, and that introduces an interesting enigma:

? MessageBox( "Some Message" )

How do you detect whether the user clicked the OK button or the close button? (Granted this shouldn't really matter.)

But it gets even more confusing because the close button isn't always enabled! Compare these:

? MessageBox( "Some Message", 5 )
? MessageBox( "Some Message", 4 )

It's inconsistent.

 

[Mike Lewis]

Dan,

I assume it's because MessageBox( "Some Message", 5 ) has a Cancel button, whereas MessageBox( "Some Message", 4 ) doesn't. The rule seems to be that if the buttons include a Cancel button, the Close button is enabled, and otherwise it isn't. And if the Close button is enabled, the box responds to ESC, and otherwise it doesn't.

I can sort of see the logic in that, though I agree it's a bit confusing.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Dan Freeman]

Hi Mike,

Yeah, consistent it isn't. You're presuming what the rule seems to be, and you have all the options at your fingertips so you can muddle through it and see which options cause what.

Are we to expect the shipping clerk or department secretary to know this? Is it any wonder why they hate their computers?

(Like I said, I feel a rant coming on. <g>)

Dan

 

[Mike Lewis]

Dan,

Feel free to rant.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy