holycrap

I have a graphics plotting program that doesn't have much of an 'on-the-fly' input output interface. the user either has to write a script file or has to use the limited options in the dialog boxes.
softwares like AutoCAD and the FEA software like ABAQUS, NASTRAN etc.. have a text box at the bottom of their screen thru which users can enter commands and the program outputs stuff onto an output textbox.
can someone tell me or point me to some place that tells me how to best implement this sort of thing ?

the I/O routines in my program use the iostream classes- basically reads commands from some script file and prints out stuff to some output file or cout. e.g. a typical routine would be:
void readMesh(istream*, ostream*, other arguments) {}

now, the GUI uses MFC and part of my confustion is how do i redirect all this program ouput that goes to the (ostream*) to go to a textbox in the GUI instead, without making major or atleast tedious mods to the existing code. and similarly, how do i redirect input from a textbox to go to an istream ?

is this even possible?? if not, i guess i will have to change the whole program structure, but even then i would like to know how it is implemented in the big commercial softwares like autocad so i get it right atleast this time.

thanks

kurifu

You can redirect input to an istream using the istringstream class, simply put it converts the input string generated in MFC into an inputstream.

__________________
Clifford Matthew Roche <geek@cliffordroche.com>
Web Hosting: http://www.crd-hosting.com
Consulting: http://www.crdev-consulting.com

holycrap

thanks, this is what i was looking for.
so, now i need to implement the whole textboxes and see how it all works out.

btw, do u know if there is a limit on the size of the string that an istringstream object can hold ? cos i wud expect my output textbox to have enuf text to keep scrolling on for many pages.

Eggbert

>do u know if there is a limit on the size of the string that an istringstream object can hold ?
would be a good assumption. It's also a good (ei. safe) assumption to think that streamsize is a narrower type than string::size_type because the former is signed and the latter is unsigned. You would be better off splitting the string data into pages so that you don't reach these limits.