Single Instance Limit 
Author Message
 Single Instance Limit

Is there a way to compile a VB6 app so that it can only run as a single
instance under XP?


Sun, 11 Mar 2012 10:28:01 GMT  
 Single Instance Limit

Quote:
> Is there a way to compile a VB6 app so that it can only run as a single
> instance under XP?

Check App.PrevInstance, however; if the user copied the EXE into a different
folder, it won't work. In this case, search the groups for "vb -dotnet
CreateMutex".


Sun, 11 Mar 2012 10:42:55 GMT  
 Single Instance Limit


Quote:
> Is there a way to compile a VB6 app so that it can only run as a single
> instance under XP?

It's not a matter of compiling.  It's a matter of writing code to handle it.
It's also not a matter of "XP" versus another version of Windows. If you
write this into your app, that's the way it's gonna be under XP, Vista,
Win7, Win98, etc (unless, of course, you write code to deal with each
version of Windows, which wouldn't be too difficult).

Quite simply, when your app starts (in Sub Main or the Load event of a form,
whichever you have set as your startup object), check App.PrevInstance. This
will be True if the
app is already running.  You can do this in a form's Load event, but Sub
Main is a much better place to perform such a check (before you even load
any forms).

However, there is a gotcha. App.PrevInstance only "works" if the app is
started again from the same folder. So, if there happens to be 2 copies of
your app's EXE file in different folders, and each of those EXEs is run,
App.PrevInstance will return False when the app is run the 2nd time. It's
not common to run into this situation, but it can happen.

--
Mike



Sun, 11 Mar 2012 11:05:09 GMT  
 Single Instance Limit
I have a question as to where App.PrevInstance is supposed to go:

In my case there are several small Apps which start a large App; call the
small apps a, b, & c, and the large app L.

First a starts L, while L is running b wants to start L, but I want b to
wait until L terminates.  There is also the possiblity that after a starts L,
both b and c may run an try to start L.  I have tried coding a, b & c to look
for a captioned form in L, by looking for its handle, when L terminates the
handle = 0.  But, some how multiple instances of L still seem to get executed.

Therefore would App.PrevInstance be placed in a, b & c, or would it be
placed a the begininng of L to detect a previous instance of itself?

Quote:



> > Is there a way to compile a VB6 app so that it can only run as a single
> > instance under XP?

> Check App.PrevInstance, however; if the user copied the EXE into a different
> folder, it won't work. In this case, search the groups for "vb -dotnet
> CreateMutex".



Sun, 11 Mar 2012 11:19:01 GMT  
 Single Instance Limit

Quote:
> First a starts L, while L is running b wants to start L, but I want b to
> wait until L terminates. ?There is also the possiblity that after a starts L,
> both b and c may run an try to start L. ?I have tried coding a, b & c to look
> for a captioned form in L, by looking for its handle, when L terminates the
> handle = 0. ?But, some how multiple instances of L still seem to get executed.

Your description of the architecture is fairly confusing..
'First a starts L' implies a is already running before L is started..
So a should be the startup. Right?
again you say 'while L is running b wants to start L'. Seems like you
are explicitly starting another instance of L and so oning
Clearly you are playing a loop game of various exe's so nothing
unusual  'multiple instances of L still seem to get executed'

Out of a,b,c,d and L Which one you want to restrict as single
instance?



Sun, 11 Mar 2012 11:40:32 GMT  
 Single Instance Limit
Thanks MikeD,

The only reason I referenced complilation, is that in newer versions of VB
there's a switch that compiles the APP to only run as a single instance.

I though it would need to run in the APP itself, as there is no way to
specify a reference to the target in App.PreviousInstance.

I appreciated the detailed explaination.

I don't think the single folder limit will be an issue as the App only
resides in one folder, along with the other apps that launch it.

Thanks again.

X.

Quote:



> > Is there a way to compile a VB6 app so that it can only run as a single
> > instance under XP?

> It's not a matter of compiling.  It's a matter of writing code to handle it.
> It's also not a matter of "XP" versus another version of Windows. If you
> write this into your app, that's the way it's gonna be under XP, Vista,
> Win7, Win98, etc (unless, of course, you write code to deal with each
> version of Windows, which wouldn't be too difficult).

> Quite simply, when your app starts (in Sub Main or the Load event of a form,
> whichever you have set as your startup object), check App.PrevInstance. This
> will be True if the
> app is already running.  You can do this in a form's Load event, but Sub
> Main is a much better place to perform such a check (before you even load
> any forms).

> However, there is a gotcha. App.PrevInstance only "works" if the app is
> started again from the same folder. So, if there happens to be 2 copies of
> your app's EXE file in different folders, and each of those EXEs is run,
> App.PrevInstance will return False when the app is run the 2nd time. It's
> not common to run into this situation, but it can happen.

> --
> Mike



Sun, 11 Mar 2012 11:48:01 GMT  
 Single Instance Limit
MikeD,

I have a second question if three instances of an APP runs and the first to
run [ App(1)] finds APP.PreviousInstance = False, and so continues to run;
then App(2) & App( 3) start (in that order) if 2 & 3 both find
APP.PreviousInstance = True will App(2) be the first to see
APP.PreviousInstance = False.  In otherwords will the run order of 1 then 2
then 3 be preserved?

X.

Quote:



> > Is there a way to compile a VB6 app so that it can only run as a single
> > instance under XP?

> It's not a matter of compiling.  It's a matter of writing code to handle it.
> It's also not a matter of "XP" versus another version of Windows. If you
> write this into your app, that's the way it's gonna be under XP, Vista,
> Win7, Win98, etc (unless, of course, you write code to deal with each
> version of Windows, which wouldn't be too difficult).

> Quite simply, when your app starts (in Sub Main or the Load event of a form,
> whichever you have set as your startup object), check App.PrevInstance. This
> will be True if the
> app is already running.  You can do this in a form's Load event, but Sub
> Main is a much better place to perform such a check (before you even load
> any forms).

> However, there is a gotcha. App.PrevInstance only "works" if the app is
> started again from the same folder. So, if there happens to be 2 copies of
> your app's EXE file in different folders, and each of those EXEs is run,
> App.PrevInstance will return False when the app is run the 2nd time. It's
> not common to run into this situation, but it can happen.

> --
> Mike



Sun, 11 Mar 2012 11:56:01 GMT  
 Single Instance Limit
Hi Gaanam,

L is the app that needs to be a single instance, and further more the run
order needs to be maintained.  In other words for the run order of a then b
then c, each must wait in that same order to launch their respective versions
of L.

It appears that placing APP.PreviousInstance at the beginning of L, may
solve the problem.  The only remaining question is if a starts an L, then b
launches an L, and then c launches an L the b & c instances of L should find
APP.PreviousInstance = True; so far so good, however will b be the next to
see APP.PreviousInstance = False, followed by c after b's instance terminates?

Quote:


> > First a starts L, while L is running b wants to start L, but I want b to
> > wait until L terminates.  There is also the possiblity that after a starts L,
> > both b and c may run an try to start L.  I have tried coding a, b & c to look
> > for a captioned form in L, by looking for its handle, when L terminates the
> > handle = 0.  But, some how multiple instances of L still seem to get executed.

> Your description of the architecture is fairly confusing..
> 'First a starts L' implies a is already running before L is started..
> So a should be the startup. Right?
> again you say 'while L is running b wants to start L'. Seems like you
> are explicitly starting another instance of L and so oning
> Clearly you are playing a loop game of various exe's so nothing
> unusual  'multiple instances of L still seem to get executed'

> Out of a,b,c,d and L Which one you want to restrict as single
> instance?



Sun, 11 Mar 2012 12:07:01 GMT  
 Single Instance Limit


Quote:
> Hi Gaanam,

> L is the app that needs to be a single instance, and further more the run
> order needs to be maintained.  In other words for the run order of a then
b
> then c, each must wait in that same order to launch their respective
versions
> of L.

> It appears that placing APP.PreviousInstance at the beginning of L, may
> solve the problem.  The only remaining question is if a starts an L, then
b
> launches an L, and then c launches an L the b & c instances of L should
find
> APP.PreviousInstance = True; so far so good, however will b be the next to
> see APP.PreviousInstance = False, followed by c after b's instance
terminates?

I'm wondering if maybe you should look at re-working the programs into
having a "L" that launches an 'a', then 'b', then 'c'.

  L opens
      Launches 'a'
         Waits for return
          Does what ever it needs to do to complete 'a' stuff.
      Launches 'b'
         Waits for return
          Does what ever it needs to do to complete 'b' stuff.
      Launches 'c'
         Waits for return
          Does what ever it needs to do to complete 'c' stuff.
  L closes

That way you only have one "L" and a, b, and c alway run in order.

-ralph



Sun, 11 Mar 2012 12:28:12 GMT  
 Single Instance Limit
Not possible, L is the main app, to which a, b, and c passes information.  
When I refer to order, I'm referring to the order of the instances of L.  
It's possible the the launch order of the other apps might be b, a, c, in
which case the instances of L need to run bL, aL, then cL.
Quote:



> > Hi Gaanam,

> > L is the app that needs to be a single instance, and further more the run
> > order needs to be maintained.  In other words for the run order of a then
> b
> > then c, each must wait in that same order to launch their respective
> versions
> > of L.

> > It appears that placing APP.PreviousInstance at the beginning of L, may
> > solve the problem.  The only remaining question is if a starts an L, then
> b
> > launches an L, and then c launches an L the b & c instances of L should
> find
> > APP.PreviousInstance = True; so far so good, however will b be the next to
> > see APP.PreviousInstance = False, followed by c after b's instance
> terminates?

> I'm wondering if maybe you should look at re-working the programs into
> having a "L" that launches an 'a', then 'b', then 'c'.

>   L opens
>       Launches 'a'
>          Waits for return
>           Does what ever it needs to do to complete 'a' stuff.
>       Launches 'b'
>          Waits for return
>           Does what ever it needs to do to complete 'b' stuff.
>       Launches 'c'
>          Waits for return
>           Does what ever it needs to do to complete 'c' stuff.
>   L closes

> That way you only have one "L" and a, b, and c alway run in order.

> -ralph



Sun, 11 Mar 2012 12:47:01 GMT  
 Single Instance Limit


Quote:
> Not possible, L is the main app, to which a, b, and c passes information.
> When I refer to order, I'm referring to the order of the instances of L.
> It's possible the the launch order of the other apps might be b, a, c, in
> which case the instances of L need to run bL, aL, then cL.

I don't know squat about your problem domain, but your insistence that there
be only one L, the muddle 'varieties' of conditionals/scenarios, and now
your revelation that L is the "main app" - only strengths my belief - you've
got a cart before the horse somewhere.

You can always communicate with L using command line parameters, something
like "L.exe -abc", or "L.exe -bac", or through some other mechanism. As
perhaps there is actually another needed "business controller" that should
be running the show - the guy who can sort out the scenarios and knows the
order in which they need to run.

-ralph



Sun, 11 Mar 2012 21:23:49 GMT  
 Single Instance Limit
Some comments:

- App.PrevInstance value doesn't change. It's set at the beginning by VB
runtime and stays that way.
- Use a mutex to solve the problem. Search the newsgroups or web for "vb
CreateMutex".
- A mutex stays alive until the process terminates, unlike a form, which
maybe unloaded, but the process could still be running for a while.
- If you are running the code in the IDE, the mutex would be attached to the
VB IDE process, and this will cause problems for you. You need to test your
code in the EXE. Some of the tools that you can use is a function called
IsInIDE(Search the web), which allows you to skip code if running in the
IDE. Another tool is OutputDebugString to print debugging messages from the
EXE. Search for "vb OutputDebugString" to see how it's used, and free debug
viewer to use with it.
- Many of the CreateMutex samples use App.Title as mutex name. In your case,
use a fixed string instead because you are dealing with multiple EXE's.



Sun, 11 Mar 2012 22:32:13 GMT  
 Single Instance Limit
Thanks Nobody,

I ran into the exact problem you mentioned that App.PrevInstance doesn't
change in a test APP I wrote (See "Code to prevent multiple instances" post).

They also suggested using Mutex, and I found and example that should work
exactly for my project.  It suggests using a Mutex in an App that runs the
main App, if there are no other instances.  This is exactly what I have now,
the only difference is in my calling App, I was checking to see if the main
App form title existed [meaning an instance was running], but somehow it
still managed to launch multiple instances.

Thanks for your help.

X.

Quote:

> Some comments:

> - App.PrevInstance value doesn't change. It's set at the beginning by VB
> runtime and stays that way.
> - Use a mutex to solve the problem. Search the newsgroups or web for "vb
> CreateMutex".
> - A mutex stays alive until the process terminates, unlike a form, which
> maybe unloaded, but the process could still be running for a while.
> - If you are running the code in the IDE, the mutex would be attached to the
> VB IDE process, and this will cause problems for you. You need to test your
> code in the EXE. Some of the tools that you can use is a function called
> IsInIDE(Search the web), which allows you to skip code if running in the
> IDE. Another tool is OutputDebugString to print debugging messages from the
> EXE. Search for "vb OutputDebugString" to see how it's used, and free debug
> viewer to use with it.
> - Many of the CreateMutex samples use App.Title as mutex name. In your case,
> use a fixed string instead because you are dealing with multiple EXE's.



Sun, 11 Mar 2012 22:53:01 GMT  
 Single Instance Limit
Thanks for trying Ralph :-)
Quote:



> > Not possible, L is the main app, to which a, b, and c passes information.
> > When I refer to order, I'm referring to the order of the instances of L.
> > It's possible the the launch order of the other apps might be b, a, c, in
> > which case the instances of L need to run bL, aL, then cL.

> I don't know squat about your problem domain, but your insistence that there
> be only one L, the muddle 'varieties' of conditionals/scenarios, and now
> your revelation that L is the "main app" - only strengths my belief - you've
> got a cart before the horse somewhere.

> You can always communicate with L using command line parameters, something
> like "L.exe -abc", or "L.exe -bac", or through some other mechanism. As
> perhaps there is actually another needed "business controller" that should
> be running the show - the guy who can sort out the scenarios and knows the
> order in which they need to run.

> -ralph



Sun, 11 Mar 2012 22:54:01 GMT  
 Single Instance Limit


Quote:
> MikeD,

> I have a second question if three instances of an APP runs and the first
> to
> run [ App(1)] finds APP.PreviousInstance = False, and so continues to run;
> then App(2) & App( 3) start (in that order) if 2 & 3 both find
> APP.PreviousInstance = True will App(2) be the first to see
> APP.PreviousInstance = False.  In otherwords will the run order of 1 then
> 2
> then 3 be preserved?

I don't really know but I'd expect so.  I suppose it kind of depends. If the
VERY first thing you do is check App.PrevInstance, then it's probably
reliable. But if you're doing any processing (loading data, etc.) then that
MIGHT result in App3 checking App.PrevInstance before App2 does because
maybe App2 is loading a different, and larger, dataset than App3, so it
takes longer.

Another thing to maybe consider...if there's no harm, serious memory usage,
or anything else fairly detrimental if there are multiple instances of your
app running, then don't worry too much about preventing it. Eventually, the
user will likely see it's running twice (or 3 times) and close the other
ones.

--
Mike



Mon, 12 Mar 2012 03:58:33 GMT  
 
 [ 21 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Limit to single instance of an Access database

2. Limit to single running instance - how?

3. How to Limit an VB Application to a Single Instance

4. Multiple Instances or Single Instances

5. Sql search inside a single txtfield with comma limited string(DAO 3.51)

6. Limit a custom control to a single web site

7. Limiting program to a single execution

8. Updating unexposed field on single instance of recurring appointment

9. HowTo: Single Instance Application

10. Opening single instances of MDI Children

11. Converting to Single-Instance App

12. Running single instance of VB program

 

 
Powered by phpBB® Forum Software