> I think, due to mailing-list problems not my all mails
> are populated, and you committed without knowledge of
> internal working of HBQT and HBXBP.
I'm trying to split HBXBP from HBQT, while you insist
on creating internal dependencies between them.
>> 2009-12-17 22:21 UTC+0200 Viktor Szakats (harbour.01 syenar.hu)
>> * contrib/hbqt/hbqt_misc.prg
>> * contrib/hbide/hbide.prg
>> - Deleted hack which moved HBXBP specific functionality
>> into the core of HBQT.
>>
>
> I am still trying to understand how this can be termed as a HACK.
Yes, please read my prev mails. It's a very simple concept.
Layering, standard interfaces.
From lower to highest:
OS <- Harbour + QT <- HBQT <- HBXBP <- apps (f.e. HBIDE)
Lower layers _do not_ know about upper layers.
They don't call them, they don't implement parts
of them, they don't even know they exist. Each
layer provides a _standard_ interface, and this
interface is used by higher layer to call into
lower layer. Period. No tricks, no exceptions,
no mixing of components, no adding of HBXBP_WHATEVER
to hbqt.ch header. Anything else is a hack, and
an ugly one. If you can't see that I'm sorry, but
can't really add too much to it. Maybe someone else
will.
>> I had to restore QT_PTROFXBP() macros inside hbide.
>> QT_PTROFXBP() has not much to do with QT_PTROF() as the
>> former serves to access oWidget member of passed class.
>> I see no need to move such logic into HBQT core code.
>> I restored QT_PTROF() also, but it's redefined as a dummy
>> in hbide.prg. I don't understand now why QT_PTROF() works
>> as dummy in hbide, but it doesn't when used as dummy in
>> HBXBP.
>> All in all, this means the .prg level :pPtr trick is still
>> needed in some places, while it's not needed in some others.
>>
>
> You introduced these lines in hbide.prg:
>
> // HACK HACK HACK
> #undef QT_PTROF
> #define QT_PTROF( oObj ) ( oObj )
>
> // HACK HACK HACK
> #undef QT_PTROFXBP
> #define QT_PTROFXBP( oXbp ) ( oXbp:oWidget )
>
> But why did you do so?
First one is because you removed all QT_PTROF*() macros
altogether, and when I restored the previous version of
hbide.prg to get back QT_PTROFXBP() macro, I also restored
QT_PTROF() macros, so instead of removing them again, I
temply added this dummy macro. The reason I didn't re-remove
them is because I couldn't find a consistent rule for this
macro, f.e. HBXBP breaks if you remove it, all test code
still has them. So, I kept it there as dummy until things
are cleared up.
Partly the same story for QT_PTROFXBP(), but in this case
I needed to restore :oWidget trick to make it possible to
remove this HBXBP specific solution from HBQT, which is
one layer _below_ HBXBP, so it should never, ever have
any XBP specific stuff hard-wired in it.
> And again you restored QT_PTROF() macro in the code,
It's a dummy. Pls, if you commit something, try to
keep whole SVN consistent. QT_PTROF() macros is still
used in HBXBP code, HBQT test code, HBXBP test code,
so it's not possible to tell whether it's needed or not.
You removed it from HBIDE only, I converted to a dummy:
same thing. I can delete it, but this won't answer why
it's used inconsistently ATM.
> where was the need to introduce it again, while our goal
> was to eliminate these calls. After implementing I removed them
> and you introduced again and that too with dummy macros.
> Can you let me do the way I want to do ? Or you want to do it yourself ?
>
> QT_PTROFXBP( oXbp ) is defined as ( oXbp:oWidget:pPtr )
> so what is wrong with it ?
QT_PTROFXBP() has two problems:
1) It used the same :pPtr trick, which was apparently
not required after your recent commits.
2) You replaced this HBXBP macro with a low-level hack
inside HBQT code. Thus violating component separation.
+1) You removed QT_PTROFXBP :pPtr trick from HBIDE, but
you kept it in HBXBP. Why?
> The way I desined hbqt_ptr() function was taking care
> of HBQT and HBXBP objects providing the same syntax.
No HBQT function, macro, whatever may ever deal with
anything outside its own level, its own jurisdiction,
etc, including HBXBP.
Notice that HBXBP is an _independent_, _replaceable_,
_optional_ component, one layer above HBQT.
>> ; TOFIX: HBQT has no pointer checking at all before accessing
>> C++ level objects, which means the simplest .prg level
>> error is instantly resulting in a GPF. All hb_par_*()
>> results must be checked for NULL before accessing them,
>> or better yet, and RTE should be generated right from
>> the hb_par_*() function.
>>
>
> I agree 100% but it is again a very tricky issue.
> May be later auto generation takes care of it but at
> present I do not know how to hook it.
if( ptr )
{
// do stuff like now
}
else
hb_errRT...(); // throw Argument Error
would seem like a good start. I can't why NULL
pointer checking in HBQT C++ code is so much
different than in any other C code we have.
> BTW I cannot simply understand your mindset in this regard.
I can see that. My problem is that it's so obvious
that I can't understand how you can't see it.
Do you think the low-level IP stack code has bits of
the FTP protocol? Same thing. (IP stack = HBQT,
FTP protocol = HBXBP)
You can violate it, but only if our goal has suddenly
changed to imitate Windows OS, where this basic rule
was disregarded for decades. Now MS struggles to fix
since 8 years.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
