>Now ax controls should be cleanly released but I cannot make any tests.
>Probably it can be easy tested by simple code like:
Hi Przemek.
Tested and working here.
Thank you.
Toninho.
__
Faça ligações para outros computadores com o novo Yahoo! Mes
On Fri, 21 Aug 2009, Pritpal Bedi wrote:
Hi
> Przemyslaw Czerpak-2 wrote:
> > C code using ax controls has to be updated to use hb_oleParam() instead of
> > hb_parptr(). That's all if reference counters were updated correctly.
> > If not then the code has to be cleaned.
> I submit that current (
Hi
Przemyslaw Czerpak-2 wrote:
>
> C code using ax controls has to be updated to use hb_oleParam() instead of
> hb_parptr(). That's all if reference counters were updated correctly.
> If not then the code has to be cleaned.
>
I submit that current ( before your "this" changes ) never releases
On Fri, 21 Aug 2009, Pritpal Bedi wrote:
Hi,
> I have to turn to GTWVG which till recently I did not looked even,
> too busy with HBXBP. I will revert to to in a couple of days and will
> thoroughly evaluate Przemek's changes to core OLE code.
C code using ax controls has to be updated to use h
Hello Viktor
Viktor Szakáts wrote:
>
> Very nice indeed.
>
> Maybe it's now possible to remove some redundant logic from GTWVG.
> At least I hope. Pritpal do you see a chance?
>
I have to turn to GTWVG which till recently I did not looked even,
too busy with HBXBP. I will revert to to in a c
Very nice indeed.
Maybe it's now possible to remove some redundant logic from GTWVG.
At least I hope. Pritpal do you see a chance?
Brgds,
Viktor
On Fri, Aug 21, 2009 at 3:33 PM, Alex Strickland wrote:
> Przemyslaw Czerpak wrote:
>
>> In Harbour user event handler receives as 1-st parameter event
Przemyslaw Czerpak wrote:
In Harbour user event handler receives as 1-st parameter event number
and then ole parameters. So above functionality can be easy implemented
as:
oAx := WIN_AxGetControl( hWnd, ;
{|event,...| myEventHandler( obj, event, ... ) } )
func
On Fri, 21 Aug 2009, Alex Strickland wrote:
Hi,
> I'm sorry to not be more clear. To confirm your deductions, I have code like
> this:
> CLASS BPTI FROM HActiveX
> METHOD terminalDSPEvent(p1, p2, p3, p4) ;
> INLINE ::Event("terminalDSPEvent", p1, p2, p3, p4)
> METHOD infoEven
Przemyslaw Czerpak wrote:
The only one thing I can help here are technical problems in
implementation so I've just look closer at axcore.c and I have
to say that for me few things are seriously broken.
I really appreciate your willingness to do this for Windows code. It is not
critical for me a
On Thu, 20 Aug 2009, Alex Strickland wrote:
Hi,
> Mindaugas posted this when he wrote it:
> ===
> my ActiveX test code is three additional lines in Hello World GUI sample:
> WIN_AxInit()
> hWndAx := CreateWindow("ATLAXWin", "http://sf.net";, ...
> oAx := WIN_AxGetControl( hWndAx, @SomeEvent
Hello Przemek
Przemyslaw Czerpak-2 wrote:
>
> I do not understand why we have WIN_AXRELEASEOBJECT(). For me
> calling this function breaks autodestructors. Pritpal?
>
I had introduced this function before auto-release pointer and
is kept by oversight. This function is not used in core as wel
Przemyslaw Czerpak wrote:
Now you are asking about implementation details and activex
functionality. Sorry but here I cannot help you. I'm not MS-Windows
programmer or even user so you will need real MS-Windows developers
help here. Mindaugas? Pritpal?
Mindaugas posted this when he wrote it:
On Thu, 20 Aug 2009, Alex Strickland wrote:
Hi,
>> hbwin library does not create any GUI objects directly so the Pritpal
>> question is still open.
> Let me ask differently, we have :
> FUNC WIN_AxGetControl( hWnd, bHandler )
> What form is bHandler?
> Is there some kind of default event?
> If i
Przemyslaw Czerpak wrote:
hbwin library does not create any GUI objects directly so the Pritpal
question is still open.
Let me ask differently, we have :
FUNC WIN_AxGetControl( hWnd, bHandler )
What form is bHandler?
Is there some kind of default event?
If it handles one thing, can't it h
On Thu, 20 Aug 2009, toni...@fwi wrote:
Hi Toninho,
> >hbwin library does not create any GUI objects directly so the Pritpal
> >question is still open. Where do you want to "attach" activex controls?
> Maybe we can create a class that need a hWnd parameter from external
> gui like FWH.
AFAIK FWH
Hi Przemek,
>hbwin library does not create any GUI objects directly so the Pritpal
>question is still open. Where do you want to "attach" activex controls?
Maybe we can create a class that need a hWnd parameter from external
gui like FWH.
I user corrent Harbour activeX with FWH in this way:
--
On Thu, 20 Aug 2009, Alex Strickland wrote:
Hi,
>> How do you want it to be in the core ?
>> How you would like to call its functionality.
>> Active-X necessarily means a rectangular area ( window ) to be manipulated,
>> and in Harbour core there is no such thing. It has to go through a GUI
>> ca
Pritpal Bedi wrote:
How do you want it to be in the core ?
How you would like to call its functionality.
Active-X necessarily means a rectangular area ( window ) to be manipulated,
and in Harbour core there is no such thing. It has to go through a GUI
calls.
If you have other thoughts, please sh
Hi
Alex Strickland wrote:
>
> Yes that's right, thanks. Do you think it could be moved to core? I don't
> use
> WVG, but HWGUI. The implementation by Mindaugus and further work by Viktor
> and
> Przemyslaw look very clean and I would prefer to use it than the ActiveX
> implementation in HWGU
Pritpal Bedi wrote:
GTWVG. And it has automatic garbase collection.
Examine harbour/contrib/gtwvg/winsink.c.
Infact it calls hbwin/ole functions.
Yes that's right, thanks. Do you think it could be moved to core? I don't use
WVG, but HWGUI. The implementation by Mindaugus and further work by V
Hi
Alex Strickland wrote:
>
> I do, and it is something which I think the current SVN core code does not
> handle. I know that Pritpals code does handle it (in WVW, WVT??? - I lose
> track), but without the automatic garbage collection that is in the core.
>
GTWVG. And it has automatic garb
toni...@fwi wrote:
I have a working class for TActiveX that user current SVN, here it is:
Do you have any requirement for multiple events?
I do, and it is something which I think the current SVN core code does not
handle. I know that Pritpals code does handle it (in WVW, WVT??? - I lose
tra
Thank you very much Przemek, I'll implement this. I don't
like such hacks and buggy 3rd party code either (they also
ruin the quality image of Harbour). The sole reason we have
legacy*.[c|prg] is to help users to transition to our
proper/better interfaces and provide the old interfaces for
them un
On Wed, 19 Aug 2009, Szak�ts Viktor wrote:
Hi Viktor,
>> My proposed changes with your fix to use hb_parnint() are working fine :-)
>> So we just need this call in legacy.prg:
>> IF ISNUMBER( xOle )
>> xOle := __OLEPDISP( xOle )
>> ENDIF
>> and add this function to olecore.c:
>> HB_FUNC(
Viktor,
My proposed changes with your fix to use hb_parnint() are working
fine :-)
So we just need this call in legacy.prg:
IF ISNUMBER( xOle )
xOle := __OLEPDISP( xOle )
ENDIF
and add this function to olecore.c:
HB_FUNC( __OLEPDISP )
{
IDispatch* pDisp = ( IDispatch * ) hb_parni
Toninho,
Thanks for your help.
Fortunately we got our previous working Harbour code working again :-)
Antonio
El 19 de agosto de 2009 18:14, toni...@fwi escribió:
> Hi, sorry to jump in.
>
>>In FWH Class TActiveX we use this code (which was working fine with
>>previous OleAuto version):
>
> I h
Viktor,
My proposed changes with your fix to use hb_parnint() are working fine :-)
So we just need this call in legacy.prg:
IF ISNUMBER( xOle )
xOle := __OLEPDISP( xOle )
ENDIF
and add this function to olecore.c:
HB_FUNC( __OLEPDISP )
{
IDispatch* pDisp = ( IDispatch * ) hb_parni
Hi, sorry to jump in.
>In FWH Class TActiveX we use this code (which was working fine with
>previous OleAuto version):
I have a working class for TActiveX that user current SVN, here it is:
---cut---
#include "hbclass.ch"
//---
Hi Antonio,
Sorry no idea. The only bug I see is hb_parnl() usage
while it should be hb_parnint(), but that only affects
x64 systems.
I hope someone will comment who knows OLE better from
the inside.
Brgds,
Viktor
On 2009.08.19., at 4:46, Antonio Linares wrote:
Viktor,
In FWH Class TActiveX
> In FWH Class TActiveX we use this code (which was working fine with
> previous OleAuto version):
>
> ::oOleAuto = TOleAuto():New( ActXPdisp( ::hActiveX ) )
It also works fine with xHarbour OleAuto.
thanks
Antonio
___
Harbour mailing list
Harbour
Viktor,
In FWH Class TActiveX we use this code (which was working fine with
previous OleAuto version):
::oOleAuto = TOleAuto():New( ActXPdisp( ::hActiveX ) )
ActXPdisp() returns a pDisp.
So we tried this change in legacy.prg:
IF ISNUMBER( xOle )
xOle := __OLEPDISP( xOle )
END
Looking at the code. Well with a small incompatibility,
most of the functionality could be resolved. Simply
CREATEOLEOBJECT() should not convert the pointer to
numeric. Such thing is wrong for GC collected ptrs.
I'll do that ASAP.
Caller code will have to be changed then to use 'EMPTY()'
instead
Hi Antonio,
You're right, I missed that. In this case the problem is
bigger and AFAICS accepting numeric pointers cannot be
implemented in a clean way. Probably an RTE should be
thrown in this case or an error returned to help catch this
case.
[ Or maybe someone has a better idea which fits in c
Viktor,
Recently you modified contrib\hbwin\legacy.prg and added this code to
support Windows (numeric) handles for creating an oleauto object:
IF ISNUMBER( xOle ) // xOle is a pDisp
xOle := win_N2P( xOle )
ENDIF
But OleAuto uses this code from __OleCreateObject():
ppDisp =
34 matches
Mail list logo
