Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

PipedProcess usage?

(1/3) > >>

dmoore:
Hi CBers. I want to use the PipedProcess class (defined in the SDK) to execute some console commands and capture the input/output in the Interpreted Languages plugin that I've been working on. I can't figure out what I'm supposed to pass to as the first argument to the constructor. From the SDK:


--- Code: ---PipedProcess::PipedProcess(void** pvThis, wxEvtHandler* parent, int id, bool pipe, const wxString& dir)
    : wxProcess(parent, id),
m_Parent(parent),
m_Id(id),
m_Pid(0),
m_pvThis(pvThis)
{
wxSetWorkingDirectory(UnixFilename(dir));
if (pipe)
Redirect();
}
--- End code ---

so what should I be passing as pvThis? Just an uninitialized pointer?

Game_Ender:
A better question is why is there a void pointer in the API?  You should probably do a search on the CB source code and see how Mandrav uses it.  Then possibly submit a patch that adds the proper doxygen comments to the headers.

EDIT- Improved my bad grammar.

dmoore:
yes, I agree it is very ugly. It looks like the PipedProcess is just a bit of a hack around the limitations of wxProcess to get the debugger to work. I would need to study the code much more carefully to get a good handle on it, which would have to wait till a later date (I suspect Mandrav would have a far better understanding of this issue :D ). In any case, after inspecting the DebuggerGDB plugin code, I think I've figured out that I just pass a pointer to the newly instantiated piped process object to get the process instantiated correctly.

But now I'm not sure about how to read from stdout at progressive intervals. I saw that DebuggerGDB handles EVT_PIPEDPROCESS_STDOUT messages, but I also noticed EVT_IDLE and EVT_TIMER message processing as well. Do I need all three of these message declarations (and assocaited handlers) to receive output correctly?

Game_Ender:
I have not looked at the code, but my guess that is that there might be a timer in PipedProcess that checks to see if the process has written anything to stdout and if so generates an event.  But if you want things quicker you can poll the PipedProcess your self and gather the input.  My guess is Mandrav started out with just listening to the events, but then to improve response time in the debugger added processing in the idle event and another timer loop.

Buts that just a guess, more digging through the class will be needed, but I have to finish my CS project. (Linked lists in C are boring).

mandrav:

--- Quote ---I can't figure out what I'm supposed to pass to as the first argument to the constructor.
--- End quote ---

The first parameter takes a pointer to the PipedProcess* variable you are just creating. You can pass NULL if you want, but I wouldn't advise it. The reason it's there is because when the piped process closes its handles, your variable (in your code) gets NULLed automatically. Perhaps some pseudocode will help explain better:


--- Code: ---wxProcess* myProcess = 0;
myProcess = new PipedProcess(&myProcess, blah, blah);
...
(process executes, you get data, etc)
...
(now you want to send a command through the process)
if (myProcess)
    myProcess->SendString(_T("break main.cpp:8"));
...
(if the process had died, myProcess would have been nulled automatically)
(else the call proceeds)

--- End code ---

As for it being void**, well, that's because you could actually put any pointer there you would like nulled when the process dies. You might put there a pointer to char* if you like: PipedProcess doesn't care. It will still null it.

Navigation

[0] Message Index

[#] Next page