PREVENTING MORE THAN 1 INSTANCE OF YOUR PROGRAM - advanced level
by Ken Lewis kenlewissr@sbcglobal.net


Home

Liberty BASIC News
Safe Registry and Ini File Alternative
Deleting and Renaming Disk Files
Segments and Flushing
Flat Toolbar with Toolips
Translating 32-bit VB API Calls
Event-Driven Programming Concepts
Spotlight on the Community!
ODBC in Liberty BASIC
Hex Viewer
Listing Files Recursively
Registering Hot Keys
Preventing more than 1 instance
Multi-Coloured Text Input Boxes
Images on Buttons and Statictext
Two Demos by David Conner

Liberty BASIC v3.02

From Hobbiest to Professional, most programmers eventually code a program that needs to prevent a second instance. Maybe you set up function specific hotkeys, or you add an Icon to the system tray. Whatever the reason, starting a second instance would, (at the very least), be problematic. Although there are many ways to approach this problem, the easiest, (that I have found so far), is provided by the Windows operating system. (I know this may be hard to believe, but it is true). In this article we will take advantage of a Windows object whose purpose is to coordinate MUTually EXclusive access to shared resources. This object is known as a MUTEX object. I will not go into details on using this with shared resources. Instead we will cover an exploitable benefit of creating a MUTEX object.

When creating a MUTEX object, we must supply a string of characters, which I will refer to as the 'name' of the mutex. If a mutex already exists with the same name, instead of a new one being created, the handle to the existing mutex is returned. In addition, the Windows defined error code, ERROR_ALREADY_EXISTS, is set by the operating system. If we create a mutex, and immedialely call GetLastError we can notify the user and end the program if it is already running.

Attached to the newsletter should be a file named 1InstanceOnly.bas. This is the example program to go with this article. A few words of caution follow;

1) Each program that you create, must have a unique name for the mutex. Otherwise you will end up with one program preventing a different program from running.

2) The attached code will not operate properly in the editor, my guess is that LB is taking ownership of the mutex. If you run it in the editor, you will have no problem starting a first instance over and over. If you try to start a second instance, the program will work as expected. After attempting to run a second instance, and closing the first instance, you will no longer be able to start a first instance. BUT if you tokenize the code it works exactly the way it is supposed to, every time.

3) If you are writing a network distributed program and you want to make sure that only one user at a time has access to the program, then the mutex name must begin with "Global\", (e.g. "Global\MyLibertyBASICProgram"). If you want to allow several users to run one instance of the program, at the same time, the mutex name must begin with "Local\", (e.g. "Local\MyLibertyBASICProgram").

4) Mutex 'name' comparison is case sensitive. So if you have a program that edits information, and a different program that displays that information, (i.e. 15 users can view customer information, but only 2 users are allowed to edit it.) You can prevent the viewers from opening, while the editors are in use. BUT you have to make sure that you match the name and case of the mutex in all programs.

If you find this code useful, be sure to thank our newsletter editors/publishers, for allowing me to share it.




Home

Liberty BASIC News
Safe Registry and Ini File Alternative
Deleting and Renaming Disk Files
Segments and Flushing
Flat Toolbar with Toolips
Translating 32-bit VB API Calls
Event-Driven Programming Concepts
Spotlight on the Community!
ODBC in Liberty BASIC
Hex Viewer
Listing Files Recursively
Registering Hot Keys
Preventing more than 1 instance
Multi-Coloured Text Input Boxes
Images on Buttons and Statictext
Two Demos by David Conner