How to reject double run?

[dobro]

I know we're going OT here, but my first 'personal' computer was a Sinclair ZX80. My only regret is that I sold it

I've always mine, with its mechanical keyboard, and its cartridge 16 k
it still works



ps:
I still have a STF 1040 (with einstel above (RTC Server))

and Falcon030 (set in artisanal fashion Tweaking Big)

[TI-994A]

I've always mine, with its mechanical keyboard, and its cartridge 16 k
it still works

Very nice! So, that makes it the TI-994A, the Sinclair ZX-81, and the Atari STF & Falcon030? You're quite the collector. It was four years after my TI that I upgraded to my very first PC, the Canon A200; both of which I still have.

Thanks for the wonderful walk down memory lane!

[dobro]

arf! I no longer have my TI99/4A, but I have a Canon X07 in a closet


I used until 2000 to generate customer invoices (flower shop )
on matrix printer via Rs232 welded on it

... yes, memories, memories

[TI-994A]

... yes, memories, memories

If you're not the sentimental kind, I've got one word for you: eBay! Where memories become quick bucks!

[Danilo]

Code: Select all

	*MyMutex = CreateMutex_(#Null, 1, LockStr$)

Code: Select all

mutexName = "myUniqueAppFlag"
appInstance = CreateMutex_(0, 1, @mutexName)

Both codes use 0/#Null for the security attributes:

The CreateMutex() call fails with ERROR_ACCESS_DENIED if the Mutex was created in another user's session. This comes from passing NULL for the SECURITY_ATTRIBUTES which results in default security settings. The typical default DACL allows only CREATOR/OWNER and SYSTEM access to the object.

[...]

the naive approach can actually keep independent users from running concurrently on an NT system.

There is an interesting article by Dr. Joseph M. Newcomer (MS MVP) about the topic:
- Avoiding Multiple Instances of an Application (his homepage)
- Avoiding Multiple Instances of an Application (at codeproject)

Sourcecode for the articles: exclusion.zip (VC++ version) and SingleInstance.zip (VC version)

His approach has the feature of defining what "single instance" actually means by using some flags:

Code: Select all

SI_SESSION_UNIQUE                        - Allow one instance per login session
SI_DESKTOP_UNIQUE                        - Allow one instance per desktop
SI_TRUSTEE_UNIQUE                        - Allow one instance per user account
SI_SESSION_UNIQUE | SI_DESKTOP_UNIQUE    - Allow one instance per login session,
                                           instances in different login sessions
                                           must also reside on a different desktop
SI_TRUSTEE_UNIQUE | SI_DESKTOP_UNIQUE    - Allow one instance per user account,
                                           instances in login sessions running a
                                           different user account must also reside    
                                           on different desktops.
SI_SYSTEM_UNIQUE                         - Allow only one instance on the whole system

I let it to you to translate it to PB.
(check his "My Policy on Use of My Code")

More articles by him: MVP Tips, Techniques, and Goodies

Also check out CreateMutex documentation at MSDN:

Parameters
[...]
lpName
[...]
The name can have a "Global\" or "Local\" prefix to explicitly create the object in the global or session namespace.
The remainder of the name can contain any character except the backslash character (\).
For more information, see Kernel Object Namespaces. Fast user switching is implemented using Terminal Services sessions.
Kernel object names must follow the guidelines outlined for Terminal Services so that applications can support multiple users.

The object can be created in a private namespace. For more information, see Object Namespaces.

[...]

Remarks

If you are using a named mutex to limit your application to a single instance, a malicious user can create this mutex
before you do and prevent your application from starting.
To prevent this situation, create a randomly named mutex and store the name so that it can only be obtained by an authorized user.
Alternatively, you can use a file for this purpose. To limit your application to one instance per user, create a locked file in the user's
profile directory.