Le 05/05/2013 12:19, Jesus a écrit : > Hi Tobi and all > > > El 05/05/13 09:00, Tobias Boege escribió: >> On Sat, 04 May 2013, Jesus wrote: >>> Recently a friend of mine reported an issue that I'm not sure how to >>> explain correctly. >>> >>> He is making a terminal program that needs to print stuff on a real >>> printer, so it needs the gb.qt4 component to get access to the Printer >>> object. But also he needs to use gb.ncurses to do some neat presentation >>> in a terminal in a kind of interactive mode. Problem arises when the >>> *Window* class in gb.ncurses collides with the same class name in gb.qt4 >>> (needed to gain access to printer functions) It seems that window class >>> in gb.qt4 surpasses the one in gb.ncurses. >>> >>> So, is it a known problem? Does anyone realized this "incompatibility" >>> when using both components at the same time? >>> Is there a way to use the printer without using gb.qt4? >>> > >> >> I never thought of using a graphical component together with gb.ncurses. I >> never intended that :-) > > Yes. The point is, how it is supposed to do printing from within > gb.ncurses without using the Printer object (found only inside graphical > components)? > > We then should need to do this through CUPS or something, doesn't it? > > The fact is my friend is trying to print a kind of report based in his > own classes that uses Draw and Paint to actually draw a report in a > drawing area when using the full program version, and the file > representing the report itself is interpreted and printed from an > stripped out version of the program that only works in console mode > (interactive curses interface). The logic of printing is the same for > both programs, so qt4 is needed to do all the stuff. Sources here [0]. > > >> [...] >> >> What do you mean actually by "surpasses"? Is there an "incorrectly >> overridden" error or does the gb.qt4 Window just override[0] the gb.ncurses >> one? If the latter is the case, you can try to disable gb.ncurses and >> Component.Load() it manually at startup? > > Right, the latter is the case. It makes them incompatible with each other. > >> >> I promise that future control classes and a future Window class (using the >> CDK) are more built like their gb.qt4 models but for now think of gb.ncurses >> as a component that conflicts with other graphical components. I don't think >> compatibility can ever be achieved, though. > > I think so, as well... but gb.ncurses programs would need to have a way > to print things. I remember old clipper database programs they were able > to print some kind of text based reports. It would be great if printing > could be based in actual drawing routines as qt4 does. But I understand > it probably never ever could be achieved. > >
Priting from the command-line with cups (a five second google search!) http://www.cups.org/documentation.php/options.html Then you "just" have to generate your report in a format understable by cups (PS, PDF, JPG mainly I think). Regards, -- Benoît Minisini ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user