Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
PLEASE HELP. Preventing Multiple Instances of an Applica
Message
From
07/08/2000 15:40:55
 
 
To
07/08/2000 15:32:54
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00401892
Message ID:
00401894
Views:
27
>I'm trying to prevent a user from opening a Foxpro 5.0 application more than one time. Right now I'm loging a flag to a Foxpro table and resetting it when they log out of the application. Problem is when there is a power outage or the pc has to be rebooted without properly exiting the application, the flag has to be reset manually by the user.
>
>Is there another way to prevent multiple instances of an application from being opened?

Attempt to FCREATE() a file of a known name in a specific location on a -local- drive, and don't FCLOSE() it or issue CLOSE ALL until you're about to exit the app. Only one application can issue an FCREATE() at any instant; if the system fails, the file being FCREATE()ed is no longer locked, so the app can open again.

An equivalent technique would be to USE filename EXCLUSIVE and trap the error, again, only one thing can have a file open for EXCLUSIVE access at any instant in time. Thew advantage of using the FCREATE() is that you can issue a CLOSE DATABASE and the FCREATE() remains active, and there's no file header to corrupt, so you don't have to differentiate between different failure modes (USE EXCLUSIVE could fail because the table is in USE already, or because the table header was corrupt, resulting in a Not a table error.)

You can also look at George Tasker's IS_RUN() in the Files section, and a number of entries in the FAQ.
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform