> francesco perillo > Inviato: venerdì 23 aprile 2010 13.38 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Re: someone uses hbqt for "business" > applications ?
> Personally, I did some tests in the past with hwgui and used the text > based coordinates as multipliers of font height and width... > WIDTH value can be calculated... code can be taken from the GET > system, since it calculates the screen area to use... just multiply by > font width.. I agree, but only if the coordinates are referred to the current form, and not to the absolute screen as i think Lorenzo was meaning. So, a great effort is needed to describe the widgets in form (and not screen) based coordinates, as you know i'm doing yet in Clipper apps. > PICTURE are a problem since there is non compatibility with Qt... I > don't use complex picture string, just some "@!"... > VALID and WHEN are a completely diffent subject since you have to > create a layer that handles object focus... more, I did not understand > if there is already a system (hbxbp???) to interface memory variables > with "widgets" > Example, setting a variable value inside a widget is "easy"... but > then the widget must set the new value back, possibly in a clipper > compatible way.... I think that hwGUI, hbXBP and other similar libraries Clipper/xBase/(x)Harbour based are more comfortable than the way hbQt could be linked to getsys construct, so a old Clipper application could be migrated with minimal or reasonable effort. > Or otherwise we should change programing paradigm, a new style of > programming, at least the screen interface... A long and winding road... Just you sent me an article about the risk of software rewriting from scratch... > > And what about tbrowses, achoices, prompts, > > menus? Another problem of QT is the SQL based approach of the browse/grid component. If you plain to retain the dbf paradigm i don't see any simple way to employ the Qt widgets for this objects. > In the long end, it would be difficult to adapt an old application > without serious changes in the code.... Well. If you mean to port an application from Clipper style to pure GUI style, i agree. The project hitself could become very different if you take full advantage of the graphics widgets and the UI approach can't be locked to the poor CUI interface. Anyway, if your target is to have the old Clipper application to run in a 32/64bit environment and in an acceptable graphic interface, the hwGUI & C. approach, IMHO, could be a very fast and non expensive path. Better would be to have an "official Harbour GUI", but this wish is very far from the target of Harbour developers, as stated in a quite old thread... So, hbQT will be the better choice to start a new project from scratch, but for me (and, I suspect, for us) at this time isn't very useful as i need to port old Clipper applications without loosing the logic and the affordabilty of the previous code. Best regards. Maurizio _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
