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 )
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
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 want to
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)
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 have
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 only
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
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 )
^
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(10)
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
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,
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
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
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 be
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,
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:
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
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
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
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_*()
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 stalled
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.
It
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
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
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 do
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 = (
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
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
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 clean
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 = pDisp;
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
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;
BOOL
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
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 )
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
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 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** ) (
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 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 // To fill
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:
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
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
42 matches
Mail list logo
