PostMessage() error

  • Thread starter Thread starter one2001boy
  • Start date Start date
Tom said:
What does it do? Just freeze for ever?

the same problem as before, the code gets into

{
fprintf(stderr, "Timeout: gnuplot is too busy\n")
...
}

That implies that wgnuplot is still busy, and is not removing WM_CHAR
messages from its message queue. That would imply that wgnuplot may be
at fault, rather than pgnuplot, assuming pgnuplot is sending the WM_CHAR
messages to the correct window (which you should check).

is there a way to wait wgnuplot not busy to send WM_CHAR message?
I have verified that the data from pgnuplot is correct, and the window
display from wgnuplot shows the messed up data after 4k data processed.
GUI apps can use stdin and stdout. e.g.
guiapp.exe < textfile.txt
will give guiapp access to textfile.txt via stdin. To use stdout, it
needs to be redirected. One simple way to redirect it is:
AllocConsole();
freopen ("CONOUT$", "w", stdout);



If guiapp.exe reads from stdin, it will pick up anything piped to it.

guiapp.exe need to hand the input from its control.

pgnuplot.exe intends to make guiapp.exe be able to handle the pipe.
if modifying the guiapp.exe to read from stdin, can it still handle the
input from its controled GUI?

thanks.
 
Ben said:
Probably a better alternative, since wgnuplot and pgnuplot source code is
available, would be to use a named pipe to transfer the data between the two
instead of PostMessage, and let wgnuplot treat it in the same way as if it
had been received by WM_CHAR. Or use a named event (the name for eitehr
method should be based on the process ID, to let multiple instances run
simultaneously, in a CGI environment for example), which is set whenever
wgnuplot's message queue is empty. Then pgnuplot could post 400 characters
and wait for the event.

I am not sure how to get started.
do you have a link for a sample code using named pipe for transfering data?

thanks.
 
Back
Top