Hi Pritpal I think that there is some misunderstanding... I'm not a native english speaker so I may be confusing some time... I will try to be more clear i n the future.
A bit about me: I was a programmer, up to about year 2000 my income was from programming. No more. I only have one copy of a big application running (started in 1986 in dBase III+) that I ported to Harbour more for a personal pleasure than for a friend request (friend, not client). So my point of view may be a bit different from who uses harbour to earn a living. I want to add that I spent really many nights on hwgui. I wanted to use it for a small program I needed for my own use and found myself involved in its development since I found more and more missing bits... implementing activeX and filling the many missing bits in the browse.... after months of work I didn't use hwgui as the "framework" because I still fell is missing something.... and it misses the most important part: there is NO documentation ! So when I read about hbqt I was curious, when I tried demoqt I become interested and when I tried hbide I become "addicted" ! So I got a couple of books from the many available on Qt and read them in a few days. There are more than 20 books listed on Amazon ! So my brain started to think that Qt could solve all my need: a multi-platform GUI, well documented, well developed, with lots of goodies inside, with lots of sample code available, tutorials, faq, etc... and most important to be used like an external library, a black-box, something that I should not work on..... but nonetheless I offered my help to trace the memory problem (till the comunication stopped) because I "feel" that Qt and hbqt is the road to go ! Sorry for the long intro but I though it was due. > I assume you have some framework in mind to achieve what you say. > Do you ? No, I don't have any framework in my mind... Qt is a framework for me. I don't want to use hbxpp or hbqtcommand at the moment... I'd like to use pure Qt. > If yes, please post the code here for review and if the group > agrees, we will follow that pattern. Also keep in mind that it must be > backward compatible. Sorry, Pritpal, I don't have any code since I don't have any framework in mind... or are you referring to the proposal to hide s_slots in the code ? I think it is a bit too early for me to modify your code, I have really basic knowledge about everything works... Infact I proposed to put s_slots in c++ code and you said that - if I understood correctly - this is not possible since multitasking applications may have different s_slots lists... Viktor proposed to hide s_slots as a VAR in QApplication (actually in TQApplication.prg) but Qt docs says: "For any GUI application using Qt, there is precisely one QApplication object, no matter whether the application has 0, 1, 2 or more windows at any given ...". I never used MT with harbour so I can't say more on the subject... >From what I understood from your message it seems that s_events is unique and so it may be hidden inside harbour class QApplication. But hiding in a VAR means you have this GC variable passed back and forth in the calls... why not keep it in C++ code ? Totally handled by Qt ? > But if you expect this overhaul from me, I am sorry, I did my level > best to reach to this level and I know how much it is difficult to > establish code flow to acheive final results something like hbIDE. > Alternatively, you can start parallel development on this segment > and send the code here. I am sure someone more conversant with > C++ will join this effort. For now I am only concentrated on hbIDE. We all say thank you for your job, we are almost all programmers here and we know and respect the work you put into hbqt and hbide. About your idea of concentrating on hbIDE... I respect it but permit me to not agree with you.... it seems to me like crossing a river during a japanese tv game show... one of the stones may be fake and the runner drop into the water... To reach your level of knowledge it will take me more than a month, too much to catch up, and I still miss all the harbour internals ! ... so my proposal is that you shortly document in some way how all the stuff is supposed to run, from a qB := QPushButton():new() to the different cases of object destruction ( qB:destroy(), qB := NIL, qB out of scope ). With this overview we have this benefits: - everybody knows how it is supposed to work - everybody can verify if it really works this way and propose changes, for example Viktor that has a more in-depth knowledge of harbour GC internals may spot some missing or inconsistent bits.. What do you think ? Francesco _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour