I have a question that i've been trying to solve for 2 days now and not doing so well :rolleyes:

Im trying to do something trivial (of course) and making the application become visible. Origionally the "put_Visible" method was translated to have only a :BOOL param.

So i tried:

invoke vf( pExcelApp, _Application, put_Visible), TRUE

And it failed, with an invlid param type error... After alot of running around and confimation, i realized one and only one clue: The param :BOOL is wrong, its actually indicated as VARIANT_BOOL, in the IDL
        [id(0x0000022e), propget, helpcontext(0x0001022e)]

HRESULT Visible(
[in, lcid] long lcid,
[out, retval] VARIANT_BOOL* RHS);
[id(0x0000022e), propput, helpcontext(0x0001022e)]
HRESULT Visible(
[in, lcid] long lcid,
[b][in] VARIANT_BOOL RHS);[/b]

I then tried manually formating and using a variant:


invoke VariantInit, addr vv
mov vv.vt, VT_BOOL
mov vv.boolVal, TRUE

Modified the Proto from :BOOL to :VARIANT and tried again. No luck.

So im stumped with too many Variables to play with...

Does anyone know how VARIANTS are to be uses 'properly' with displatchable methods?

Does anyone know what the "RHS" means following the proto definition above??

Im guessing its the assumed proto type is now my problem (might not be :VARIANT )

Please help if you think you have something to add ;)

Thanx alot!
Posted on 2002-12-26 23:48:15 by NaN
Hi NaN,

the RHS possibly is the name of the variable.

Where did you get the IDL from? Im asking because the lcid parameter doesnt appear in my excel typeinfos.

In a VBScript app, there is a simple code:

Set objXL = WScript.CreateObject("Excel.Application")
objXL.Visible = TRUE

which works and is without lcid (I use office 2000)

BTW: VARIANT_BOOL isnt a VARIANT, in VC its simple defined as WORD (which may be a problem sometimes with MASM because of the invoke bug). You will need variants only if you call methods throu IDispatch::Invoke.
Posted on 2002-12-27 05:59:26 by japheth
The LCID value is the 'This' param of the interface from which the Visible method is called from.

I found that VARIANT_BOOL is a WORD last night, but i tried:

xor eax, eax
mov ax, TRUE
invoke (pExcelApp, _Application, put_Visible), ax

and it also failed :rolleyes: . Is this affected by the 'invoke' bug you spoke of?

Anywho, im baffled too as I've done the VB script before as you got it, and works everytime.....

I know i got the App Interface working correctly (From trial and error methods).
I also know that the Vtbl offset is correct in the assembly transcriptions.

Im truely puzzled..
Posted on 2002-12-27 09:15:49 by NaN

The LCID value is the 'This' param of the interface from which the Visible method is called from.


I Posted on 2002-12-27 10:30:43 by NaN
I was right with the assumption, the tool is making another error:

Here is the generated code for IWindow:
   STDMETHOD   get_ActiveCell , :ptr ptr Range, :ptr HRESULT

STDMETHOD get_ActiveChart , :ptr ptr Chart, :ptr HRESULT
STDMETHOD get_ActivePane , :ptr ptr Pane, :ptr HRESULT
STDMETHOD get_ActiveSheet , :ptr ptr IDispatch, :ptr HRESULT
STDMETHOD get_Caption , :ptr VARIANT, :ptr HRESULT

And here is the IDL for the same area:
        [propget, helpcontext(0x00010131)]

HRESULT _stdcall ActiveCell([out, retval] Range** RHS);

[propget, helpcontext(0x000100b7)]
HRESULT _stdcall ActiveChart([out, retval] Chart** RHS);

[propget, helpcontext(0x00010282)]
HRESULT _stdcall ActivePane([out, retval] Pane** RHS);

[propget, helpcontext(0x00010133)]
HRESULT _stdcall ActiveSheet([out, retval] IDispatch** RHS);

[propget, helpcontext(0x0001008b)]
HRESULT _stdcall Caption([out, retval] VARIANT* RHS);

[propput, helpcontext(0x0001008b)]
HRESULT _stdcall Caption([in] VARIANT RHS);

As you can see there is not to be a "HRESULT" out param by the methods for both the property put and property get type methods...

(Sorry, not trying to irritate you, just make your tool better ;) )
Posted on 2002-12-27 10:46:38 by NaN

the "this" parameter is invisible in the protos defined by comview, but it is there of course.

STDMETHOD macro name:req,arguments:VARARG
local prototype,pointer,function
ifnb <arguments>
;---------------------------------------------------------------!------------------------- its here
prototype catstr ?Interface,<_>,<name>,< typedef proto :ptr ,arguments>
prototype catstr ?Interface,<_>,<name>,< typedef proto :ptr>
pointer catstr <p>,?Interface,<_>,<name>,< typedef ptr >,?Interface,<_>,<name>
function catstr <name>,< p>,?Interface,<_>,<name>,< ?>


The prototype for put_Visible property takes 2 real parameters, "this" and a VARIANT_BOOL, thats all. (VARIANT_BOOL, although it is a WORD, must be pushed as DWORD to keep stack dword aligned)
Posted on 2002-12-27 10:47:59 by japheth
Well there is a third REAL param "LCID"... Cause it took a week of my real time to find this problem... ??? Maybe this is a one time fluke or maybe there is something being overlooked here... i dunno..

Thanx for the stack info tho.. I see your point here.

Posted on 2002-12-27 11:10:03 by NaN
NaN, you are right.

For TKIND_DISPATCH typeinfo there may exist a (somewhat hidden) referenced TYPEINFO.

From MSDN:

If the TKIND_DISPATCH type description is for a dual interface, the TKIND_INTERFACE type description can be
obtained by calling GetRefTypeOfImplType with an index of ?1, and by passing the returned pRefType handle to
GetRefTypeInfo to retrieve the type information.

I missed that up to now. With this info you get these "hidden" parameters lcid and retval, no more special handling for include generation is required.

I will adjust comview accordingly

Posted on 2002-12-28 05:27:40 by japheth
I really didnt understand all to much from that quote ;) So im glad you understand it, and secondly I wish to to thank you for being willing to improve your COMView tool (I realize you have other projects on the go).

I realy dont anticipate any more problems beyond this and the HRESULT business i posted above... (which i assume is also an ez fix...)

Thanx alot Japheth, let me know when your got things worked out..

To perhaps help you out, here is the Excel .OLB which i have been using to cause all these problems ;) --> Download

Also, here is the IDL i was given by Gunner. I assume it was transcribed with a VC++ tool --> Download

The interface that showed some problems with these hidden types was _Application . The methods get_Visible and put_Visible were the onces that brought this business to light.

As well the interface IWindow is where i noticed the extra method param :HRESULT being tack on that should not be there..

Thanx again Japheth for everything,
Posted on 2002-12-28 06:10:38 by NaN
I 've go the next version to work, but regard it as preliminary, I want to have a "stable" version this time and so need some more testing.

Please report errors you may find
Posted on 2002-12-28 09:11:20 by japheth
It all looks great!

But time will truely tell (still have to edit out the transcription to work... The excel TLib has methods with over 20 VARIANT params, this causes masm32 to complain about lines being to long... ;) (Not your problem, dont worry!)

However, if i may add some constructive feedback.. When i work with such big com headers.. i copy the interface/class name with the GUID to the top of the file and comment it out to form an index:

;;sIID__Application textequ <IID {0000208D5h,00000h,...}}>
;;sIID__Chart textequ <IID {0000208D6h,00000h,...}}>
;;sIID__Worksheet textequ <IID {0000208D8h,00000h,...}}>
;;sIID__Global textequ <IID {0000208D9h,00000h,...}}>
;;sIID__Workbook textequ <IID {0000208DAh,00000h,...}}>
;;sIID__IOLEObject textequ <IID {0000208A2h,00001h,...}}>
;;sIID__IQueryTable textequ <IID {000024428h,00001h,...}}>

This way by double clicking on the name "sIID__Application" and hitting F3 it jumps to the interface description for quick referencing.. (saves time in the long run).

I dont know if it would be a pain in the arse or not to include this, but if it would be relatively painless, i think it would be a handy to have...

As well the double ';;' is for the assembler. It will absolutely ignore a double ; in the file, however, it will still copy/include the single semicolon stuff on a pre-compile. Adding some speed relief.

Thanx again Japheth!
Posted on 2002-12-28 09:39:53 by NaN
After fixing line too long, and some less likely text label errors (ie. Comment, Label, RGB, Arc, Rectangle)

It recompiled perfectly and ran Excel as it should!

I think you got it with this one...
Great work!
Posted on 2002-12-28 09:58:13 by NaN
How did you fix the "line too long" errors, NaN?

I tested with excel.inc now, and found as only "solution" to cut the parameter line.

And I had some troubles with "structure redefines" (duplicate definitions in office.inc and excel.inc).
That can be avoided by generating ifdefs.

Now here is my "final" version :) . Still you have to fix some errors manually (parameter names), but its done it one minute.
Posted on 2002-12-28 12:47:37 by japheth
You can get around 512 char lengths by replacing key words with smaller text equates:



(This compiles with 30 Variants and an extra output Variant pointer)

As well, i did also encounter all the other stuff, but chose not to bother you with it. Adding ifdef's is not too much swet off my back, and symbol redef's are rare if any..

Posted on 2002-12-28 14:07:20 by NaN

The LCID is the Locale Identifyer, a number that specifies which language/dialect you're using. Sending NULL means use the computer's default.

If you want to know some more, look in the language.inc file from my stuff.

(whack me if I didn't include it in my published stuff and I'll post it here)

I have zero idea what that "RHS' could be.
Posted on 2002-12-30 15:13:24 by Ernie
Thanx Ernie..

I evenually discovered that when working out the InvokeHelper fucntion in the other thread... Here...

Thanx alot tho Ernie :alright:
Posted on 2002-12-30 15:49:16 by NaN