Pritpal Bedi wrote:
I was experimenting and got to this point : olecore.c line # 231
case HB_IT_OBJECT: /* or ARRAY */
if( HB_IS_OBJECT( pItem ) )
{
// if( hb_stricmp( hb_objGetClsName( pItem ), "HB_OLEAUTO" ) == 0 )
^^
Hello
I was experimenting and got to this point : olecore.c line # 231
case HB_IT_OBJECT: /* or ARRAY */
if( HB_IS_OBJECT( pItem ) )
{
// if( hb_stricmp( hb_objGetClsName( pItem ), "HB_OLEAUTO" ) == 0 )
^
Hi
? valtype( oDialogs:calendar ) -> U
This is OK as at this point :calendar property is uninitialized.
oDialogs:calendar := oCal ->GPF
If I omit above line then Calandar Control behaves properly.
I just cannot open any of the dialogs provided by the control.
Later one more error is gene
Hi,
oCal := hb_ActiveX( ... )
..
..
oDialogs := CreateObject( "Codejock.CalendarDialog.11.2.2" )
? valtype( oDialogs ) // "O"
oDialogs:calendar := oCal ->Here it GPF's
I do not know the reason for without a deeper debugging. What is result of:
? oCal:ClassName
Current code converts
Hi
Mindaugas Kavaliauskas wrote:
>
> I'd rather say wvg's is better. It uses VirtualAlloc() to allocate page
> having the correct (read/write/execute) permissions. But I'm lost among
> the details. _AsCallback() has many strange parameters instead of a
> single codeblock.
>
Me too do not ha
Hi,
I have tried to search for it but could not.
can you point-out the link, or to be easier, post on this list again.
I just want to compare with contrib/gtwvg/wincallb.c.
I'd rather say wvg's is better. It uses VirtualAlloc() to allocate page
having the correct (read/write/execute) permis
Hello Mindaugas
Mindaugas Kavaliauskas wrote:
>
>>> nAddr := MakeWndProc( {|X,Y,Z,T| WndProc( X,Y,Z,T ) } )
>>
>> Can you make this function public. Probably this may pave the
>> way to clean a non-portable part of GTWVG, whio knows.
>
> This function is not 64bit compatible. So, I do not w
Hi,
nAddr := MakeWndProc( {|X,Y,Z,T| WndProc( X,Y,Z,T ) } )
Can you make this function public. Probably this may pave the
way to clean a non-portable part of GTWVG, whio knows.
This function is not 64bit compatible. So, I do not want to propose it
for the masses. The source of it was publ
> The development in this direction got stalled due to attention
> to QT implementation. At a given point of time one may have
> limited times.
>
> HBWHAT was not bad either. It needs just few tweaks and by far
> the most comprehensive API so far. Perhaps we need more resources
> to join the effort
Hello
Viktor Szakáts wrote:
>
> As for lightweight winapi, HBWHAT had a lot of problems, so
> it's no more. Some WINAPI's are now implemented
> (hopefully properly) as WAPI_*() functions in HBWIN. But
> this effort seem to have stalled.
>
Not exactly.
The development in this direction got st
Hi Mindaugas,
I'd certainly welcome your lightweight AX implementation,
this way hopefully not every contrib would need to reinvent
it again and again.
As for lightweight winapi, HBWHAT had a lot of problems, so
it's no more. Some WINAPI's are now implemented
(hopefully properly) as WAPI_*() func
Sorry Mindaugas
Mindaugas Kavaliauskas wrote:
>
> my name is Mindaugas. I've tried to joke a few times writing Pritpul,
> but it seems you are not enough sharp-eyed to notice the difference
> neither in spelling of my name nor in yours.
>
I did notice. At times a foreign name tends to have
Hello Mindaugus
Mindaugas Kavaliauskas wrote:
>
> I've extended my previous sample by:
>
> nAddr := MakeWndProc( {|X,Y,Z,T| WndProc( X,Y,Z,T ) } )
Can you make this function public. Probably this may pave the
way to clean a non-portable part of GTWVG, whio knows.
Just to put everything t
Pritpal Bedi wrote:
Hi Mindaugus
Hi Pritpal,
my name is Mindaugas. I've tried to joke a few times writing Pritpul,
but it seems you are not enough sharp-eyed to notice the difference
neither in spelling of my name nor in yours.
Regards,
Mindaugas
Francesco Saverio Giudice wrote:
Are these two different things the same ActiveX?
I will look at Pritpal's upload, but, as I wrote before, I would like to
have an independent (from gtwvg) version.
I've extended my previous sample by:
===
Hi Mindaugas,
Il 18/05/2009 23.13, Mindaugas Kavaliauskas ha scritto:
Hi Francesco,
in the past I've wrote some code to "include Internet Explorer window
into my dialogs as a separate control". Using some sample on the
internet I've implemented: IOleInPlaceFrame, IOleClientSite,
IOleInPlaceS
Hi Mindaugus
Mindaugas Kavaliauskas wrote:
>
> I've tried to add ActiveX to my plain WinAPI Hello world sample. I
> needed to add *TWO* lines (marked by /* !!!*/) below and #pragma
> begindump/enddump. THAT'S ALL! I understand that event handler is
> missing and OleAutomation object should b
Hi Francesco,
in the past I've wrote some code to "include Internet Explorer window
into my dialogs as a separate control". Using some sample on the
internet I've implemented: IOleInPlaceFrame, IOleClientSite,
IOleInPlaceSite interfaces (3 dozens methods), used IOleObject,
IHTMLDocument2, IW
Hi Mindaugas, Pritpal,
I was just writing about and Mindaugas sent this mail, great!
I was thinking about adding a separate handling for ActiveX code to
leave isolate as Ole code we already have, so it will be enough (!) to
add an upper layer where ActiveX can attach itself without needs of
gt
Hi,
I've tried to add ActiveX to my plain WinAPI Hello world sample. I
needed to add *TWO* lines (marked by /* !!!*/) below and #pragma
begindump/enddump. THAT'S ALL! I understand that event handler is
missing and OleAutomation object should be created, but this is not so
much code. I have a
Hi,
Pritpal Bedi wrote:
Mindaugas Kavaliauskas wrote:
The middle part of mail window is not redrawn, but I get no error.
It means ActiveX is not initialized even.
I will apply your changes and will do some tests todays.
Till then...
wvgax.prg wvgsink.c if full of commented out code, ful
Hello
Mindaugas Kavaliauskas wrote:
>
> The middle part of mail window is not redrawn, but I get no error.
>
It means ActiveX is not initialized even.
I will apply your changes and will do some tests todays.
Till then...
Regards
Pritpal Bedi
--
View this message in context:
http://www.n
Hello Pritpul,
I've put my hands a to change gtwvg to be compatible with OLE
implementation, but I'm unable to test changes. Does anyone have gtwvg
sample with working (or GPFing) ActiveX controls. I've tried to use
contrib/gtwvg/tests samples. They do not give any error, but demowvg
window is
Hello all,
This error, still persists:
[ERROR]
Error description: Error BASE/3012 Argument error: NEW
Args:
[ 1] = N 1470288
Stack Calls
===
Called from: => HB_OLEAUTO:NEW(0)
Called from: classes\ACTIVEX.PRG => TACTIVEX:NEW(0)
Called from: webexp.prg => MAIN(1
Hello Mindaugus
Mindaugas Kavaliauskas wrote:
>
> I've put my hands a to change gtwvg to be compatible with OLE
> implementation, but I'm unable to test changes. Does anyone have gtwvg
> sample with working (or GPFing) ActiveX controls. I've tried to use
> contrib/gtwvg/tests samples. They d
Anyhow I've now read messages from Przemek and Mindaugas targeting
your specific AX problem, I hope it will be committed and we
can move on to next issues. IMO your GTWVG AX code can also quite
easily changed to use real pointers, or call an API.
Hi,
I've put my hands a to change gtwvg to be
I've moved new ole to hbwin, because otherwise we will very very
slowly adapt to
it, since very few users would test it.
Not exactly. It just broke all the linking process itself, simply
unusable to test either.
You still didn't post what error you're getting. First you
wrote that you cannot
Hello Pritpul,
We will to change at least numeric type to pointer type...
Yes, but how. I am following your code but am been
unbale to hook any code inside it because of WINAPI background.
harbour/contrib/gtwvg/wvgsink.c
Thanks for this line. I did not know we have more OLE/ActiveX code i
Thanks Przemek
Przemyslaw Czerpak-2 wrote:
>
> It's enough to add to olecore.c this function:
>
> PHB_ITEM hb_oleItemPut( PHB_ITEM pItem, IDispatch* pDisp )
> {
>IDispatch** ppDisp;
>
>ppDisp = ( IDispatch** ) hb_gcAlloc( sizeof( IDispatch* ),
> hb_ole_destructor );
>*ppDisp = pDi
Hello
Viktor Szakáts wrote:
>
> I've moved new ole to hbwin, because otherwise we will very very
> slowly adapt to
> it, since very few users would test it.
>
Not exactly. It just broke all the linking process itself, simply
unusable to test either.
> hbwin.lib - New implementation, with c
On Thu, 14 May 2009, Pritpal Bedi wrote:
Hi,
> Mindaugas Kavaliauskas wrote:
> > We will to change at least numeric type to pointer type...
> Yes, but how. I am following your code but am been
> unbale to hook any code inside it because of WINAPI background.
> harbour/contrib/gtwvg/wvgsink.c
>
I've moved new ole to hbwin, because otherwise we will very very
slowly adapt to
it, since very few users would test it.
In just one day now at least we begin to have a better idea about problems,
which is good, and until things settle everyone can use the last know
revision which is compatible wi
Hello Mindaugus
Mindaugas Kavaliauskas wrote:
>
> We will to change at least numeric type to pointer type...
>
Yes, but how. I am following your code but am been
unbale to hook any code inside it because of WINAPI background.
harbour/contrib/gtwvg/wvgsink.c
AtlAxCreateControl = ( PATLAX
Rossine
You have to apply patch in olecore.c itself.
You cannot club this function in #prgma begin/end
construct. Rebuild olecore.c.
Also try Przemek's refinements. May be any could help.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/Errors-with-11032-tp23521549
Hello Pritpal,
Including this in my example: (WEBEXP.PRG)
[CODE]
#include "FiveWin.ch"
function Main()
local oWnd, oActiveX
local cEvents := ""
DEFINE WINDOW oWnd TITLE "FiveWin ActiveX Support"
oActiveX = TActiveX():New( oWnd, "Shell.Explorer" )
oWnd:oClient = oActiveX // T
Antonio Linares can perhaps give us a opnião about this ...
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Hello Przemek and All,
Przemyslaw Czerpak-2 wrote:
>
> In summary I guess that you wanted to make sth like:
>
>if( lOleError == S_OK )
> lOleError = CoCreateInstance( HB_ID_REF( ClassID ), NULL,
> CLSCTX_SERVER, fIID ? HB_ID_REF( iid ) : HB_ID_REF( IID_IDispatch ), (
> void**
Hi,
Apply this patch in olecore.c and let me know it solves this issue:
but there is a question if we want to still tolerate code with
C pointer <-> HVM number item conversions and keep workarounds
for it. I'm leaving the decision to Mindaugas.
Usage of numbers instead of pointers is one
Hello, Pritpul,
Apply this patch in olecore.c and let me know it solves this issue:
Mindaugus, please check if this can be implemented like this or
some else construct is needed.
HB_FUNC( OLECREATEOBJECT ) /* ( cOleName | cCLSID [, cIID ] ) */
{
...
if( HB_IS_NUMBER( 1 ) )
{
We will
>
> if( lOleError == S_OK )
> lOleError = CoCreateInstance( HB_ID_REF( ClassID ), NULL,
> CLSCTX_SERVER, fIID ? HB_ID_REF( iid ) : HB_ID_REF( IID_IDispatch ), (
> void** ) ( void * ) &pDisp );
>}
> + else if( ISNUM( 1 ) )
> + {
> + pDisp = ( IDispatch * ) ( HB_PTRDIFF )
On Wed, 13 May 2009, Pritpal Bedi wrote:
Hi,
> > METHOD New( oWnd, cProgID, nRow, nCol, nWidth, nHeight ) CLASS TActiveX
> > ::oOleAuto = TOleauto():New( ActXPdisp( ::hActiveX ) )
> Apply this patch in olecore.c and let me know it solves this issue:
> Mindaugus, please check if this can be
>
> Apply this patch in olecore.c and let me know it solves this issue:
> Mindaugus, please check if this can be implemented like this or
> some else construct is needed.
>
> HB_FUNC( OLECREATEOBJECT ) /* ( cOleName | cCLSID [, cIID ] ) */
> {
> wchar_t*cCLSID;
> GUIDClassID, iid;
Hello
Rossine wrote:
>
> METHOD New( oWnd, cProgID, nRow, nCol, nWidth, nHeight ) CLASS TActiveX
> ::oOleAuto = TOleauto():New( ActXPdisp( ::hActiveX ) )
>
Apply this patch in olecore.c and let me know it solves this issue:
Mindaugus, please check if this can be implemented like this or
Hi Rossine,
Thanks for your report.
I suggest to keep using the older revision until these
incompatibilities with certain 3rd parties get resolved
in one way or another.
We will probably have to introduce some compatibility
calls to satisfy these tools until they adapt to our
changes. We should
Hello,
Using version 11021 compile with BCC55 works fine, but I am using version
11032 is the seguints errors:
[ERRORS]
Error: Unresolved external '_hb_oleAnsiToWide' referenced from
C:\FWH\LIB\FIVEHC.LIB|MSGSAPI
Error: Unresolved external '_HB_FUN_ANSITOWIDE' referenced from
C:\FWH\LIB\FIVEH.LI
45 matches
Mail list logo
