|
I have 1 exe which needs to call another exe, passing some data.
How best to call another exe within my first exe?
|
|
|
|
|
PROCESS_INFORMATION pInfo;
STARTUPINFO sInfo;
DWORD exitCode;
sInfo.cb = sizeof(STARTUPINFO);
sInfo.lpReserved = NULL;
sInfo.lpReserved2 = NULL;
sInfo.cbReserved2 = 0;
sInfo.lpDesktop = NULL;
sInfo.lpTitle = NULL;
sInfo.dwFlags = 0;
sInfo.dwX = 0;
sInfo.dwY = 0;
sInfo.dwFillAttribute = 0;
sInfo.wShowWindow = SW_SHOW;
if (!CreateProcess(NULL, "path\\second.exe",
NULL, NULL, FALSE, 0, NULL, NULL, &sInfo, &pInfo))
{
printf("ERROR: Cannot launch child process\n");
exit(1);
}
Cheers
|
|
|
|
|
I can think of three ways:
1) Use Shared memory
2) Passing a WM_DATA message to your rxing applications window (This also works for passing data between 16 & 32 bit apps).
3) Make the rxing exe a COM server.
What's your level of expertise?
Do you need more info or is this enough to get you started?
"You can lead a horse to water but a pencil has to be lead"
|
|
|
|
|
Oops, forgot to ask the obvious question (Just saw Prasanth's post  )
Do you need to pass the data at application launch? (Prasanth's solution) or at run-time? (my suggestions)
|
|
|
|
|
I would like to see sample code on Prasanth's solution.
What if I need to pass an object, from 1 process to another. Is my object Thread-Safe or do I need to sync data?
I'm use to COM DLL's running under MTS & some connection points experience.
Cheers for all the help!
Gerry.
|
|
|
|
|
Hi Gerry, I need to know a few more things to be able to help.
Re: I would like to see sample code on Prasanth's solution.
It's there in his post. Prasanth is spawning a process from another process. Is this what you want to do?
Re: What if I need to pass an object, from 1 process to another.
C++ object?
COM object?
OS handle object?
Binary data 'object'?
Other(?)
Do you pass the object at from one process to the other when the second process is started?
or..
Do you pass the object when the second process is already running?
Re: Is my object Thread-Safe or do I need to sync data?
Depends on the object (See last comment) and on what you intend to do with it.
If you can describe what exactly you want to do, I will be hopefully be able to give you some better advice.
|
|
|
|
|
It's a C++ object. I want to learn more about Calling another Exe from my main exe, then letting it carry out some task, & then returning.
I would passbyref the object when the second process kicked off.
Not sure to create a new process or spawn another Thread & sync the data. Multi-threaded.
Cheers for everything.
Gerry.
|
|
|
|
|
OK, that's clearer.
If you call into another process from another process, you have two address spaces.
What this means in reality is this. You have a pointer to an area of memory (a C++ object for example). This pointer has a physical address, say 0x1000000 which is meaningful *only* in the address space it is created in. So if you have a separate process to which you pass this C++ object pointer to and try to de-reference it, then it will not point to the object you want.
This is why you need the shared-memory approach.
Of course, you have to come up with a way of calling a function in another process first using some form of IPC. (Into the realms of COM here).
In fact, that's what COM out-of-process servers are designed for.
NOTE: You can expose the C++ object as shared memory between two processes, but you still have to thread synch because two threads are (potentially) using the same memory concurrently.
If you want to create a separate thread in the same process then pass a C++ object by reference (pointer) then that's the simpler solution. You still have to synch access on the data (the C++ object's methods and attributes) though.
My advice, do the in-process (two threads in same address space) approach first, with thread synchronisation, then migrate the code to calling cross-process later.
|
|
|
|
|
Cheers Mick,
That makes everything clearer. I appreciate all the advice you have given me.
I'm going out to buy Advanced Windows for NT, J. Richter...I think it has great coverage of processes & threads..
Thanks.
Gerry.
|
|
|
|
|
I want to make a control that like a Grid that can provide the function of
setting columns and rows, changing selection by just pressing up, down, left
or right arrow keys. Is that the CListCtrl can do so?
Thanks !
Vickie
|
|
|
|
|
check out the mfc grid control here on codeproject ... its way cool
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hi,
Can I replace a record in a databse through ADO knowing only the index o the record to be replaced?
|
|
|
|
|
if you have read/write access to the db you can get the record's primary key from its index and perform an UPDATE on the record replacing the bits of info you want to change
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
error LNK2001: unresolved external symbol "unsigned short __cdecl ABC_EventLk(unsigned long,unsigned long)" (?ABC_EventLk@@YAGKK@Z)
error LNK2001: unresolved external symbol "unsigned long hABC_Wnd" (?hABC_Wnd@@3KA)
fatal error LNK1120: 2 unresolved externals
************************************************************************************
Does anyone know what these error messages mean? and how to fix this bug?
|
|
|
|
|
It means the ABC_EventLk function is in a class not included in the project, or a lib not linked into the project.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Does anybody know how I can force my MFC-Dialogbased-Application to be opened
only once. No second instance should be possible.
I tried it with a flag
BOOL MyInstance = FALSE;
in the InitApplication() - and in the InitInstance() I wrote
if(!MyInstance)
{
MyInstance = TRUE;
CZones dlg;
m_pMainWnd = &dlg;
dlg.DoModal();
}
I thought that InitApplication() is called only once and every further Instance is just
calling InitInstance(). But it looks like every Instance is also calling InitApplication()...
Any Ideas ?
Manfred
|
|
|
|
|
manfred ... the win32 apps all run in their own process space so they dont get to see the others and the concept of a global flag across all instances doesn't hold
what you should do in the initinstance (or what i would do) is use the enumerate thru all the active windows and see if another instance of your app is in the list ... if it is just terminate gracefully from the second instance
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
And how can I enumerate through all active windows?
Any function() available?
Manfred
|
|
|
|
|
EnumWindows() will go thruogh any top level windows in the system and call a user-supplied callback function passing the window handle of each active window ... from that you can get the window title and check against your app name
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hi,
here is a another way to check out if your application is already running.
I used this in my API-code but it should also run in MFC.
First create a mutex-object on startup.
-> CreateMutex(NULL,true,"SomeName");
Than ask about last-error
-> if( GetLastError()==ERROR_ALREADY_EXISTS)
{
// do exit stuff
}
Hope it helps
Mario ///
----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------
|
|
|
|
|
i always used to get worried in case my app terminated abnormally and left a dangling mutex (not a pretty sight let me tell you) so i opted for a more 'passive' approach
prolly just me being paranoid
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
Hi,
first of all the function CreateMutex() returns a handle to an object when creation succeeds. On the other side the mutex-object will be created by the process which started first. Calling CreateMutex with same "Name" again won`t succeeds because it already exists so the worst case is to have 1 object at the same time and no more.
Mario ///
----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------
|
|
|
|
|
> so the worst case is to have 1 object at the same time and no more.
I think Lauren is trying to say that if your app AbEnds, and leaves the Mutex active, other instances of your application will not be able to launch, as they will see that the Mutex is active, and will not come up.
A fix is to combine the Mutex with the "Window Search": Check for the Mutex, and then search for your app's window by it's *Window Class*. Then:
o If you find the window, use ::SendMessageTimeout(...) to see if your app is not hung. If it responds, use that window handle to bring the app to the foreground (always a good idea, so the user gets some feedback).
o If you find the window, but your app is hung, you can do whatever you want (kill it and relaunch, wait for it, etc.).
o If you do not find the window, your app likely AbEnded, and left the Mutex lying around. You can then launch another instance.
Peace!
-=- James.
|
|
|
|
|
>>I think Lauren is trying to say that if your app AbEnds, and leaves the >>Mutex active, other instances of your application will not be able to >>launch, as they will see that the Mutex is active, and will not come up.
Yes in fact you`re right. That´s a point I haven`t thought about. The question is what will happen with a mutex-object which owner is no longer running ? Is it still reserved or is it free to get ? That`s worth a try I think.
Mario ///
----------------------
www.klangwerker.de
mario@klangwerker.de
----------------------
|
|
|
|
|
> The question is what will happen with a mutex-object which owner is no longer running ?
The documentation says that the handle to a created/obtained Mutex object is automatically closed when the process terminates. I am not sure if that includes abnormal termination. I am *fairly* certain I have had Mutex objects get "orphaned" on me in the past.
But the thing I would concerned about is not really abnormal termination of your process, but your process trying to shut down, but cannot, because of a rogue/blocked thread, or something like that. You app will *appear* to have shut down to the user, but will still be sitting in the background someplace. Of course, you should try to prevent stuff like this from happening, but Sh*t Happens! 
MSDEV tends to do that to me at least twice a day (goes to sleep in the background after a shutdown)!
Peace!
-=- James.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
