Originally posted by: Dante Shamest
Although your code used MFC, I was able to adapt it for my pure Win32 application.
Great work!! :D
Reply
Originally posted by: Claude Wynne
// Change the declaration for PipeData"
//TCHAR PipeData[BUF_SIZE];
// Change the call to AppendText(PipeData) :
//AppendText(PipeData);
// Change the search for "Press any key to continue"
//TCHAR *ptr = _tcsstr(PipeData, _T("Press any key to continue . . ."));
CHAR *ptr = strstr(PipeData, "Press any key to continue . . .");
I was getting garbage output. I'm running on Windows XP but it seems that the output from the redirected standard output is in ANSI not UNICODE. I made the following changes in Redirect.cpp to get it to work:
char PipeData[BUF_SIZE];
AppendText(CString(PipeData));
Thank you very much for your help on fixing the UNICODE bug. I have to spend a lot of time to search for this solution since almost programs only output to ANSI format.
ReplyOriginally posted by: Mansukh Patidar
Is it possible to redirect the GDI output?
ReplyOriginally posted by: Nathan Scherdin
I love this class. :)
ok, got that out of the way.
This class does just about everything I could want it to do however I have noticed a problem. If I try to execute a DOS program(don't know about windows) that either has a longfilename or is in a directory that has a longname the class will not execute the program.
Any help would be appriciated...please.... :)
Reply
Originally posted by: salman a khilji
this class is not able to display the results in 'real time'. I would say a simpler way to do this is to use create process and pass the arguments as something like...
c:\notepad.txt c:\txt.txt>logfile.log
and then read back that log file.
that will bypass all the extra work thru the piping.
This will allow someone to use the return codes from the child process. If anyone has figured out how to get it to display in real time, let me know.
Salman
ReplyOriginally posted by: Carrie Kimbel
Thanks for the code. It is working for me, except that the line feed characters (\n) are showing up as bars instead of actual line feeds. A line feed does occur when the edit box runs out of horizontal space. It must be something simple I'm missing. Anyone have advice??? Thanks.
Figured it out - I needed a \r\n in the console application code instead of just \n
Originally posted by: Joe Ismert
Redirect seems to only redirect messages that come from the application called and doesn't grab everythig thrown to stderr/stdout. for instance if my program calls a dll that throws messages to stdout I want those too. How can I get tehm?
ReplyOriginally posted by: Gaby
I tried your output redirection and that's great. Thanks you.
My only problem is that the Edit Control displays some extra characters after the message that is
normally returned by the spawned process (the console application). Do u have any idea of what this could be
due to?
Thanks again.
Originally posted by: Ben Burnett
To prevent this deadlock situation the waiting process can wait in a separate thread, leaving the main
window thread free to process window messages, or use the MsgWaitForMultipleObjects() API in conjunction with
the dispatching messages.
In the Run member change the folowing;
void CRedirect::Run()
if ( NumBytesRead )
if ( MsgWaitForMultipleObjects( 1, &ProcessInfo.hProcess,
//....
//...
This occurs when the waiting process is waiting in the thread that processes the messages sent to the window
(the main window thread).
{
//...
{
//...
}
else
{
//------------------------------------------------------------------
// If the child process has completed, break out.
//------------------------------------------------------------------
/*
if ( WaitForSingleObject(ProcessInfo.hProcess, 0) == WAIT_OBJECT_0 ) //lint !e1924
(warning about C-style cast)
{
break;
}
*/
FALSE, 0, QS_ALLINPUT) == WAIT_OBJECT_0 )
{
break;
}
}
}
Originally posted by: John Kiapecos
Is it possible to terminate a DOS program waiting for
keyboard input [kbhit()] without hitting a key ?