Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Only open application once
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00585701
Message ID:
00585847
Views:
50
>>>Hi Nadya,
>>>
>>>The API you reference to only shows how to prevent second instance of the application from running. The "FirstInstance.prg" does the same in vary similar way. In addition it shows how to make already open application's window active.
>>
>>Sergey,
>>
>>Having written the article and having seen Ed's code, if I were currently looking for a solution to this problem, I'd probably use Ed's method with the necessary additions to display the original instance of the application. I say this because Ed's solution requires less code overhead, and, therefore, would be easier to maintain.
>>
>>Admittedly, I still use my solution, but only because it's the method recommended in the Platform SDK.
>
>Hi George,
>
>Maybe I'm missing something, but only difference I see in Ed's code that it creates event instead of mutex.
>* Ed's
>DECLARE INTEGER CreateEvent IN WIN32API ;
>   INTEGER lpEventAttributes, ;
>   SHORT bManualReset, ;
>   SHORT bInitialState, ;
>   STRING @ lpName
>DECLARE INTEGER GetLastError IN Win32API
>DECLARE CloseHandle IN Win32API INTEGER hObject
>nEh = CreateEvent(0,0,1, PROGRAM(0) + '.EVENT')
>IF GetLastError() = ...
>
>* FirstInstance.prg
>DECLARE INTEGER CreateMutex IN win32api INTEGER, INTEGER, STRING @
>DECLARE INTEGER GetLastError IN Win32API
>DECLARE CloseHandle IN Win32API INTEGER hObject
>cExeFlag = "STARBASE"+CHR(0)
>nExeHwnd = CreateMutex(0,1,@cExeFlag)
>IF GetLastError() = ...
>
As I can see both of them use the same amount of code.

Sergey,

First, I'm working purely on recollection here, so if it's faulty, my apologies. Second, and to the point, I wasn't comparing Ed's work to the other program in the download section. I was comparing it to mine. There's a significant difference between the two.

The problem, as I see it with the use of the Mutex solution (as in the example above), is that the Mutex isn't properly released. This doesn't cause problems at run time, since the Mutex is destroyed when the application closes. At design/debugging time, however, it does. If, in course of debugging, you run your application (using the Mutex to prevent other instances) what happens is that the Mutex isn't destroyed when you return to the design mode. This is because the Mutex belongs to FoxPro, not the application. Under this circumstance, this would require you to exit VFP and re-open to continue. Naturally, there are additional API calls (and code) involved. If I recall correctly, Ed's implementation handles this issue more simply.
George

Ubi caritas et amor, deus ibi est
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform