> I've nothing against hbqt. > The discussion is about using it to create business apps and I pointed > one problem: many here have a lot of C5x CUI code to convert and hbqt > does not help.
It is not its job ! hbqt maps the Qt classes, and it's something we must have. Also hwgui/minigui have such classes but in hwgui case (I didn't study minigui code) they are a mess, since a class maps a windows objects WITH clipper behaviour.... hbqt is better on this front, since a QLineEdit works like a documented QLineEdit widget. And then you can have hbxbp on top, that encapsulates QLineEdit in a xbpSLE, a bit misleading name, but with written documentation and some sample code. We can think about a "compatibility layer" and base it on hbxbp or directly on hbqt... >> This is the main problem of >> every GUI library. We tend to forget the basic differences of >> CONSOLE and GUI way of programming flow - program controlled vs >> user controlled. We can mimic the CUI calls to present the interface >> but we _cannot_ mimic the CUI like behavior, viz., ReadModal(). > > Here I disagree. Me too, . But for example in CUI applications with no mouse enabled you were forced to enter all the on-screen fields (*) so that you could use VALID/WHEN for side-effects jobs like moving record pointers, setting variables, etc. With the mouse, you can jump from field to field... in windows users expect that disabled fields are grayed (WHEN condition= false) and not just skipped so that you should evalutate the conditions not just when entering the field (but it can have side-effects...) > I have a Fivewin version of my apps since 1998 and I'm still selling > it. I don't know fivewin > It has been relatively easy to reach the point where menus, forms > and tbrowses are "shared" between the CUI and GUI. Clearly it required > some classes, some PP and also some changes in the FW classes code but > since FW has SAY/GET and TCBROWSE classes it was not so hard. Is your code using @ GET, or is data-driven based ? In the first case the only way to go is with PP (like Massimo has shown) and some glue classes, in the second case it can be easier (can be, Maurizio warned about possible coordinates problems) It would be nice to see two screenshot of the same form of your application, one from CUI and the other from fivewin... > Result: I can build the same app as CUI or GUI simply defining a > __DOS__ or a __WIN__ macro at build time. > The main point is that FiveWin was "planned" as a convertion tool for > C5x code while hbqt is a direct wrapper of C++ classes. > > IMHO hbqt needs a "compatibility layer" towards C5x UI components ( > and it can't be XBP for the reasons I already explained many times > before ). We can think about a "compatibility layer" and base it on hbxbp or directly on hbqt... I don't think it would be a hard job... hwgui already has such layer... Francesco (*) I modified the getsys.prg so that when the user presses page-down all when/valid conditions of following fields are checked _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
