Hello Viktor

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.


vszakats wrote:
> 
> 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.



>       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?

And again you restored QT_PTROF() macro in the code, 
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 ?

The way I desined hbqt_ptr() function was taking care 
of HBQT and HBXBP objects providing the same syntax.



>     ; 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.

BTW I cannot simply understand your mindset in this regard.

Regards
Pritpal Bedi

-- 
View this message in context: 
http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13277--trunk-harbour-tp26835971p26836402.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.

_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to