C / C++ / MFC

baerten9-Sep-07 22:50

9-Sep-07 22:50

Thanks for help

It's more the problem if the Parent-Process dies and the child processes are still living.

If the parent process ( the GUI ) creates 5 new child processes and the windows user kills the
parent process with the TaskManager, so there are still 5 processes running and never be closed.
That's the problem

Stephen Hewitt10-Sep-07 14:37

10-Sep-07 14:37

The procedure I outlined will do exactly what you want. Here's an example:
-----------------------------------------------

// ParentChild.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <iostream>
#include <Windows.h>
#include <conio.h>
#include <string>
#include <sstream>
#include <algorithm>
#include <memory>
#include <assert.h>

using namespace std;

HANDLE GetInheritableProcessHandle()
{
HANDLE hProcess;

BOOL bOK = DuplicateHandle(
GetCurrentProcess(), // HANDLE hSourceProcessHandle
GetCurrentProcess(), // HANDLE hSourceHandle
GetCurrentProcess(), // HANDLE hTargetProcessHandle
&hProcess, // LPHANDLE lpTargetHandle
SYNCHRONIZE, // DWORD dwDesiredAccess
TRUE, // BOOL bInheritHandle
0 // DWORD dwOptions
);

if (!bOK)
{
return NULL;
}

return hProcess;
}

void SpawnChild()
{
// Get our path.
char Us[MAX_PATH];
GetModuleFileName(NULL, Us, sizeof(Us));

// Get an inheritable process handle for this process.
HANDLE hUs = GetInheritableProcessHandle();
assert(hUs!=NULL);

// Build the command line.
ostringstream oss;
oss << "\"" << Us << "\" " << reinterpret_cast<DWORD>(hUs);
string CommandLine = oss.str();

// Build a mutable version of the command line string.
char *pMutable = new char[CommandLine.length()+1];
const char *pStr = CommandLine.c_str();
memcpy(pMutable, pStr, CommandLine.length()+1);

// Launch the child process.
STARTUPINFO si = {0};
si.cb = sizeof(si);
si.lpTitle = "I am the child!";
PROCESS_INFORMATION pi;
BOOL bOK = CreateProcess(
NULL, // LPCTSTR lpApplicationName
pMutable, // LPTSTR lpCommandLine
NULL, // LPSECURITY_ATTRIBUTES lpProcessAttributes
NULL, // LPSECURITY_ATTRIBUTES lpThreadAttributes
TRUE, // BOOL bInheritHandles
CREATE_NEW_CONSOLE, // DWORD dwCreationFlags
NULL, // LPVOID lpEnvironment
NULL, // LPCTSTR lpCurrentDirectory
&si, // LPSTARTUPINFO lpStartupInfo
&pi // LPPROCESS_INFORMATION lpProcessInformation
);

delete [] pMutable; // Free the memory.
CloseHandle(hUs);

if (!bOK)
{
return;
}

// As always, close handles you don't need or are finished with!
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
}

int main(int argc, char* argv[])
{
if (argc==1)
{
cout << "I am the parent." << endl;
SpawnChild();
cout << "Press any key to exit." << endl;
_getch();
}
else
{
cout << "I am the child." << endl;

// Get the handle to the parent from the command line.
DWORD HandleValue;
istringstream iss(argv[1]);
iss >> HandleValue;
HANDLE hParent = reinterpret_cast<HANDLE>(HandleValue);

// Wait for the parent to exit or be killed.
WaitForSingleObject(hParent, INFINITE);

// Close handles you're finished with.
CloseHandle(hParent);
}

return 0;
}

Steve

baerten10-Sep-07 21:52

10-Sep-07 21:52

Ok, i see, it kills really the child processes.

But how does it work exactly?

The command, here pMutable, stores the path & exe and a specific number ( dublicated handler ) after it.

Does the child process also die because the dublicated handle is destroyed and the clone-handle
can't no longer exists and kills that way the child process?

Big thanks for you help !! Smile | :)

Stephen Hewitt10-Sep-07 22:05

10-Sep-07 22:05

The child process isn’t killed; it’s waiting for the parent process to finish (either gracefully of forcefully). A process HANDLE is a waitable object -- it becomes signaled when the process it identifies no longer exists. WaitForSingleObject waits for a waitable object to become signaled. All the DuplicateHandle stuff is to make the HANDLE inheritable so it is inherited by the child (since the bInheritHandles argument passed to CreateProcess is TRUE). The value passed in the command line is the duplicated HANDLE's value.

Steve

baerten10-Sep-07 22:27

10-Sep-07 22:27

Ok, i understand it now. Smile | :)

So i can create a thread which waits till the parent-process is dead and closes then the application.

Otherwise, if the child closes at first, i kill the Thread which waites on the handle.

Big thanks for your great help Rose | [Rose]

Stephen Hewitt11-Sep-07 19:26

11-Sep-07 19:26

That’s the basic idea. A word of warning: don’t use the TerminateThread function! See here[^] for details. A professional implementation would use the WaitForMultipleObjects function instead of WaitForSingleObject; one of the objects is the parent's HANDLE and the other an event (see CreateEvent) that you use to tell the thread to exit gracefully. Your main thread uses the event to signal the other thread to close down and then waits for it to do so using WaitForSingleObject on the thread's HANDLE.

Steve

vipin_nvk9-Sep-07 22:27

vipin_nvk

9-Sep-07 22:27

Hello

It seems if you create a process in your application using createprocess or any other API and if the parent application gets terminated forcibly (as in your case) the child process will not get terminated. For referenc refer the "Terminating a Process" section of the MSDN. To go to this topic, look into the Remarks section of "CreateProcess" API.

In the "Terminating a Process" it is clearly mentioned as "When the system is terminating a process, it does not terminate any child processes that the process has created."

However in that section they have mentioned a possibility of achieving ur requirement of terminating a child process when the parent application gets terminated.

Thanx

baerten9-Sep-07 23:49

9-Sep-07 23:49

Thanks for your help

The possibility offered by MSDN won't fix this kind of problem Sigh | :sigh:

So i think there is no possibility to work around my problem Unsure | :~

Stephen Hewitt10-Sep-07 15:57

10-Sep-07 15:57

baerten wrote:
So i think there is no possibility to work around my problem

I wouldn't go that far. See here[^].

Steve

focus in edit control

bhogavalli suresh9-Sep-07 20:03

bhogavalli suresh

9-Sep-07 20:03

i am using dialog ,in that i have an edit control,when ever my dialog displays cursor must be in the edit control,plz help me............

Nishad S9-Sep-07 20:08

9-Sep-07 20:08

You can call GotoDlgCtrl() API for that edit to set the focus. If it is in OnInitDialog, you should return FALSE.

- NS -

bhogavalli suresh9-Sep-07 20:29

bhogavalli suresh

9-Sep-07 20:29

ok fine,if it in another function ,wts the processs............

Nishad S9-Sep-07 20:32

9-Sep-07 20:32

GotoDlgCtrl itself... Smile | :)

- NS -

Wamuti9-Sep-07 21:35

9-Sep-07 21:35

tried setting it to a member of CEdit(The edit box itself ) but GoToDlgCtrl is not a member of CEdit.

Wamuti: Any man can be an island, but islands to need water around them!
Edmund Burke: No one could make a greater mistake than he who did nothing because he could do only a little.

Nishad S9-Sep-07 22:24

9-Sep-07 22:24

Wamuti wrote:
tried setting it to a member of CEdit(The edit box itself )

No... You have to call like, GotoDlgCtrl( &m_edit );

- NS -

Sreedhar DV9-Sep-07 20:33

Sreedhar DV

9-Sep-07 20:33

Set the "Tab stop" for the edit control as 1. For doing this click Ctrl+D on the resource view of the dialog. Set the edit control tab stop as 1. It is the simplest way to solve your problem. Smile | :)

Sreedhar DV

Wamuti9-Sep-07 21:25

9-Sep-07 21:25

add a member variable for that edit box e.g. "m_deEditBox" using the class wizard and set the category as a control and the variable type should change to be automaticaly CEdit.

Wherever you want to receive focus use the SetFocus() and that should do the trick
e.g. :

m_deEditBox.SetFocus();
Only make sure m_deEditBox is visible within the class you are using! Smile | :)

Wamuti: Any man can be an island, but islands to need water around them!
Edmund Burke: No one could make a greater mistake than he who did nothing because he could do only a little.

Stephen Hewitt9-Sep-07 22:03

9-Sep-07 22:03

Calling SetFocus to set the focus to a control on a dialog box is wrong! See here[^] for details.

Steve

Wamuti9-Sep-07 22:47

9-Sep-07 22:47

First, Thanks for the correction.
Second, sorry this is long but here goes;
When i tested SetFocus(), i placed it in two buttons as:

void CSetfocusDlg::OnBfirst() //first button
{
// TODO: Add your control notification handler code here
m_deOne.SetFocus();

}

void CSetfocusDlg::OnBsecond() //second button
{
// TODO: Add your control notification handler code here
m_deTwo.SetFocus();

}
and it worked just fine.

But if i am getting it right, if there is a button in a dialog, SetFocus() is reserved for the default push button, right?

This means that even if i put m_editControl.SetFocus() in OnInitDialog(), i would still not get the desired effect of setting the cursor to the Edit control(what i understand from the site you directed me and practically i have tried, so i was very wrong indeed).

Ofcourse it makes sense to use the WM_NEXTDLGCTL but i cant get the message in the class wizard. Then how do i code the handler? Please help! Sigh | :sigh:

Wamuti: Any man can be an island, but islands to need water around them!
Edmund Burke: No one could make a greater mistake than he who did nothing because he could do only a little.

Wamuti9-Sep-07 22:54

9-Sep-07 22:54

Oops

sorry, using SetFocus() won't work. But i am learning. Thanks for understanding.

Wamuti: Any man can be an island, but islands to need water around them!
Edmund Burke: No one could make a greater mistake than he who did nothing because he could do only a little.

DeviceIoControl

Waldermort9-Sep-07 19:26

Waldermort

9-Sep-07 19:26

I'm somewhat confused about this api. My local copy of MSDN aswell as the online version state that this api requires win2k and upwards. But many code samples I have found, including several here on CP, state that it can be used on win98.

What's the deal?

Re: DeviceIoControl

Nishad S9-Sep-07 20:11

9-Sep-07 20:11

In my MSDN (Visual studio 2005) it is as

Requires: Windows XP, Windows 2000 Professional, Windows NT Workstation, Windows Me, Windows 98, or Windows 95.

Smile | :)

- NS -

Re: DeviceIoControl

Waldermort9-Sep-07 20:14

Waldermort

9-Sep-07 20:14

Thanks for confirming that. I wonder why they changed the documentation? I don't suppose you could copy and paste the paramaters, just in case it has changed. Though I doubt it very much.

Re: DeviceIoControl

Nishad S9-Sep-07 20:30