Home > Archive > Visual Basic > April 2006 > Count and/or Limit processes running ...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Count and/or Limit processes running ...
|
|
|
| Im using Visual Basic 6.0 and I dont want someone to be able to run my
program more than once. I also want to prevent them from running it from
other 'window user names' that are on their system.
How do I tell my program in Visual Basic 6 to NOT allow the same 'process'
or 'exe' to be run on the same system more than once at a time? Also to make
sure they can NOT 'switch users' and run it under a different 'windows user
name' while its running on under another name.
Thanks.
| |
| Karl E. Peterson 2006-04-25, 6:57 pm |
| Craig wrote:
> Im using Visual Basic 6.0 and I dont want someone to be able to run my
> program more than once. I also want to prevent them from running it
> from other 'window user names' that are on their system.
> How do I tell my program in Visual Basic 6 to NOT allow the same
> 'process' or 'exe' to be run on the same system more than once at a
> time? Also to make sure they can NOT 'switch users' and run it under
> a different 'windows user name' while its running on under another
> name.
The simplest way within a single login would be something like:
Sub Main
If App.PrevInstance = False Then
'do stuff
End If
End Sub
To cover all logins, I think the best you can do is leave a dropping
somewhere. The problem with that is, what if your app crashes and fails to
clean it up on exit?
--
Working without a .NET?
http://classicvb.org/
| |
|
| Thank you for the quick response. I will try what you have told me.
- Craig
"Karl E. Peterson" wrote:
> Craig wrote:
>
> The simplest way within a single login would be something like:
>
> Sub Main
> If App.PrevInstance = False Then
> 'do stuff
> End If
> End Sub
>
> To cover all logins, I think the best you can do is leave a dropping
> somewhere. The problem with that is, what if your app crashes and fails to
> clean it up on exit?
> --
> Working without a .NET?
> http://classicvb.org/
>
>
>
| |
|
| > To cover all logins, I think the best you can do is leave a dropping
> somewhere. The problem with that is, what if your app crashes and fails
> to
> clean it up on exit?
Easy peasy, the program holds the "dropping" (or "flag file") open then when
another instance tries to run it not only looks for the "dropping" but if it
finds one it tries to delete it, if the deletion fails then there is another
instance running, if it can delete it then it is crash detrius, if there is
no file then it can carry on.
Dave O.
| |
| Karl E. Peterson 2006-04-26, 6:56 pm |
| Dave wrote:
>
> Easy peasy, the program holds the "dropping" (or "flag file") open
> then when another instance tries to run it not only looks for the
> "dropping" but if it finds one it tries to delete it, if the deletion
> fails then there is another instance running, if it can delete it
> then it is crash detrius, if there is no file then it can carry on.
That's lateral thinking! I like it. :-)
--
Working without a .NET?
http://classicvb.org/
| |
| Tom Esh 2006-04-26, 6:56 pm |
| On Wed, 26 Apr 2006 16:18:30 +0100, "Dave" <nobody@nowhere.com> wrote:
>
>Easy peasy, the program holds the "dropping" (or "flag file") open then when
>another instance tries to run it not only looks for the "dropping" but if it
>finds one it tries to delete it, if the deletion fails then there is another
>instance running, if it can delete it then it is crash detrius, if there is
>no file then it can carry on.
Sounds like a "roll-yer-own" mutex to me.
One advantage with a real Mutex object (CreateMutex) is the OS will
clean up your "droppings" :-)
-Tom
MVP - Visual Basic
(please post replies to the newsgroup)
| |
| Karl E. Peterson 2006-04-26, 6:56 pm |
| Tom Esh wrote:
> On Wed, 26 Apr 2006 16:18:30 +0100, "Dave" <nobody@nowhere.com> wrote:
>
>
> Sounds like a "roll-yer-own" mutex to me.
> One advantage with a real Mutex object (CreateMutex) is the OS will
> clean up your "droppings" :-)
Do they exist cross-logins? (Never tested that one before!) If so, that's
definitely the way to go.
--
Working without a .NET?
http://classicvb.org/
| |
| Tom Esh 2006-04-26, 6:56 pm |
| On Wed, 26 Apr 2006 11:46:03 -0700, "Karl E. Peterson" <karl@mvps.org>
wrote:
>
>Do they exist cross-logins? (Never tested that one before!) If so, that's
>definitely the way to go.
Hmmm... (twiddle, twiddle)...
No, but...
YES! ...if the mutex name starts with "Global\"
Apparently same rule as TerminalServices session, at least on XP Pro
with "fast user switching" enabled.
-Tom
MVP - Visual Basic
(please post replies to the newsgroup)
| |
| Karl E. Peterson 2006-04-26, 6:56 pm |
| Tom Esh wrote:
> On Wed, 26 Apr 2006 11:46:03 -0700, "Karl E. Peterson" <karl@mvps.org>
> wrote:
>
> Hmmm... (twiddle, twiddle)...
> No, but...
> YES! ...if the mutex name starts with "Global\"
> Apparently same rule as TerminalServices session, at least on XP Pro
> with "fast user switching" enabled.
So that'd work with multiple TS sessions as well? That'd be very  ,
indeed.
And, wouldn't ya know it... It's all a matter of knowing what to google!
How To Write an Application That Supports Fast User Switching in Windows XP
http://support.microsoft.com/defaul...kb;en-us;310153
D'oh!
--
Working without a .NET?
http://classicvb.org/
| |
| Tom Esh 2006-04-26, 6:56 pm |
| On Wed, 26 Apr 2006 12:44:27 -0700, "Karl E. Peterson" <karl@mvps.org>
wrote:
>
>So that'd work with multiple TS sessions as well? That'd be very ,
>indeed.
Yeah, looks like it should.
>
>And, wouldn't ya know it... It's all a matter of knowing what to google!
>
>How To Write an Application That Supports Fast User Switching in Windows XP
>http://support.microsoft.com/defaul...kb;en-us;310153
>
>D'oh!
Cool. Looks a lot like my mutex class except I explicitly request
ownership with WaitForSingleObject after a successfull CreateMutex and
release it in class Terminate. That was way back in Win9x, but IIRC
those were only necessary to get the same behavior in the IDE.
Otherwise, since the OS cleanup is per-process, the mutex or ownership
persists with the IDE.
BTW, "Set an Existing Application Instance to the Foreground" looks
familiar too. :-)
-Tom
MVP - Visual Basic
(please post replies to the newsgroup)
| |
| Karl E. Peterson 2006-04-26, 6:56 pm |
| Tom Esh wrote:
> BTW, "Set an Existing Application Instance to the Foreground" looks
> familiar too. :-)
Despite the clever disguise of braces and semi-colons???
Gotta love it when you find those, huh? Heh...
--
Working without a .NET?
http://classicvb.org/
| |
|
| >
> Sounds like a "roll-yer-own" mutex to me.
> One advantage with a real Mutex object (CreateMutex) is the OS will
> clean up your "droppings" :-)
>
>
> -Tom
> MVP - Visual Basic
> (please post replies to the newsgroup)
Sort of, except I want it to work across a network to prevent multiple
instances opening the same database file (for an occasional exclusive task),
a mutex won't cover that and opening the database as exclusive is not on as
exclusive access is not always needed.
I also use it a a sort of "task mutex" where if one instance is doing a
certain task (eg user editor) which should be done exclusively it creates a
flag file which tells all other instances that they are not allowed to do
that task.
Also normally I have no problem with multiple instances, but I do limit it
to 5 instances. A neat trick here is to have any temporary files in a
temporary folder numbered 1 to 10 each instance using the next in sequence,
so by limiting to less than 10 instances, 2 can never conflict over the same
temporary folder and if there is a crash the program will eventually get
round to the same folder and tidy it up.
Regards
Dave.
| |
| Bob O`Bob 2006-04-28, 3:56 am |
| Karl E. Peterson wrote:
> Dave wrote:
>
> That's lateral thinking! I like it. :-)
I wrote that into a signal file class some time ago.
It's the only instance I can recall where I used freefile but discarded
the handle immediately, something like:
Open signalname for Output As (freefile)
Possibly also the only place I've ever coded "Close" with no arguments,
but I'm less certain of that.
Bob
--
|
|
|
|
|