Re: Pass in additional command line arguments to a single instance app
- From: Norman Bullen <norm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 25 Jan 2007 03:37:11 GMT
p19010101@xxxxxxxxx wrote:
Thanks Igor,You need to develop some sort of synchronization method to prevent more than one instance from acting as if it is the first (or only) instance.
I have later discovered that many MS apps are using DDE to pass in
command line arguments, so it must be the way to go. Unfortunately
implementing a DDE server looks awfully complicated, and if I go down
that path I will probably spend more time mucking around DDE instead of
coding the app's core logic.
Anyway, so far I've managed to get SendMessage/WM_COPYDATA working, and
it's pretty much what I wanted except that there's a minor
problem......
I added a key in the Registry: HKCR\*\shell\Open with My
App\command\myapp.exe %1, so that user can right click a file in
Explorer to send the filename to my app. The selected filename is then
passed through %1 to __argv[1]. This mechanism works fine if only 1
file was selected. However, if multiple files were selected, say 5,
Explore actually calls my app 5 times passing in 1 file at a time and
some files were skipped.
I think the problem is that the 1st instance was still creating and not
yet ready to receive the message. So I added a Sleep just before
SendMessage, this patches the problem but introduces unnecessary delays
for all subsequent calls to my app.
Am I doing something wrong? Is there a way to ensure a message was sent
and received succesfully (other than sending back an ACK)?
Cheers!
I use the existence of a window with a particular class name as the indicator that a "first instance" is running. (I use a GUID which is unique to each of my applications as the class name.)
To prevent two instances from trying to start or exit at the same time, I use a mutex, coincidentally with the same name. An instance can not start (create the window), exit (destroy the window), or check for existence of the window unless it can acquire the mutex. The first instance must create the window before releasing the mutex.
If an instance starts, acquires the mutex, and then finds that the window exists, it must ensure that the first instance does not terminate without recognizing that this subsequent instance tried to start. It does this by posting a special message to the window. (This message can be the mechanism to convey command line parameters to the first instance as well.)
Before the first instance can destroy the window, it must acquire the mutex. Then it checks for any of these special messages using PeekMessage(). If there are none, it can destroy the window and terminate which releases the mutex. If there is one or more of these messages in the queue it must not terminate.
The special messages can arrive at any time. In your case it sounds like you would simply add a "work item" to a queue to be processed by the first instance. Other applications might need to load a new document that was named on the command line of the second instance.
Norm
--
--
To reply, change domain to an adult feline.
.
- References:
- Pass in additional command line arguments to a single instance app
- From: p19010101
- Re: Pass in additional command line arguments to a single instance app
- From: Igor Tandetnik
- Re: Pass in additional command line arguments to a single instance app
- From: p19010101
- Pass in additional command line arguments to a single instance app
- Prev by Date: Re: NT Service Executable Change - System has memory of previous one?
- Next by Date: Re: Regular Expressions in VC++
- Previous by thread: Re: Pass in additional command line arguments to a single instance app
- Next by thread: Re: Pass in additional command line arguments to a single instance app
- Index(es):
Relevant Pages
|
