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

Reply via email to