> francesco perillo > Inviato: sabato 24 aprile 2010 8.52 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Re: someone uses hbqt for "business" > applications ? > > 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... >
I think better to go step by step. Only if we can obtain a working xbp layer, we'll can build a hbqt layer on it. The direct hbqt approach is very hard for me and could result in a no way direction. I'm ever targetting to port old Clipper code. Maybe if you unlink this need (as hbIDE project), starting from scratch could be useful in hbqt direct approach. > 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...) > A layer taking count, in a little modifed getsys (mainly reader), could take in charge the event polling. You know how this was made in hwGUI approach and how this way we mimic the readmodal using graphic controls. > 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's absolutely needed to link the coordinates of the controls to the current form and not to the screen. > We can think about a "compatibility layer" and base it on hbxbp or > directly on hbqt... I vote again for test before the hbxbp layer. I'm architect. Never build the upper floors on a unsure foundation. About the direct path i'm very dubious. > > I don't think it would be a hard job... hwgui already has > such layer... Yes. We knows that. Best regards. Maurizio _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
