Re: Only One Instance.
From: Jamie (jamie_5_not_valid_after_5_at_charter.net)
Date: Thu, 15 Jan 2004 02:08:57 -0800
well what ever, i have used AToms, Mutexes, MemoryFile and FindWIndow
with post backs. i can tell you that for me using custom name Main
Window Classes per APP not the default "TFORM1" that every one uses with
post back helps me grately. because it also is able to return back to
the secondary app the handle info of the original app along with what
ever else i need for it at the time.
this way i can pop the original to the front and then exist the secondary
i am sure that your way works well for what you do, i have extra
requirements on some of the code i write.
I also had to use EnumWindows, get the Handle, use PostBack function
to get the start up times and other initiated info per instant. so that
the current instant coming up would be inline with the others..
so what ever., i guess what ever way works for it is what you use..
Rob Kennedy wrote:
> Jamie wrote:
>> i always found that if you can only have one instance of the app then
>> you should Special Name the Main Form Class to something that should
>> never exist, use the FINDWIndow in the Main Source before The
>> TAPplication.initiate gets executed..
> Or, you could simply create a mutex. Advantages:
> 1. The name of the mutex has no effect on anything else in your program,
> so you can continue to name your objects however you want.
> 2. The mutex name is more likely to be unique within the system. You can
> even use a GUID.
> 3. Mutex creation is atomic. It is impossible for two processes to
> create like-named mutexes without knowing it. Creating a window, on the
> other hand, is not atomic. If process A and process B are started
> simultaneously, they might both call FindWindow before either one has
> created the window that the other process is looking for.
>> if you find the CLASS then you should use the SENDMESSAGE to that
>> handle that you have receieved with a special user message that you
>> have your app responed to .. if all of this falls into play then you
>> can be
>> as sured that you have a copy of your app running.
> But there is no guarantee that any of that will fall into place.
> When your main form is open in the IDE, it has the same class name and
> title as the form your program creates. FindWindow might find that
> window, which makes testing and debugging inconvenient. FindWindow is an
> attractive function because it's easy to use and it's easy for novices
> to understand. But it's simply not the right tool for the job.
>> there the methods that others use like CreateMutex etc.. but i found
>> that if the SENDMESSAGE works your app can return back aditional info
>> that you may want also to insure its your app and not just some fluke
>> that there is another app on the desktop running that way.,..
> Using a mutex does not preclude usage of other techniques for
> transferring control to the previous instance. However, a mutex is a
> guaranteed method of detecting multiple instances. FindWindow offers
> absolutely no guarantees.
> Besides, if the window you find doesn't return the value you were
> expecting, then you've determined that you didn't find the right window.
> But now what? You still can't conclude that no other instances of your
> program are running. FindWindow only returns one window, and it always
> returns the first one it finds.
> If you want to communicate with the existing instance of a program, then
> you can use a mailslot instead of a mutex. Like mutex names, mailslot
> names are unique on a system, so you can use CreateMailslot just as you
> would use CreateMutex. Mailslots also allow you to send information to
> the first instance, so the first instance can receive subsequent
> instances' command-line parameters.