> (I assumed XHB stuff is already removed from here) > > But why we do not want to include XBP stuff here ? > This does not interacts with XBP anyway, only XBP interacts > with it, and this poses no harm.
I've tried to describe this in several of my e-mails, so I'm not sure if will be able to iterate it more. To repeat: It's a _basic_ requirement for component separation. HBQT should know _nothing_ about hbide, or hbxbp, or anything else which is a layer above it. Currently HBQT violates this by holding classes for HBIDE, and also HBXBP, which is wrong. Such inter- dependencies should be avoided to have a clean layout. Currently it's used to trick out our agreement to not include C code in HBXBP, instead you simply moved these components to HBQT. For HBIDE it's slightly different cause, but it's also not good this way. > The final function skeleton may be like this > > //-------------------// > FUNCTION hbqt_ptr( xParam ) > > IF hb_isObject( xParam ) > if __objHasMsg( xParam, "PPTR" ) > RETURN xParam:pPtr > > elseif __objHasMsg( xParam, "OWIDGET" ) > RETURN xParam:oWidget:pPtr No, this is wrong. OWIDGET has to with HBXBP, but HBQT should have no inside knowledge about HBXBP, since it's a different lib at a different layer. > It will allow to mix HBQT and HBXBP use the same syntax > with interchangele way. This should be solved on the HBXBP level only. > Of course, C level call is much more efficient, I will give it a try. > > I have more changes to commit, so please do not commit > anything here, I will do thw spadework, just suggest for > some time. Sorry I've committed something before reading your mail, but pls don't restore such layer violations. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
