TypeLibInspector - OleView was yesterday

[doudou]

TypeLibInspector is a property inspector and documentation generator for COM type libraries.

Features

• Display TypeLib information in comprehensible form
• Choose between OLE Automation/VTable view on dual interfaces
• Search TypeLib for types, properties, methods
• Save TypeLib information as XML document
• Export documentation as HTML
• Export constants from TypeLib for use in AU3
• Support custom export plugins (s. attached examples)

TypeLibInspector can use both TLBINF32 and TLI.au3 as its backend (configurable in Tools menu). If nothing different set by user, it first tries to load TLBINF32 and falls back to TLI.au3 if TLBINF32 was not found. The preference for TLBINF32 is because this component is about 4 times faster than TLI.au3 (not surprising - TLBINF32 is native compiled library) but if you plan to export something like COM IDL (f.i. through a custom plugin) you will have to switch to TLI.au3 for TLBINF32 distorts the type information and even drops some of it (to match with its main target: Visual Basic).

All application sources are attached, please refer to README.txt for details.

Note: to install additional plugin package extract it in TypeLibInspector's "plugins" directory.

---

(Below occurrences of "TypeLibInspector.exe" can be substituted by "AutoIt3.exe PATH_TO_PROJECT\src\au3\TypeLibInspector.au3")

Using it with Windows shell

If TypeLibInspector finds path to a type library file in the 1st argument of command line, it opens the file:

TypeLibInspector.exe C:\Windows\system32\msxml.dll

As type libraries can be contained in various type of files (DLL, OCX, EXE etc.), it is not very convenient associating every possible type with TypeLibInspector, I recommend creating a link to it in the SendTo folder.

Using it from within PSPad (or other editors)

Since version 0.1.0 TypeLibInspector supports custom type queries in the second command line argument. If this parameter specified like:

TypeLibInspector.exe C:\Windows\system32\msxml.dll --selectType=@name='IXMLDOMNode'

the type library will be opened and the type matching query (if one found) will be highlighted.

For working with programming code editors a special feature of TypeLibInspector could be of particular interest: given a ProgID (or class name in terms of ObjCreate()) it can search for associated type library + type system wide. Triggering this function is simple (note "-" in the first argument):

TypeLibInspector.exe - --selectType=@progid='Excel.Application'

So in PSPad you can create a tool link with settings like

Name: TypeInfo
Path: TypeLibInspector.exe
Parameters: - --selectType=@progid='%SelText%'

Highlighting ProgID in the code window and executing the link will open TypeLibInspector displaying the properties of the associated object. I am not familiar with Scite but am sure that these instructions can be easily translated for it too (if you know how, please, be so kind and share your hints here).

---

Version 0.1.1

• Compatible with TLI.au3 1.0.8
• Compatible with AutoIt 3.3.16.0
• Fixed various issues when running on 64 bit system

Version 0.1.0

• Compatible with TLI.au3 1.0.5
• Array type handling improved
• Added possibility of type search based on custom query at start-up
• All external types are now linked with their libraries

Version 0.0.3

• Support for array types added
• Added possibility to pass parameters to XSLT processor (s. JaCoB Plugin)
• Plugin output file names made configurable (s. JaCoB Plugin)

Version 0.0.2

• Navigation history added
• Support for TLI.au3 v. 1.0.3 added
• Added encoding declaration in CSS

Requirements

• MSXML2 (shipped with most Windows versions)
• IE (my respect if you managed to remove it from your system)
• AutoItObject
• TLI.au3 (min. 1.0.5)

TypeLibInspector_0.1.1.zip

TypeLibInspector-0.1.1-sfx.exe

TypeLibInspector64-0.1.1-sfx.exe

Edited April 15, 2022 by doudou
Version 0.1.1 released

[ValeryVal]

Very good!

[ValeryVal]

1. Is it bug (file tldoc-html-common.inc.xsl)?:

<xsl:if test="@indirection &gt; 0">Pointer to </xsl:if>

<xsl:if test="@indirection &gt; 1">pointer to </xsl:if>

<xsl:if test="@indirection &gt; 2">pointer to </xsl:if>

Sometimes it outputs like this:

Pointer to pointer to pointer to ....

2. File tldoc-view.html has tag:

<meta http-equiv="content-type" content="text/html; charset=UTF-16">

but with it it can't to include my updated style sheets tldoc-view.css

With UTF-8 it works fine, though...

Thanx

[doudou]

Very good!

Thanks for the compliment.

1. Is it bug (file tldoc-html-common.inc.xsl)?:

<xsl:if test="@indirection &gt; 0">Pointer to </xsl:if>

<xsl:if test="@indirection &gt; 1">pointer to </xsl:if>

<xsl:if test="@indirection &gt; 2">pointer to </xsl:if>

Sometimes it outputs like this:

Pointer to pointer to pointer to ....

Why is that a bug?

It does exactly what meant to do: for TYPE* it shows "Pointer to TYPE", for TYPE** - "Pointer to pointer to TYPE" etc. You are familiar with pointer concept, I presume?

2. File tldoc-view.html has tag:

<meta http-equiv="content-type" content="text/html; charset=UTF-16">

but with it it can't to include my updated style sheets tldoc-view.css

With UTF-8 it works fine, though...

You shouldn't change encoding of tldoc-view.html to anything else but UTF-16. This file is used internally as "frame" for XSL transformation in memory which is always performed in UTF-16. If you mix up encodings here the results could be unpredictable. If you want to modify tldoc-view.css using international characters better change the encoding of this file to UTF-16.

[ValeryVal]

About "UTF-16". My browser is Firefox. It seems to do the same as

in this FireFox case.

[doudou]

About "UTF-16". My browser is Firefox. It seems to do the same as

in this FireFox case.

Yes. As I told you, add

@charset "UTF-16";

at the beginning of the stylesheet and save it in corr. encoding.

[ValeryVal]

Why is that a bug?

It does exactly what meant to do: for TYPE* it shows "Pointer to TYPE", for TYPE** - "Pointer to pointer to TYPE" etc. You are familiar with pointer concept, I presume?

Ahh.. That's right.

If you mix up encodings here the results could be unpredictable. If you want to modify tldoc-view.css using international characters better change the encoding of this file to UTF-16.

tldoc-view.html and tldoc-view.xsl has already different encoding, I think.

The first file has UTF-16

and the second one - UTF-8

[doudou]

tldoc-view.html and tldoc-view.xsl has already different encoding, I think.

The first file has UTF-16

and the second one - UTF-8

This is correct. By "mix up" I meant that MSXML would always use UTF-16 for XSL transformations in memory, no matter what encoding is defined in the source file - so trying to utilize UTF-8 source could produce jibberish.

If you want to take influence on how exported HTML looks it is better to make a copy of the distributed plugin and modify it in the way so it doesn't use shared application resources (HTML, CSS, XSL), then you can play with encodngs as you wish without risking application malfunction.

[ValeryVal]

Updated xml&xsl files works fine with UTF-8, too.

This is documented in article

Best Practices for XML Internationalization, where they shows examples with only UTF-8 encoding.

BTW. In other article they recommend:

UTF-16 is more efficient than UTF-8 for Chinese, Japanese, and Korean (CJK) ideographs. When using UTF-16, each character requires two bytes, while many will require three bytes under UTF-8 encoding. Either UTF-8 or UTF-16 should work. However, it is wise to test actual transformations with both encodings to determine which results in the smallest file for your particular data. On a pragmatic note, many applications and operating systems, particularly Unix and Linux variants, offer better support for UTF-8 encoding.

As nearly every XSLT example in this book has shown, the <xsl:output> element determines the encoding of the XSLT result tree:

<xsl:output method="html" encoding="UTF-16"/>

If this element is missing from the stylesheet, the XSLT processor is supposed to default to either UTF-8 or UTF-16 encoding.[42]

[42] The XSLT specification does not say how the processor is supposed to select between UTF-8 and UTF-16.

My case isn't Chinese, Japanese, and Korean (CJK) ideographs. So it will be better to use UTF-8 encoding, I think.

Thank you for help and TypeLibDocumenter script.

[doudou]

Updated xml&xsl files works fine with UTF-8, too.

This is documented in article

Best Practices for XML Internationalization, where they shows examples with only UTF-8 encoding.

I'm afraid, you don't understand me fully. tldoc-view.html is not intended to be used anywhere outside the application's view, which is rendered by MSMXL in-memory transformer that doesn't care much about standards nor it respects encoding declaration in the source files, all characters are always handled as UTF-16. If you try to feed alternatively encoded sources to it, it could work - as long as everything is within ASCII range - but it would produce unreadable output for higher UNICODE code-points. Firefox isn't an issue at all here because the control in the view is embedded IE.

[ValeryVal]

Russian version of your TypeLibDocumenter is working here.

It can make valid pages by updated *.xml files with Russian UTF-8 characters.

As for MSMXL, my rss_viewer have been using it's transformation methods as soon as 2006.

[doudou]

Russian version of your TypeLibDocumenter is working here.

It can make valid pages by updated *.xml files with Russian UTF-8 characters.

Would you please tell in details, what you did and for what purpose? Not that we talk about different things.

As for XSL encoding in MSXML I recommend reading Encoding issues using the Microsoft XSLT engine.

[ValeryVal]

Would you please tell in details, what you did and for what purpose? Not that we talk about different things.

OK! I have translated into Russian text items of the following files

tldoc-au3-const.xsl, tldoc-defs.inc.xml, tldoc-html-common.inc.xsl,

tldoc-html-functions.inc.xsl, tldoc-html-multi.xsl, tldoc-html-single.xsl

tldoc-view.xsl.

For example (tldoc-html-common.inc.xsl):

<div><strong>Target system: </strong>

to

<div><strong>..Russian words here..: </strong>

with encoding UTF-8

Documenter showed Russian chars correctly.

After then I was trying to test usage of background style for <h1> tag in tldoc-view.css. Sample was the native AutoIt3 documentation style sheet:

h1 {

font-family: "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif, "MS sans serif";

font-size: small;

line-height: normal;

color: #FFFFFF;

background-image: url(../images/blue_gradient_1024x24.jpg);

background-repeat: repeat-y;

}

But new strip (instead of your blue) didn't work.

Why?

I found that reason of it was encoding UTF-8 in tldoc-view.xsl.

That was my question about UTF-16 encoding in tldoc-view.xsl!

After replacement UTF-16 in tldoc-view.xsl to UTF-8 the Documenter showed gradient strip needed (blue_gradient_1024x24.jpg).

That's all.

Edited May 17, 2010 by Valery

[ValeryVal]

Sorry for OT but we have today the World Information Society Day.

See about it here

[doudou]

...

But new strip (instead of your blue) didn't work.

Why?

I found that reason of it was encoding UTF-8 in tldoc-view.xsl.

That was my question about UTF-16 encoding in tldoc-view.xsl!

After replacement UTF-16 in tldoc-view.xsl to UTF-8 the Documenter showed gradient strip needed (blue_gradient_1024x24.jpg).

That's all.

Ok, now you lost me.

The original files have following encodings:

tldoc-view.xsl -  UTF-8
tldoc-view.css -  UTF-8
tldoc-view.html - UTF-16

In this combination it is absolutely no problem to change the CSS like you did. Somehow there's something fused in steps you are describing.

Would be nice if you posted the modified files (not only for better understanding but also for people interested in Russian translation).

[ValeryVal]

Would be nice if you posted the modified files (not only for better understanding but also for people interested in Russian translation).

The simplest test will be following actions

- make new dir "images" in folder "res"

- add to it the file "blue_gradient_1024x24.jpg" from AutoIt3 doc

- change definition for h1 in tldoc-view.css (folder "css" in folder "res") to

h1 {

font-family: "Trebuchet MS", Verdana, Arial, Helvetica, sans-serif, "MS sans serif";

font-size: small;

line-height: normal;

color: #FFFFFF;

background-image: url(../images/blue_gradient_1024x24.jpg);

background-repeat: repeat-y;

}

- see the result

- answer the question "Is there new strip?"

I will send the Russian translation of *.xsl and *.xml files in other time.

Thank you.

[doudou]

- answer the question "Is there new strip?"

The answer is: yes. As you can see on screenshot 1 (IE) and 2 (FF after adding @charset "UTF-8"; to CSS) .

[ValeryVal]

So we have new degree of freedom or independent variable) for experiments with UTF. It is @charset "UTF-8"; in CSS file.

Yesterday I've been trying to change encoding UTF-16 <=> UTF-8 in

tldoc-view.html updated (with sample line in body like <h1>Sample</h1> to separate area of lookup.

Stylesheet (tldoc-view.css) had h1-style with

background-image: url(../images/blue_gradient_1024x24.jpg);
  background-repeat: repeat-y;

and first line

@charset "UTF-8";

and wthout it.

FF didn't show strip at all with/without @charset "UTF-8";.

IE6 exposed many new obscurities for me, including security issues.

This is dark place in IE for me and I'm glad that my steps can't be reproduced from the beginning.

My messages can be abstruse and strange for you and could be similar

irresoluble questions like

this

Outlet from this state is to go back to subject of this thread, I think.

[ValeryVal]

If so then my previous question is following:

2. File tldoc-view.html has tag:

<meta http-equiv="content-type" content="text/html; charset=UTF-16">

but with it it can't to include my updated style sheets tldoc-view.css

With UTF-8 it works fine, though...

I found that FireFox will show gradient strip if tldoc-view.html will be in UTF-8 format. But tldoc-view.html has to have line

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

Let we have shared sample - AU3Aut.dll

Next questions:

1. Can I change embedded CSS of page AU3AUTLib-1.0.html exported from Documenter?

2. Is there possibility to have history of clicks in Documenter GUI (to go back)?

3. Is there chance to collect doc line of COM interfaces AU3Aut.dll into separate resource file (for localization)?

ie

after line

_SelfID

we have english line:

Returns the ID of the currently executed script.

It would be nice to save it into some XML file in folder

/locale/en/docs.xml

Then for Germany it will be folder

/locale/ge/docs.xml

for Russian

/locale/ru/docs.xml

and so on.

[doudou]

I found that FireFox will show gradient strip if tldoc-view.html will be in UTF-8 format. But tldoc-view.html has to have line

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

I'm very sorry but I still don't understand what purpose this encoding juggling should serve or what the problem is. All versions of IE display everything nicely with original encoding combination, FF requires solely the correct encoding statement in 'tldoc-view.css' - this doesn't matter though because 'tldoc-view.html' is only used in internal view, which is embedded IE.

1. Can I change embedded CSS of page AU3AUTLib-1.0.html exported from Documenter?

Actually you can change whatever you want in the export procedure since it is performed via plugins. Make a copy of plugins\html-single.ini as, say, plugins\html-mine.ini and modify it like this:

[Plugin]
name=HTML (my file)
category=export
type=XSLExport
[XSLExport]
ext=html
xslt=mine\tldoc-html-single.xsl
splitOnBoundaries=0
copyResources=Icons,Images
displayResult=1
[CopyIcons]
src=%tldresdir%icons\*
dest=icons\
[CopyImages]
src=mine\images\*
dest=images\

Then create a directory plugins\mine, copy template tldoc-html-single.xsl in there and make desired modifications to it (f.i. manipulate CSS). Create a directory plugins\mine\images and populate it with images used in your template. Your new plugin will appear in Export menu next time TypeLibDocumenter is run.

2. Is there possibility to have history of clicks in Documenter GUI (to go back)?

If it was only clicks in the HTML view it would be very simple but since we can navigate in the TreeView as well, it would require a bit of programming. It's a good idea though and I'm adding this in the next release.

3. Is there chance to collect doc line of COM interfaces AU3Aut.dll into separate resource file (for localization)?

ie

after line

_SelfID

we have english line:

Returns the ID of the currently executed script.

It would be nice to save it into some XML file in folder

/locale/en/docs.xml

Then for Germany it will be folder

/locale/ge/docs.xml

for Russian

/locale/ru/docs.xml

and so on.

It is not that simple. COM has its own globalization layer controlled by LCID and it can change not only the doc string but the appearance of a TypeLib/component entirely. The names of types, methods, properties can be different or even not present in a certain locale. Currently TypeLibDocumenter supports only the default locale (user/system) and I am not sure yet what shape the view on globalization layers should assume but it is definitely subject for a future release. Edited May 18, 2010 by doudou