Main Screen 'X' Closable 2

[gbcpastor]

How can I disable the control box at the top right of main FoxPro window making it non-closable when I run an app?

 

[Mike Lewis]

[tt]_screen.Closable = .F.[/tt]

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

I've answered your question. But you might want to ask yourself if this is really what you want to do.

Put yourself in your user's shoes. Almost every application you know allows you to close down by clicking the X in the top right corner of the window. Now you come across an application where the X does not have this effect. Is that going to endear you to the application?

A better approach is to keep the X enabled and to use ON SHUTDOWN to control what happens when the X is clicked. Something like this:

* Start of main program
ON SHUTDOWN DO ExitProc

* The rest of the main program here

FUNCTION ExitProc
lcMessage = "Are you sure you want to quit?"
IF MESSAGEBOX(lcMessage, 1, 32) = 1
  * User wants to quit
  QUIT
ENDIF
RETURN

This is just an example, of course, but it should give you a general idea.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[gbcpastor]

Thanks Mike, that's perfect. And I will take your advice on the "On Shutdown".

 

[Olaf Doschke]

Mike,

but ON SHUTDOWN also happens, when the OS shuts down. And you usually don't want to be in the way there.

gbcpastor,

there are problems with the _screen closebox X, wherever you want to do end-of-business-day processing which a) should run once per day and b) should run once per day. I prefer ON SHUTDOWN QUIT (don't think that leaves no spare room for the application to tidy up, all classes run their Destroy event, all forms get a QueryUnload besides their Destroy and Unload).

Part of the solution for such a condition is not trying to avoid any unwanted exit, but do a countermeasure at startup, detecting whether the application was ended normally and even if so, whether the user did pick the end-of-business-day processing or not, to do it then. That detection is easy, you write out a file at the end of a normal closing of your application, check its existence at startup. When it exists you remove it and any unplanned closing leaves this state as detectable non-normal end of the previous session, you only generate it again at the normal ending. Same about the end-of-day-processing, you have several ways to also mark that in some data, especially if its sufficient the last system of a shop triggers that you want that information centralized and not in a local file existence, only.

You gotta be prepared for the case an app crashes anyway. And that can happen, no matter how pristine your code may be, due to disc space running full, power outages and more.

You can anyway remove that X option or even the whole title bar for the user for sake of running as the main software like a POS system, and still have ON SHUTDOWN QUIT to not be in the way when the OS restarts. which may also be due to Windows updates.

If you simply try Mikes routine and shut down your system, the mechanism of Windows listing software not closing will bring up your application and ask to cancel the system shutdown. From that perspective, you're good to go with such code, as long as the user is there to react, but the option has a timeout and when this happens during night the OS will still simply kill your process. Another reason you'd want to be prepared for the scenario a previous ending of your application wasn't as planned.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[gbcpastor]

Thanks Olaf. You've given me much to consider.

 

[Mike Lewis]

but ON SHUTDOWN also happens, when the OS shuts down. And you usually don't want to be in the way there.

Yes, I am aware of that, but it doesn't detract from my point. If he wants to interrupt the shutdown for whatever reason - to get user confirmation, to deal with unsaved edits, whatever - that reason would probably apply regardless of whether the user clicks the X in the title bar, or selects Close from the control menu, or right-clicks and selects Close Window from the taskbar, or shuts down Windows.

Of course, we don't know exactly why the OP wants to disable the X in the title bar. It might help to know that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[vernpace]

Best not to disable the control box. However, as Mike mentioned, there are scenarios where you may not want the user to close the form. You can use the QueryUnload Event to accomplish this. Pseudo code:

IF conditions are [b]not[/b] ok to close the form
   MESSAGEBOX("You forgot something dude.", 0, "Error")
   RETURN .F.
ENDIF

 

[Mike Lewis]

Vernspace,

If you want QueryUnload to prevent a form from closing, then it needs to do NODEFULT rather than RETURN .F.

In any case, QueryUnload is not appropriate help here because the OP wanted to prevent the "Main Foxpro window" (_SCREEN) from closing, not an individual form.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

But _SCREEN also has Queryunload and you can program an event handler and bind it to that _screen event, to "program" the screen event.

And you can bind to _VFP.HWND receiving the WM_QUERYSHUTDOWN and WM_SHUTDOWN as other explicit signs it's the OS closing the app and not just the user clicking the X. And then you react appropriately to the case. And that again works fine without "redirecting" the ON SHUTDOWN to some procedure which again doesn't distinguish between closing the app via close button or other reasons.

Bye, Olaf.



Olaf Doschke Software Engineering

https://www.doschke.name

 

[gbcpastor]

Excellent suggestions all. I'll review them and likely use a little of all. Thanks guys for all your help.