This is mainly to Japheth, but if anyone else can add more light, please speak up ;)

Japheth,

Im playing around with your COMView app, and i think I've run into a problem with it. I have a transcribed Acad.inc that works, and i used your tool to make another one for testing sake. I modified my source to addapt to your calling conventions etc., and the program works as expected.. with one flaw:

One interface "IModelSpace" for example, has many "add" methods to insert objects into this drawing 'space'.

I was calling the "AddCircle" method in particular, which from my working program required the following params:

center:VARIANT, radius:REAL8, pICircleOut:PTR INTERFACE

When compiling this phase, i got a param/proto error, which when i looked into it i realized the last "PTR INTERFACE" param was not transcribed by your program. I look around and realizes all the "Add" methods failled to include its last output. I also ran your program to see if it was listed by it, and if showed only:

AddCircle | 0x60A | dispatch, func, sdtcall | Ptr IAcadCircle | Center:VARIANT, Radius:R8 | 136

As im seeing thing, the 'rcType' Field is being Ignored for "func, stdcall" typed methods. My question is: Is this intentional? Are you expecting the return to be in EAX after the invoke?? I've never seen this before and conceptually it *could* happen, but again, its not standard practice that i am aware of?? (Please correct me if im wrong here).

As well, if this is a bug, could you advise me to where in your program it should be fixed, and recompiled..

This is still an awesome tool Japheth!
Thanx for your help,
:alright:
NaN
Posted on 2002-12-22 02:51:27 by NaN
Hi NaN,

I cant tell from your infos if this is a bug. From what you have inserted it looks like one.

So you may look for the error yourself :) . The place where to look is:

file CTypeinfoDlg.asm, proc FunctionsOnInitDialog.

look for code like



movzx ecx,[esi].FUNCDESC.cParams
mov esi,[esi].FUNCDESC.lprgelemdescParam
mov szStr,0
.while (ecx)

....
.endw



In file ComView.asm there is a bug, but it causes too much stuff displayed, not too less
(if returned parameter is of type USERDEFINED)



GetParameterTypeEx proc uses esi pTypeInfo:LPTYPEINFO, pElemDesc:ptr ELEMDESC, pStr:LPSTR, iMax:dword, iMode:dword

mov esi,pElemDesc
movzx eax,[esi].ELEMDESC.tdesc.vt
.if (eax == VT_USERDEFINED)
mov eax,pStr ;BUG: string should be cleared first
mov byte ptr [eax],0 ;insert these 2 lines
invoke GetUserDefinedType, pTypeInfo, [esi].ELEMDESC.tdesc.hreftype, pStr, iMax
.else


Please tell me the bug(s) you'll find.

Japheth
Posted on 2002-12-22 10:00:58 by japheth
Im havent tracked the above mentioned problem yet, but i did come across this routine which also needs some ammending (CreateInc.asm):
;--- avoid some ASM reserved names in declarations

;--- by simply add a underscore to it

CheckReservedNames proc uses esi pStr:ptr byte

xor esi,esi
invoke lstrcmpi, pStr, CStr("invoke")
.if (eax == 0)
inc esi
.endif
invoke lstrcmpi, pStr, CStr("name")
.if (eax == 0)
inc esi
.endif
invoke lstrcmpi, pStr, CStr("length")
.if (eax == 0)
inc esi
.endif
[b] invoke lstrcmpi, pStr, CStr("add")
.if (eax == 0)
inc esi
.endif
invoke lstrcmpi, pStr, CStr("offset")
.if (eax == 0)
inc esi
.endif[/b]
.if (esi)
invoke lstrcat, pStr, CStr("_")
.endif
ret

CheckReservedNames endp


I had to fix these manually, but didnt mention it... (A minor point, but since you asked ;) )

:alright:
NaN
Posted on 2002-12-22 11:42:09 by NaN
Havent Tested, since I have to go X-Mas shopping, but i think i found the location where extra stuff should be added (not positive, since i dont fully know the ITypeLib and its structures yet).

In the file (CreateInc.asm), lines 390->401:
invoke WriteString, hFile, addr szStr


mov szStr,0
mov eax,[esi].FUNCDESC.invkind
mov edx,[esi].FUNCDESC.funckind
.if ((eax == INVOKE_PROPERTYGET) && (edx == FUNC_DISPATCH))
invoke WriteString, hFile, CStr(", :ptr ")
invoke GetParameterTypeAsm, pTypeInfo,\
addr [esi].FUNCDESC.elemdescFunc, addr szStr, sizeof szStr
.endif

invoke WriteLine, hFile, addr szStr


Here you have routines to handle the Property Get 'type' method, by as im reading it, simply tacking on the pointer at the end of the STDMETHOD description. If this if case was modified somehow to be : (Making up some labels here in bold):
.if ((edx == FUNC_DISPATCH) && ((eax == INVOKE_PROPERTYGET) 

[b]||((eax=INVOKE_FUNC) && (ReturnType != TYPE_VOID) ) ) )[/b]


Basically tying to spell out:

If DISPATCH and ( PROPERYGET or ( FUNC and RETURN_NOT_VOID) ) then add tailing ':PTR '

Let me know if you agree or have further suggestions.
Thanx
:alright:
NaN
Posted on 2002-12-22 12:08:05 by NaN
NaN,

thanks for your improvements. :)

And you have found the right place to modify (although I worked hard to get you to absolutely wrong places). Congratulations.

I remember the problem now.



mov eax,[esi].FUNCDESC.invkind
mov edx,[esi].FUNCDESC.funckind
.if ((eax == INVOKE_PROPERTYGET) && (edx == FUNC_DISPATCH))


is definitely not sufficient. I once had tried



movzx eax, [esi].FUNCDESC.elemdescFunc.tdesc.vt
.if (eax != VT_VOID)


which at first glance resolves this problem. But if you look again you may realize that now all functions with a return value get this extra parameter. And for functions AddRef() and Release() this is surely wrong (Ok, you will never call AddRef via Invoke_).
Up to now I didnt find any flags in typeinfo which provides for a proper solution.
So my solution was the one which is implemented now, because it served my purposes.
Help here would be very appreciated.

Japheth
Posted on 2002-12-22 14:51:27 by japheth
I will see what the .CHM has to offer that Gunner provided...

I would be surprised if there was no clean solution to this. However, my time is stretched thin as Christmas is here. I will work on the problem as I can.

Thanx again!
:alright:
NaN
Posted on 2002-12-22 21:01:59 by NaN
Man, i can't cleanly find a way to compile this...

Im not dumb, i do know what your doing, its just I *never* go down this road. I have to compile each object separately, and then link them all to gether. However, your doing other stuff that i dont practice, which is leaving out all lib definitions (how you make it link with out 'includelib' is i do not know...). I punched in all the ones needed, but im still getting external protos not declaired like 'Malloc'... i have Oaidl.inc inlcuded...

Ahh.. im tire of this for now... too confusing just to get a compile.

Here is the *fixed* COMView compile:
Microsoft (R) Macro Assembler Version 6.14.8444

Copyright (C) Microsoft Corp 1981-1997. All rights reserved.

Assembling: D:\masm32\_ACTIVE\Comview\COMView.asm
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

COMView.obj : error LNK2001: unresolved external symbol _g_hWndSB
COMView.obj : error LNK2001: unresolved external symbol _Destroy@CInterfaceList@4
COMView.obj : error LNK2001: unresolved external symbol _Create@COptions@0
COMView.obj : error LNK2001: unresolved external symbol _Destroy@COptions@4
COMView.obj : error LNK2001: unresolved external symbol _Create@CMainDlg@0
COMView.obj : error LNK2001: unresolved external symbol _Destroy@CMainDlg@4
COMView.obj : error LNK2001: unresolved external symbol _InitGlobalCEditDlg@0
COMView.obj : error LNK2001: unresolved external symbol _DeinitGlobalCEditDlg@0
COMView.exe : fatal error LNK1120: 8 unresolved externals
_
Link error


And selecting CProcessDlg for a separate compile i get:
Microsoft (R) Macro Assembler Version 6.14.8444

Copyright (C) Microsoft Corp 1981-1997. All rights reserved.

Assembling: D:\masm32\_ACTIVE\Comview\CProgressDlg.asm
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

CProgressDlg.obj : error LNK2001: unresolved external symbol _malloc@4
CProgressDlg.obj : error LNK2001: unresolved external symbol _free@4
CProgressDlg.obj : error LNK2001: unresolved external symbol _CenterWindow@4
CProgressDlg.obj : error LNK2001: unresolved external symbol _GetListView@CMainDlg@4
LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
CProgressDlg.exe : fatal error LNK1120: 5 unresolved externals
_
Link error


All other dialogs are simular (more or less).
Posted on 2002-12-22 23:28:03 by NaN
NaN,

because its xmas I generated COMView version 1.4.3. Its with your suggestion included.
To avoid generationg AddRef/Release with this wrong extra parameter I avoid now generating
the IDispatch functions generally. Thats because macro BEGIN_INTERFACE allows an inherit interface as second parameter. So the includes generated all are a bit smaller now.

Your link problems: I dont really understand why you get these errors. There is a .MAK file included which should work. includelib statements I dont use normally, I prefer setting LIB= environment var or /LIBPATH: linker option.

heres the new COMView version

Japheth
Posted on 2002-12-23 00:32:14 by japheth
Thanx alot, i didnt expect this (i was just venting, i dont have the program that uses make files, i learned without it and never found a need for it).

Anywho, since you have recompiled it, can you do me one more small favor and recompile it again, except modify it a bit to keep it from crashing ;)
;--- avoid some ASM reserved names in declarations

;--- by simply add a underscore to it

CheckReservedNames proc uses esi pStr:ptr byte

mov esi, offset ReservedNames
mov ecx, SIZERESERVEDNAMES
.while ecx
push ecx
lodsd
invoke lstrcmpi, pStr, eax
[b] pop ecx
.break .if (eax == 0)[/b]
dec ecx
.endw
.if (ecx)
invoke lstrcat, pStr, CStr("_")
.endif
ret

CheckReservedNames endp


You had it breaking before the pop ( :tongue: ), so i reversed it as shown above. (It crashed on the first 'add' method, but it did concatenate the underscore nicely.

Thanx again for you help...
:alright:
NaN
Posted on 2002-12-23 17:12:37 by NaN
Oh yes, one should never do such quick shots. Its "100% positively sure" that you will implement more new bugs than to eliminate :mad:

Anyway, the new compiled version is attached.

Japheth
Posted on 2002-12-23 18:03:43 by japheth
Im sorry, i was not trying to take shots at you.. I do appreciate the work you have done with your tool, and the work your doing now..

Thank you very much..
:alright:
NaN
Posted on 2002-12-23 18:06:23 by NaN
BTW, just to let you know, i the latest version seems to run perfect. It transcribed the entire AutoCad tupelib and ran fine the first time...

I also discovered two more reserved words: "Align" and "Group" (Didnt know group was a reserved word, but anyways ;) )

Thanks again..!

(not to learn how you implement your classes ;) )


:alright:
NaN
Posted on 2002-12-23 18:49:32 by NaN
And more found:

"Wait"

"Goto"

"Repeat"

"Even"

"Rept"

"Or"

"Name"

"Comment"

"Union"


:rolleyes: :rolleyes: :rolleyes: NaN :rolleyes: :rolleyes: :rolleyes:
Posted on 2002-12-23 19:57:10 by NaN
Wow!

Man those macros really add up in the end.

The AutoCad.inc file comes to : 6,966 Lines of code
The Office97.inc file comes to : 2,506 Lines of code
The Excel8.inc file comes to : 18,033 Lines of code

Plus Windows.inc!

Your COMView tool has come thru with flying colors (few extra bumps like above postings, and string too long protos, but these are MASM32 limitations, not your tool!)

The compile time on my AMD 800 Duron is Approx 10 sec. :eek:

However, these are probably the largest programs i could bring together! So everything should be downhill from here (under 10 seconds ;) )

Thanks for all your help Japheth! Hope the above reserved words are some help to you!

:alright:
NaN
Posted on 2002-12-23 20:31:17 by NaN
Thanks NaN,

I'm afraid after some time it ends up having all MASM names in the "reserved" names table :) .

Japheth
Posted on 2002-12-24 14:27:44 by japheth