| Do you suggest a different approach?
If the code in pager.cc is close to what you want, but doesn't quite
do everything you need, then we can probably fix things so that it
will work for you. You may have to suggest changes. But I think that
would be better than duplicating much of that code on your own.
OK. So I see that octave_stdout means octave_pager_stream::stream(), which simply returns a reference to the static "instance" member, and on the first try it's allocated.
The static instance is an octave_pager_stream. Its rdbuf is set to an octave_pager_buf in initialization, which in my embedder gets overwritten by another streambuf implementation, which is what you're saying I shouldn't do.
It would in fact be possible to reuse octave_pager_buf, but I'd have to capture its output. I see it has two methods of doing output. The first is to call an external binary program and communicate to it with this external_pager->write() function. I'm assuming that external_pager, which is an oprocstream *, will fire up an external binary and communicate with it using pipes, which is probably the wrong way for an embedder. So I can't use that method of capturing the output.
As I understand, when there's no external_pager, it << to cout. In Linux, I can rdbuf the cout (although that might munge your careful buffering) but as we've been discussing, this isn't possible in MinGW. The C++ way is to add a virtual write() function to octave_pager_stream, whose default logic is something like
if(external_pager) { external_pager->write(...); external_pager->flush(); }
else { cout<<...; }
Then instead of entirely diregarding octave_pager_stream, I could subclass it and reimplement only the virtual write() function.
Of course, my reimplemented write() would ignore external_pager because I don't think it makes sense in the context of a GUI (or am I wrong?) If I'm wrong, there's the added difficulty of capturing the output of external pager and dumping it to my GUI.
I think you should look at the way user input is handled by the
functions in src/input.cc. Probably your command line should hook
into that (or use a similar method) instead of calling eval_string.
You might also get readline capability for free that way, but I don't
know for sure since I don't know the details of the way your QT widget
handles input.
I'll try to take a look. I was going too fast to pay attention to the obvious.
If there is some functionality that you need, please suggest it.
Perhaps we could have functions that return the startup messages as
character strings. At startup, Octave could print the messages that
these functions return unless it is running in embedded mode. In
That would be perfect.
User debugging/info. These messages are written if you start Octave
with the --verbose option. I think they could go to octave_stdout.
That's probably best because right now that output will not be shown by Workshop.
| toplev.cc:
| > After recovering from an exception, or when exiting, Octave prints
| > a newline character to std::cout.
I think these could to to octave_stdout, so I've made that change in
the CVS sources.