🚀 go-pugleaf

Never mind, figured it out...

//typedef *thdThread PThread;
PThread SecondThread;

SecondThread = new thdThread(true);

//do something
SecondThread->ThreadName = "Test" + IntToStr(x);

//add it to the threadlist
ThreadList->Add(SecondThread);

//make a TList
TList *List = new TList();

//Assign the contents of the TThreadList to it
List->Assign(ThreadList->LockList(), laCopy);

//grab the thread you want
SecondThread = (PThread)List->Items[index];   //index is the index from the
TList

//access whatever you need to
Label1->Caption = SecondThread->ThreadName;

//unlock the list
ThreadList->UnlockList();

Thanks for looking and if you have any tips on this, feel free to post them
:)

Jay McVinney


"Jay McVinney" <compforce@hotmail.com> wrote in message
news:4045001f$1@newsgroups.borland.com...
> OK,
>     Silly question I suppose, but I'm running into it and haven't before.
> Normally I just throw a thread out there to execute and die off when it's
> done.  Now what I need is a thread that I can go back and talk to when I
> need to.
>
> MainProcess ->Creates thread A -> which creates thread B -> which creates
a
> new external process
>
> The basic code would look like
>
> ----------------------------------------------
> OnAnEvent()
> {
> TThreadA *ThreadA = new TThreadA(true);  //create a suspended thread
> ThreadA->ThreadName = ThreadName;  //unique name for the Named Thread
> ThreadA->Resume();
> };
> OnAnotherEvent()
> {
> //this is where I need to call the method from ThreadB
> };
> ----------------------------------------------------
> ThreadA
> ----------------------------------------------------
> void __fastcall TThreadA::SomeFunction()
> {
> TThreadB *ThreadB = new ThreadB(true);
> ThreadB->ThreadName = SomeName;  //uniquely named thread
> ThreadB->Resume();
> }
> --------------------------------------------------
> ThreadB
> --------------------------------------------------
>
> void __fastcall TThreadB::Execute()
> {
> bool RunIt=true;  //actually a __thread variable, just put it here so the
> code made some sense
>
> RunThread();
> while (RunIt)
> {
>     Sleep(1);
>     Application->ProcessMessages();
>     pid = pi.dwProcessId;
>     tid = pi.dwThreadId;
>     GetExitCodeProcess(pi.hProcess, &dwExitCode);
>     if(dwExitCode==0 && RunIt){
>
>     RunThread();    //restarts the process if it dies
>     };
>
> };
>     CloseHandle( pi.hProcess );
>     CloseHandle( pi.hThread );
> }
> //--------------------------------------------
> void TThreadB::RunThread()
> {
>     ZeroMemory( &si, sizeof(si) );
>     si.cb = sizeof(si);
>     ZeroMemory( &pi, sizeof(pi) );
>
>     // Start the child process.
>     if( !CreateProcess( NULL, // No module name (use command line).
>         "notepad.exe", // Command line.
>         NULL,             // Process handle not inheritable.
>         NULL,             // Thread handle not inheritable.
>         FALSE,            // Set handle inheritance to FALSE.
>         0,                // No creation flags.
>         NULL,             // Use parent's environment block.
>         "D:\\WinNT\\System32",             // Use parent's starting
> directory.
>         &si,              // Pointer to STARTUPINFO structure.
>         &pi )             // Pointer to PROCESS_INFORMATION structure.
>     )
>     {
>         //nothing started
>     }
> }
> //----------------------------------------------
> void TThreadB::MethodThatIwantToCall()
> {
> //do something with the process here
> };
>
>
>
> So, I find all kinds of documentation on threading and calling a child
> thread from a main thread, but I can't seem to find out how to pass that
> handle from the intermediary thread back to the main thread.  i.e. say
that
> I have 5 threads, each with a copy of notepad running and I want to send a
> command to the third instance of notepad, how can I find the correct
handle
> to do so.  It appears that this is not covered by TThreadList, which is
what
> I was trying to use for managing the thread pool.  Note that the above
> information has been scaled to make the idea of what I am trying to do
much
> less complicated.  There are definitive reasons for the threads to be
> created in this manner.
>
> TIA
> Jay McVinney
>
>