Hi
Viktor Szakáts wrote: > > 1) QSyntaxHighlighter is not a wrapper of QT class with same name, > but a customized Harbour version, named HbSyntaxHighlighter. > This is wrong, such special class should be added as such on > .prg level with alternate wrappers. > This may be doable but I could not find the alternative. Actually QSyntaxHilighter() is a purely virtual class and only be sub-classed, so I decided with the same wrappers. > 2) HbSyntaxHighlighter is stored in hbqt_slots.cpp instead of > local file next to wrappers. This violates separation of > components by placing local stuff to central file. > You already have done it. > 3) Same goes (with possible differences in details) to these classes: > > - MyMainWindow > - MyDrawingArea > - HbDbfModel > - HbTableView > > MyMainWindow and MyDrawingArea should be given some > more meaningful name, like HBQTMainWindow, HBQTDrawingArea. > > 4) We should define a common prefix for extended QT classes, > could be "HBQT". This means these should also be renamed: > > MyMainWindow -> HBQTMainWindow > MyDrawingArea -> HBQTDrawingArea > HbSyntaxHighlighter -> HBQTSyntaxHighlighter > HbDbfModel -> HBQTDbfModel > HbTableView -> HBQTTableView > Agreed. I will do in a while. > Of course by knowing the exact purpose of these inherited > classes, we can give them even more meaningful names, > like HBQTDbfModelXBP, or HBQTSyntaxHighlighterIDE. > Even better. > Which leads to the next point: > > 5) Why HBXBP and HBIDE specific stuff is present in HBQT? > > I know we agreed not to add C/C++ stuff to HBXBP > (and possibly not to HBIDE), but it's not solution to > trick this rule by placing HBXBP/HBIDE specific C++ stuff > to HBQT lib. HBQT is generic lib, should never contain > app specific stuff like that. > > Possible good solution is to extend wrappers in HBQT so > that such features can be implemented on .prg level. > We can think of in this direction. So far I only concentrated on functionality part. Before I achieved some results I was never sure it will work. > 6) Several functions are not marked as static, while they are. > Ok. > 7) listBlock.clear() will clear a list of PHB_ITEMs stored > in a container, but nothing ensures that these items are > actually freed with hb_itemRelease(). > May be you are right. But current implementation attempts to disconnect events and slots first and releases the codeblocks. This call simply ensure that list is "packed". > I tried to fix some of these, but it's just scratching the > surface. > I am sure for the better of this project. My zest is doubled, believe me. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBQT-problems-tp26686657p26687051.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
