Hi Pritpal,
>> Why should this conversion be done on the object wrapper level?
>> Why can't you do this conversion in QT_QPIXMAP()?
>> F.e. in hb_gcpointer()?
>>
>
> Because if I implement it QT_QPIXMAP() I have to
> touch around 100 .qth headers which is not viable at this point.
> So I am int
Hello Przemek
Przemysław Czerpak wrote:
>
>proc main()
> p1( "a", "b", "c", 10, 20, 30, .t. )
>return
>
>proc p1( ... )
> local v
> p2( "Original parameters:", ... )
> for each v in { ... }
> switch valtype( v )
> case "N"; v += 1000
On Fri, 18 Dec 2009, Pritpal Bedi wrote:
Hi,
> >> Method QPixmap:new(...)
> >> LOCAL aP := hb_aParams()
> >>
> >> aeval( aP, {|x| x := hbqt_ptr( x ) } )
> >> Qt_QPixmap(...) /* How this can be achieved with above syntax */
> >>
> >> RETURN Self
[...]
proc main()
p1( "a", "b",
Hi
Still better, but I did not test yet:
METHOD QSomePlainObject:new( ... )
LOCAL p
LOCAL aP := hb_aParams()
LOCAL nParams := len( aP )
IF nParams > 0
FOR EACH p IN aP
p := hbqt_ptr( p )
NEXT
ENDIF
::pPtr := hb_execFromArray( @Qt_QSomePlainObject(), aP
Hi
Viktor Szakáts wrote:
>
>> Method QPixmap:new(...)
>> LOCAL aP := hb_aParams()
>>
>> aeval( aP, {|x| x := hbqt_ptr( x ) } )
>>
>> Qt_QPixmap(...) /* How this can be achieved with above syntax */
>>
>> RETURN Self
>
> Why should this conversion be done on the object wrapper level
Hi Pritpal,
>> Again maybe I'm missing something, but in this
>> case isn't the pointer unwrapping done by inside
>> QSomeClass() ? I mean if you pass parameters
>> as is, why would you need to make any transformations
>> on them, when this transformation can be done
>> at destination functio
Hi Pritpal,
>> It hard-wires XBP functionality (which I've removed
>> once already) to HBQT lib.
>>
>> We should avoid that for several obvious reasons.
>> Can you fix it to not require this hack?
>>
>
> There is nothing hard-wired.
hbqt_misc.prg - which is part of HBQT - _has_ the word
"XB
>> It hard-wires XBP functionality (which I've removed
>> once already) to HBQT lib.
>>
>> We should avoid that for several obvious reasons.
>> Can you fix it to not require this hack?
>>
>
> There is nothing hard-wired.
>
> I see the final goal in larger perspective
> and please do not break
> (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 i
Hi
Viktor Szakáts wrote:
>
> It hard-wires XBP functionality (which I've removed
> once already) to HBQT lib.
>
> We should avoid that for several obvious reasons.
> Can you fix it to not require this hack?
>
There is nothing hard-wired.
I see the final goal in larger perspective
and plea
Hi
Viktor Szakáts wrote:
>
> I've just checked further and the fix is quite simple
> and obvious, so I can make it.
>
> The other comment is that maybe there is no need to
> make any sort of hack to check for "Q" or "HB" in the
> beginning of class name, but simply check whether
> :pPtr me
I've just checked further and the fix is quite simple
and obvious, so I can make it.
The other comment is that maybe there is no need to
make any sort of hack to check for "Q" or "HB" in the
beginning of class name, but simply check whether
:pPtr member exists and retrieve it if it does. Low
Hi Pritpal,
I've checked and there is a problem with this commit.
It hard-wires XBP functionality (which I've removed
once already) to HBQT lib.
We should avoid that for several obvious reasons.
Can you fix it to not require this hack?
Brgds,
Viktor
On 2009 Dec 17, at 12:04, vouch...@users.s
Hello Viktor
Viktor Szakáts wrote:
>
>> TODO: Method SomeQtClass:new( ... )
>> ::pPtr := QSomeClass( ... )
>>In above construct it is not known how many parameters
>>are of type pointer and otherwise and how, if resolved,
>>be forwarded t
Hi Pritpal,
>+ Implemented to avoid use of QT_PTROF() and QT_PTROFXBP() macros.
> The functionality is transparent and accepts HBQT and HBXBP objects
> as is.
Thank you very much.
> TODO: Method SomeQtClass:new( ... )
> ::pPtr := QSomeClass( ... )
>
Revision: 13275
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13275&view=rev
Author: vouchcac
Date: 2009-12-17 11:04:37 + (Thu, 17 Dec 2009)
Log Message:
---
2009-12-17 02:06 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
* contrib/hbqt/filelist.mk
16 matches
Mail list logo
