How to disable the "Exit" button ?

  • Thread starter Thread starter Agnes
  • Start date Start date
A

Agnes

I need to disable the exit button in the form .
However, the min. and max. button need to keep it

How ?
Thanks a lot
From Agnes
 
Agnes said:
I need to disable the exit button in the form .

You can, but in 99% of applications you shouldn't. It's about
the same as mounting a brick under a car's brake pedal to make
sure it always goes fast enough.

That X isn't an exit button, it's a close button (it closes a
window). Most VB applications do exit indeed when their last
window is closed.

When you click it, the "Closing" event is fired in the code
belonging to that form. You can cancel it through the event
arguments: set e.cancel = true; but *NEVER* do so without asking
the user for confirmation.

If not handled properly (i.e. a plain dumb "e.cancel=true"), it
will effectively make it impossible for a user to log off or to
shut down his system without first killing your app through task
manager. Most of them will just reach for the power or reset
button instead.
In either case, your app won't be able to exit cleanly.
 
* "Agnes said:
I need to disable the exit button in the form .
However, the min. and max. button need to keep it

\\\
Private Declare Auto Function GetSystemMenu Lib "user32.dll" ( _
ByVal hWnd As IntPtr, _
ByVal bRevert As Int32 _
) As IntPtr

Private Declare Auto Function GetMenuItemCount Lib "user32.dll" ( _
ByVal hMenu As IntPtr _
) As Int32

Private Declare Auto Function DrawMenuBar Lib "user32.dll" ( _
ByVal hWnd As IntPtr _
) As Int32

Private Declare Auto Function RemoveMenu Lib "user32.dll" ( _
ByVal hMenu As IntPtr, _
ByVal nPosition As Int32, _
ByVal wFlags As Int32 _
) As Int32

Private Const MF_BYPOSITION As Int32 = &H400
Private Const MF_REMOVE As Int32 = &H1000

Private Sub RemoveCloseButton(ByVal frmForm As Form)
Dim hMenu As IntPtr, n As Int32
hMenu = GetSystemMenu(frmForm.Handle, 0)
If Not hMenu.Equals(IntPtr.Zero) Then
n = GetMenuItemCount(hMenu)
If n > 0 Then
RemoveMenu(hMenu, n - 1, MF_BYPOSITION Or MF_REMOVE)
RemoveMenu(hMenu, n - 2, MF_BYPOSITION Or MF_REMOVE)
DrawMenuBar(frmForm.Handle)
End If
End If
End Sub
///
 
* lucvdv said:
You can, but in 99% of applications you shouldn't. It's about
the same as mounting a brick under a car's brake pedal to make
sure it always goes fast enough.

That X isn't an exit button, it's a close button (it closes a
window). Most VB applications do exit indeed when their last
window is closed.

Did you ever install MSDN? I remember, for some seconds, even the close
button is disabled. There are certain cases where this makes sense.
 
Hi Herfried,
Did you ever install MSDN? I remember, for some seconds, even the close
button is disabled. There are certain cases where this makes sense.

What is the addition in this message from you, you write the same as lucvdv?

Cor
 
Did you ever install MSDN? I remember, for some seconds, even the close
button is disabled. There are certain cases where this makes sense.

I was just trying to warn Agnes that overzealous use of it can have
undesired side effects, especially users inventing their own way to
exit the application without giving it an opportunity to shut down
cleanly.

Also keep in mind that removing or disabling the close button doesn't
prevent the user from stopping it. If an application really should
run all the time, it can be better to split it up into a worker core
and a user interface, and let the core run as service.


As always there are exceptions - you just don't want to interrupt some
things (such as flashing new firmware into a piece of hardware).
Some of my own projects run as shell on XP Embedded, exiting them at
any time would be quite undesirable, but still I built in a hidden way
to do it.

Even the shell instance of Windows Explorer has always had an exit
mechanism. At first sight it has little or no use, but it used to
provide the fastest way to repair the damage if the ShellIconCache got
corrupted.
 
* Lucvdv said:
I was just trying to warn Agnes that overzealous use of it can have
undesired side effects, especially users inventing their own way to
exit the application without giving it an opportunity to shut down
cleanly.
OK.

Also keep in mind that removing or disabling the close button doesn't
prevent the user from stopping it. If an application really should
run all the time, it can be better to split it up into a worker core
and a user interface, and let the core run as service.

A service for some simple work that should not be cancelled by the user?
As always there are exceptions - you just don't want to interrupt some
things (such as flashing new firmware into a piece of hardware).
Some of my own projects run as shell on XP Embedded, exiting them at
any time would be quite undesirable, but still I built in a hidden way
to do it.

;-)
 
Herfried said:
A service for some simple work that should not be cancelled by the user?

It depends on the application.

All through this thread, a similar question that someome once
asked in one of the MS newsgroups kept coming back to memory: his
boss had asked him to write a program to log all applications
that were used on a system, and he needed a way to prevent users
from shutting down the logger.
 
* lucvdv said:
It depends on the application.

All through this thread, a similar question that someome once
asked in one of the MS newsgroups kept coming back to memory: his
boss had asked him to write a program to log all applications
that were used on a system, and he needed a way to prevent users
from shutting down the logger.

In this case, I would write a service ;-).
 
Hi Lucvdv

That cannot be done in this way.
You can use the cancel in the taskmanager.

This kind of things have a simpler approach.

You set the start date and the end date in the log.

And tell that you check that with the payment system.

Cor
 
* "Cor Ligthert said:
That cannot be done in this way.
You can use the cancel in the taskmanager.

You can start the service in the admin account, so the simple user
doesn't have the rights to stop it.
 
You can start the service in the admin account, so the simple user
Both of them are history...

Full supported as far as it are no W2000 classes by the NET the same as VB

History?

Cor
 
* "Cor Ligthert said:
Full supported as far as it are no W2000 classes by the NET the same as VB

History?

Mhm... I don't know anybody who is still using Windows 98 and Windows Me.
 
In windows W98 or in windows ME?
Mhm... I don't know anybody who is still using Windows 98 and Windows Me.

And you could not say that to Microsoft, they still are supporting W98 and
Windows Me and you do not know anybody who is still using it.

:-))))

Cor
 
* "Cor Ligthert said:
And you could not say that to Microsoft, they still are supporting W98 and
Windows Me and you do not know anybody who is still using it.

If my customers don't use it, why design applications for it?

;-)))
 
Back
Top