Avoiding multiple executables from running 
Author Message
 Avoiding multiple executables from running

I know how to prevent the same executable from being started twice on
the same machine.

But, is there an easy way to prevent another VB executable from
running.  I have two versions of the same program and they lock up if
both are running because they try to use the same data acquisiton
device.



Sat, 11 Dec 2010 22:56:06 GMT  
 Avoiding multiple executables from running

Quote:

>I know how to prevent the same executable from being started twice on
> the same machine.

> But, is there an easy way to prevent another VB executable from
> running.  I have two versions of the same program and they lock up if
> both are running because they try to use the same data acquisiton
> device.

Create a mutex.  Mutexes are system-wide, so each app can check for the same mutex created by the other app. Here's an example:

-------BEGIN CODE

Private Type SECURITY_ATTRIBUTES
    nLength                             As Long
    lpSecurityDescriptor                As Long
    bInheritHandle                      As Long
End Type
Private Const ERROR_ALREADY_EXISTS      As Long = 183

Private Declare Function CreateMutex Lib "kernel32" Alias "CreateMutexA" (lpMutexAttributes As SECURITY_ATTRIBUTES, ByVal
bInitialOwner As Long, ByVal lpName As String) As Long

Private Sub Main()

    Dim sa                          As SECURITY_ATTRIBUTES

    'Prevent running this program again if it's already running
    If Not IsIDE Then 'InIDE Then 'only process in compiled exe
        sa.bInheritHandle = 1
        sa.lpSecurityDescriptor = 0
        sa.nLength = Len(sa)

        Call CreateMutex(sa, 1, "MutexName")

        If Err.LastDllError = ERROR_ALREADY_EXISTS Then
            MsgBox App.Title & " is already running.", vbInformation
            Exit Sub
        End If
    End If

<remaining code for Sub Main
End Sub

Public Function IsIDE() As Boolean

    Dim hVB432          As Long
    Dim hVB416          As Long
    Dim hVB5            As Long
    Dim hVB6            As Long

    hVB432 = GetModuleHandle("VB32.EXE")
    hVB416 = GetModuleHandle("VB.EXE")
    hVB5 = GetModuleHandle("VB5.EXE")
    hVB6 = GetModuleHandle("VB6.EXE")

    IsIDE = (hVB432 > 0 Or hVB416 > 0 Or hVB5 > 0 Or hVB6 > 0)

End Function

-----END CODE

You can use any name you want for the mutex.  Simply check for the same name in both apps and take appropriate action if the mutex
exists.

--
Mike
Microsoft Visual Basic MVP



Sat, 11 Dec 2010 23:24:32 GMT  
 Avoiding multiple executables from running


Quote:
>Create a mutex.  Mutexes are system-wide, so each app can check for the same mutex created by the other app. Here's an example:

Your IsIDE function is clever. (Steals it, then looks innocent)

One question : Don't you have to destroy the mutex when it's no longer
in use, or does that happen automatically?

        J.
    Jeremiah D. Seitz
    Omega Techware
    http://www.omegatechware.net



Sat, 18 Dec 2010 01:40:14 GMT  
 Avoiding multiple executables from running



Quote:


>>Create a mutex.  Mutexes are system-wide, so each app can check for the
>>same mutex created by the other app. Here's an example:

> Your IsIDE function is clever. (Steals it, then looks innocent)

Thanks. Many people use a "simpler" means of a Debug.Assert with a divide by
0 operation.  That's fine in many cases.  However, a caveat of that is that
it won't work if you need to know if a compiled component (an ActiveX DLL or
OCX, for example) is being used within the IDE. The method I provided will.

Quote:

> One question : Don't you have to destroy the mutex when it's no longer
> in use, or does that happen automatically?

No, not necessary.  From the docs for CreateMutex from MSDN Library:

"The system closes the handle automatically when the process terminates. The
mutex object is destroyed when its last handle has been closed."

--
Mike
Microsoft MVP Visual Basic



Sat, 18 Dec 2010 02:28:53 GMT  
 Avoiding multiple executables from running



Quote:


> >Create a mutex.  Mutexes are system-wide, so each app can check for the

same mutex created by the other app. Here's an example:

Quote:

> Your IsIDE function is clever. (Steals it, then looks innocent)

> One question : Don't you have to destroy the mutex when it's no longer
> in use, or does that happen automatically?

I believe it is valid from 'boot' to 'boot'.
So yes, you should also consider a removal strategy whenever you use a
Mutex.


Sat, 18 Dec 2010 02:36:20 GMT  
 Avoiding multiple executables from running


Quote:





> >>Create a mutex.  Mutexes are system-wide, so each app can check for the
> >>same mutex created by the other app. Here's an example:

> > Your IsIDE function is clever. (Steals it, then looks innocent)

> Thanks. Many people use a "simpler" means of a Debug.Assert with a divide
by
> 0 operation.  That's fine in many cases.  However, a caveat of that is
that
> it won't work if you need to know if a compiled component (an ActiveX DLL
or
> OCX, for example) is being used within the IDE. The method I provided
will.

> > One question : Don't you have to destroy the mutex when it's no longer
> > in use, or does that happen automatically?

> No, not necessary.  From the docs for CreateMutex from MSDN Library:

> "The system closes the handle automatically when the process terminates.
The
> mutex object is destroyed when its last handle has been closed."

You are correct. My above reply was hasty as I was thinking of something
else.

-ralph



Sat, 18 Dec 2010 03:10:06 GMT  
 Avoiding multiple executables from running


Quote:
> > Your IsIDE function is clever. (Steals it, then looks innocent)

> Thanks. Many people use a "simpler" means of a Debug.Assert with a divide by
> 0 operation.  That's fine in many cases.  However, a caveat of that is that
> it won't work if you need to know if a compiled component (an ActiveX DLL or
> OCX, for example) is being used within the IDE. The method I provided will.

That last line looked a bit verbose to me, since there will only be one that
actually has a value I was wondering if it would be easier to just add the
results:

from:
    IsIDE = (hVB432 > 0 Or hVB416 > 0 Or hVB5 > 0 Or hVB6 > 0)

to:
    IsIDE = (hVB432 + hVB416 + hVB5 + hVB6) > 0

LFS



Sat, 18 Dec 2010 06:15:37 GMT  
 Avoiding multiple executables from running

Quote:

> That last line looked a bit verbose to me, since there will only be one that
> actually has a value I was wondering if it would be easier to just add the
> results:

> from:
>     IsIDE = (hVB432 > 0 Or hVB416 > 0 Or hVB5 > 0 Or hVB6 > 0)

> to:
>     IsIDE = (hVB432 + hVB416 + hVB5 + hVB6) > 0

I was thinking along the same lines, but would expect
slight advantages from sticking with 'Or'

      IsIDE = (hVB432 Or hVB416 Or hVB5 Or hVB6) > 0

        Bob
--



Sat, 18 Dec 2010 06:18:28 GMT  
 Avoiding multiple executables from running


Quote:

>> That last line looked a bit verbose to me, since there will only be one
>> that
>> actually has a value I was wondering if it would be easier to just add
>> the
>> results:

>> from:
>>     IsIDE = (hVB432 > 0 Or hVB416 > 0 Or hVB5 > 0 Or hVB6 > 0)

>> to:
>>     IsIDE = (hVB432 + hVB416 + hVB5 + hVB6) > 0

> I was thinking along the same lines, but would expect
> slight advantages from sticking with 'Or'

>      IsIDE = (hVB432 Or hVB416 Or hVB5 Or hVB6) > 0

I suppose either of those is slightly more legible. But I don't think either
is going to make a difference performance-wise.

--
Mike
Microsoft MVP Visual Basic



Sat, 18 Dec 2010 06:54:20 GMT  
 Avoiding multiple executables from running

Quote:




>>> That last line looked a bit verbose to me, since there will only be one
>>> that
>>> actually has a value I was wondering if it would be easier to just add
>>> the
>>> results:

>>> from:
>>>     IsIDE = (hVB432 > 0 Or hVB416 > 0 Or hVB5 > 0 Or hVB6 > 0)

>>> to:
>>>     IsIDE = (hVB432 + hVB416 + hVB5 + hVB6) > 0

>> I was thinking along the same lines, but would expect
>> slight advantages from sticking with 'Or'

>>      IsIDE = (hVB432 Or hVB416 Or hVB5 Or hVB6) > 0

> I suppose either of those is slightly more legible. But I don't think either
> is going to make a difference performance-wise.

A negligible difference is still /a difference/.

And legibility is *always* a worthwhile goal.

I'm working on a POS project right now (no - I do NOT mean "point of sale")
which has the earmarks of at least three wildly different and substantially
incompatible programming styles.  Of the little of it that is commented
at all, nearly half has comments which look like "line noise" to me,
because the PC doesn't have the required character set installed.
Not that those comments would be any more readable _to me_ if they were
properly displayed...

        Bob
--



Sat, 18 Dec 2010 07:05:09 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. How to avoid multiple instances...

2. Avoiding multiple connections when using data controls

3. Maybe OT: Avoid multiple logons on web apps.

4. Avoid multiple row select in MSFlexGrid

5. How to avoid multiple record locking?

6. Multiple Icons in executable???

7. Multiple executables in a single project

8. How to compile multiple reports into one executable under Crystal Report 6.0

9. Validating Events, Avoid running

10. Macros in Excel: How do I avoid getting confirmation windows when I run the macro

11. Avoid Repetition Run for my EXE ( VB )

12. Code to schedule modules to run every hour (or multiple daily runs)

 

 
Powered by phpBB® Forum Software