Piping problem

[boaz]

I’ll try to explain my problem, bear with me

I’m working on a windows version of SE (windows 7 32-bit to be exact)
I have a macro that runs a shell program, lets call it X, and using pipe to catch it’s output,
using the following syntax:
PIPE_INFO pipeInfo;
pipeInfo.processHandle=_PipeProcess(X, pipeInfo.processStdoutPipe, pipeInfo.processStdinPipe, pipeInfo.processStderrPipe,"");

On the new version of program X, the program calls anohter program (a java_launcher), let’s call it program Y where all the interesting stuff is happening
When I run the macro, I get a cmd window with the java_launcher, nothing on the pipe and in the end a cmd window that needs to be closed manually.

The reason I’m asking this question here, is because when I run program X from cmd (with the exact same syntax), I see the output of Y in the cmd as if it is still the same command (and no indication about the double processes).
Maybe there is a way to make SE pipe to do the same? Maybe a flag I should use? something else?
(the documentation for PipeProcess is scarce)

[chrisant]

The reason I’m asking this question here

Sorry to be dense, but there were no question marks yet, and my natural language parser has trouble in the mornings:

Are you asking why X's pipe isn't capturing Y's output?
Or how to make SE not capture piped output from sub-child processes?
(Or something else?)

[boaz]

hmm...
I see what you mean - from all the detailed descriptions I didn't clearly state what I want.
I want my macro to behave like in the previous version.
meaning, be able to read from the pipe the data that is now the output of program Y, and not see another cmd pop up.

[chrisant]

I think you're saying:
- Your macro hasn't changed.
- You haven't changed versions of SE.
- You upgraded from ProgramX v4 to ProgramX v5.
- ProgramX v5 works differently in your macro than ProgramX v4 did.
- You want to figure out how to get your macro to give the same results with X v5 as it used to with X v4.

Right?

The only hits that Google shows for "PIPE_INFO _PipeProcess" are this thread.
What language are you using, and what SDK is that from?
Which program is doing the PIPE_INFO stuff -- your macro, or ProgramX?

Anyway, this sounds like ProgramX changed how it spawns new the child process for ProgramY.  Off the top of my head some possibilities include:  maybe it doesn't pass the handles anymore, maybe it doesn't duplicate them properly, maybe it forced creation of a new console window, maybe ProgramY forced creation of a new console window.

If you have access to source for ProgramX v4 and v5, can you compare how they deal with piping?  Or maybe PIPE_INFO and _PipeProcess are private functions inside ProgramX and their implementation changed and introduced a regression?

[Graeme]

Looks like _PipeProcess is a slickedit built-in function.

Have you seen the _PipeShellResult function or is that what you're already using?
Have you tried the "C" option in the fifth parameter?

What do you mean by this?
<quote> I want my macro to behave like in the previous version.</>

Previous version of what?  Previous version of slickedit?  Previous version of program X?

<quote>On the new version of program X ... </>
If program X is the thing that changed, why do you think that you can solve the problem by changing your slickedit macro?

[boaz]

some answers:
1. previous version of program X
2. Because when I run program X in the command line and not getting multiple window, I assumed that I can make slickedit macro behave the same.
3. _PipeShellResult is not suitable because program X (now program Y) has a lot of output and has a rather long process which I present async. in a log window inside slickedit

And on the same note, what solved the problem was running _PipeProcess with 'C'. It is ugly because it opens a console
but it gives me the output of program Y. If I put 'H' in the parameter I get the same result as putting ""

Thanks Gereme, you solved my problem!

If anyone else has a different solution (that will be pretty - not opening a blank cmd), please let me know.

[Graeme]

2. Because when I run program X in the command line and not getting multiple window, I assumed that I can make slickedit macro behave the same.

Which command line - the slickedit command line or a Windows console?
If you run program X async. how do you know when it has completed?

Have you tried both "C" and "H" options together?

You could create an external program that wrote the data to a temporary file, and call it using the "shell" function and notify slickedit on completion by invoking vs.exe -#your_macro_name

[boaz]

Yay! running it with "CH" solved the thing!

by the way, as to your question how do I know it finsihed, I'm activating a timer and checking for _PipeIsProcessExited periodically. A bit old school polling, but it's sufficient for my uses...