[VB6] Modern Shell Interface Type Library - oleexp.tlb

[Elroy]

I apologize to the handful of people who've already downloaded the new 6.5 release, I forgot to include the new radio management APIs in the build list, and the source file was missing the IRadioManager interface that toggles airplane mode.

Please grab the new oleexp65-R1.zip if you originally had oleexp65.zip.

No problem, Fafalone. I (for one) appreciate all the work you've done with this thing. Also, not sure I see the problem with returning HRESULT.

[fafalone]

Thanks

HRESULT... In C/C++ there's no automatic error handling... an interface method informs you an error occurred by returning a negative HRESULT. VB consumes this and hides it for its automatic error handling system. In C/++ you have to check it yourself; in VB, VB checks it, and raises an error you can handle with 'On Error GoTo' on 'On Error Resume Next'.

The problem is VB is essentially treating every error as a critical failure with the 'GoTo' option... a lot of the time, you don't want to jump out to an error handler and abandon the entire method, for example with enumerators-- running out of items is the inevitable end of a COM enumeration. On Error GoTo sucks for that. But Resume Next, you often don't want to disable VB's natural error handling for all the VB-native code too, so you might find yourself needing to change error handling tons of times.

Personally I wish there was an option for 'Ignore errors for interfaces I've defined' option. That's what nebeln is essentially trying to do. The problem is a lot of people don't *want* to be responsible for all the error handling themselves, and VB (and tB for now) never built the special handling required to allow Implements where there's no HRESULT. (It's more complex than you'd think, after talking to Wayne about how it can be implemented-- essentially in tB when this is supported, you'll be forfeiting automatic error handling and will have to both handle internal errors yourself and be responsible for HRESULT codes returned to outside callers). Another issue is all the SDK examples are in C++, and it's tough when you're just learning how to use all these interfaces to re-architect the code you're porting to account for not doing like the SDK and handling errors with SUCCEECED but instead jumping out of the code flow. Struggled with it myself at the beginning; still forget to handle it right sometimes.

VB6 adds to the complications in that if you do leave it as HRESULT, it sometimes messes with the error info. tB has Err.LastHResult to help with this; it guarantees accuracy for the last HRESULT independent from the VB translation of Err.Number.

There's a very strong bias against OERN in the community, but I find myself more and more wanting to just use it for entire methods in oleexp/WDL-heavy calls. Especially when I don't really understand what I'm doing; like my DirectComposition example, every method is OERN so I could follow the SDK as closely as possible.

[AAraya]

[EDIT]

Ignore the post below.

The old TLB did not need to be unregistered. I just had to read and follow the upgrade instructions fafalone provided here.

=====

I have an older version of this type lib (v4.2 from 2017) which I'm trying to unregister so that I can register the new one so that I can use your ucShellBrowse control which is my ultimate goal in this. But I'm coming up against the following error when I try to run "regsvr32 /u" on the old version of the TLB:

"The module oleexp.tlb may not be compatible with the version of Windows that you're running. Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe."

I'm on Windows 10, 64 bit. I've tried both the 32 and 64 bit versions of regsvr32. I'm running the Command Line as admin. Nothing works.

I don't normally have issues registering and unregistering files.

Help! Anyone???

[VanGoghGaming]

Regsvr32 only works with DLL and OCX files. Just overwrite your old oleexp file with the latest version and you're done.

[AAraya]

Regsvr32 only works with DLL and OCX files. Just overwrite your old oleexp file with the latest version and you're done.

Yeah, I knew that years ago when I regularly worked with TLB files. It's been a while since I've had to update one. Thanks for the refresher!

[fafalone]

There's some benefits to a TLB that needs to be registered/reregistered properly every upgrade, but I've avoided triggering that requirement just so you never need to worry about registration with oleexp.

Specifically, you know that error you sometimes get with passing UDTs 'Only publicly defined blahblahblah'... well those can be avoided if you associate a GUID with the UDT. But then you can't just overwrite the old typelib or things go off the rails; you have to unregister it, overwrite, and register (albeit not with regsvr32, but a typelib-specific tool).

[fafalone]

Project Updated - oleexp v6.6

(oleexp 6.6 - Release 06 June 2024)
-Added Direct3D 9 interfaces(courtesy of The trick for the core interface set
-Added DXVA2 and DXVAHD interfaces
-Added all Background Intelligent Transfer Service interfaces and coclasses
-Large expansion of Direct3D 12 interfaces
-Added Direct3D 12 Video interfaces
-Some misssing Direct3D 11 interfaces
-Added Windows Media Device Manager interfaces and coclasses
-Added DirectML interfaces (directml.h, 100%)
-Added Virtual Disk Service interfaces
-Added UPnP interfaces (upnp.h, upnphost.h, 100%)
-Added INATExternalIPAddressCallback Interface, for use with NATUPnP Type Library v1.0 (NATUPNPLib, included with Windows)
-Added VBA-related interfaces from vbinterf.h (100% coverage)
-(Bug fix) MFMEDIASOURCE_CHARACTERISTICS, MF_SOURCE_READER_FLAG, and MF_SOURCE_READER_CONTROL_FLAG enums all values incorrect.
-(Bug fix) SHCreateStreamOnFileEx was defined in wrong dll.
-(Bug fix) The following UDTs contained unsupported types: LOGPALETTE, NETRESOURCE, OLEUICONVERT, PUBAPPINFO, KSJACK_SINK_INFORMATION, D3D12_META_COMMAND_DESC, D3D12_AUTO_BREADCRUMB_NODE1, D3D12_FEATURE_DATA_PROTECTED_RESOURCE_SESSION_TYPES, D3D12_VIDEO_EXTENSION_COMMAND_PARAMETER_INFO, SPDISPLAYPHRASE, BASEBROWSERDATAXP, BASEBROWSERDATALH, TOOLBARITEM, and DML_ADAM_OPTIMIZER_OPERATOR_DESC.

IMPORTANT: DUE TO ATTACHMENT SIZE LIMITS, THE DOWNLOAD STRUCTURE HAS CHANGED. READ ZIP CONTENTS.

[xiaoyao]

It took several years to make this TLB registration DLL registration tool. Because sometimes there are some TLBs referenced in the system, it is impossible to re-register after changing the path. Activex DLLs require administrator privileges to register, and.net DLLs are often registered successfully on different computers but cannot be used. It's really a headache, so I developed this small tool, and it's better to drag files later. The top function is added, but the pop-up dialog box will run to the back of the window and can not be clicked, all kinds of conflicts. Running under LINUX WINE, I accidentally searched out all the DLLs in the C disk. There are more than tens of thousands of data, and the total number has become negative. Then I can only use the API to locate a certain line and get the current data. But the event of the control cannot be used again. Widgets are also sometimes a lot of work, containing 10-50 technical difficulties.

[fafalone]

I can't understand what you're talking about and it seems unrelated to oleexp.

oleexp has lighter registration requirements than OCX controls or some other typelibs because it doesn't use registered types; you can just overwrite old versions with new versions or use a register/unregister tool that calls these simple APIs;

Declare Function LoadTypeLib Lib "oleaut32" _
                              (ByVal szFileName As Long, _
                              lplptlib As Any) As Long   ' lplptlib As Long

Declare Function RegisterTypeLib Lib "oleaut32" _
                              (ByVal ptlib As Any, _
                              ByVal szFullPath As String, _
                              ByVal szHelpDir As String) As Long

Declare Function UnRegisterTypeLib Lib "oleaut32" _
                              (GUID As GUID, _
                              ByVal wVerMajor As Long, _
                              ByVal wVerMinor As Long, _
                              ByVal lcid As Long, _
                              ByVal SYSKIND As SYSKIND) As Long

'or newer x64 compat defs
Public DeclareWide PtrSafe Function RegisterTypeLib Lib "oleaut32" (ByVal ptlib As ITypeLib, ByVal szFullPath As String, Optional ByVal szHelpDir As String) As Long
Public Declare PtrSafe Function UnRegisterTypeLib Lib "oleaut32" (ByRef libID As UUID, ByVal wVerMajor As Integer, ByVal wVerMinor As Integer, ByVal lcid As Long, ByVal SYSKIND As SYSKIND) As Long
Public DeclareWide PtrSafe Function RegisterTypeLibForUser Lib "oleaut32" (ByVal ptlib As ITypeLib, ByVal szFullPath As String, ByVal szHelpDir As String) As Long
Public Declare PtrSafe Function UnRegisterTypeLibForUser Lib "oleaut32" (ByRef libID As UUID, ByVal wVerMajor As Integer, ByVal wVerMinor As Integer, ByVal lcid As Long, ByVal SYSKIND As SYSKIND) As Long

[7edm]

fafalone, just to follow up on this and to clear out any confusion xiaoyao's post may have created. I have "OLEEXP - Modern Shell Interfaces for VB6, v4.7" as oleexp.tlb in SysWow64. So I can just overwrite that one with version 6.6, right?

[fafalone]

fafalone, just to follow up on this and to clear out any confusion xiaoyao's post may have created. I have "OLEEXP - Modern Shell Interfaces for VB6, v4.7" as oleexp.tlb in SysWow64. So I can just overwrite that one with version 6.6, right?

Yes that's correct.

There's an issue with doing that for 4.6 or earlier since I inadvertently changed the project GUID in 4.7, but it's been the same ever since so simple overwriting is only a problem for 4.6 and earlier. 4.7 and up are good. You'd only need to use the unregister/register method if you wanted to change the path of newer versions.

[7edm]

Ok, that was interesting/useful information, because when I look in VB6's references dialog I also see OLEEXP - olelib With Modern Interfaces v4.62, but in a local forder outside of system folders. Is this your old version then? I have no clear memory of why I have it there so that's why I ask, but it's not "in use" by any of my projects so can just be deleted then?

[7edm]

Ops, at a closer look I see that the oleexp.tlb file is not even present in that non-system folder anymore, so this is obviously some leftover in the registry. Which leads to the question, is it possible to unregister it without the file present?

EDIT: Found the old zip file so nop with missing file.

[xiaoyao]

Ops, at a closer look I see that the oleexp.tlb file is not even present in that non-system folder anymore, so this is obviously some leftover in the registry. Which leads to the question, is it possible to unregister it without the file present?

EDIT: Found the old zip file so nop with missing file.

It should be possible. So my registration tool is based on this principle, first-register the old version, then un registration, and then register the new version.

At the earliest time, my tool was only dedicated to t1b registration.Because after the TLB reference, if you move the location of the file, you will fail to re-register. Especially the one with the same name but a different GUID.

The first step is to find the old version, re-register it first, and then uninstall the registration.You can put tlb file in any director.

Then register a new tlb file, which basically requires three steps.

[fafalone]

Great, go make your own thread for your tool.

Here's a much simpler one by Brad Martinez (his website is long-since defunct, there were tons of great projects on it).

[7edm]

Great! Did the job.

[xiaoyao]

about regtypelib.zip
Does he have a 64-bit version of the source code?

Test whether the 64-bit system can be used.
In the future, if a piece of code can support both 32-bit and 64-bit.
At the same time, it is more convenient to do the attributes of the two platforms.
You can add such a flag attribute to it.
(for x64/x86)
Because Vba and twinbasic need 64 bits.

You are the biggest contributor in the world to the expansion of TLB's various functions.

You use your spare time to complete these free products. Contributed hundreds of thousands of dollars of intellectual power to our CP community.

[fafalone]

oleexp.tlb is for 32bit only, it will not work with 64bit tB or VBA.

For 64bit tB, as the first post notes, I have a replacement called 'Windows Development Library for twinBASIC' (WinDevLib). It covers 100% of oleexp.tlb and also has 6000+ of the most common APIs declared.

[tmighty2]

I am trying to use GetTickCount.

I have referenced OLEEXP - Modern Shell Interfaces for VB6, v6.6 (oldexp.tlb) to my project, thinking that having to declare the function is no longer required.
Yet VB6 does not recognize it and tells "Variable not found". Same as with GetCursorInfo (which I had declared as Private Declare Function GetCursorInfo Lib "user32" (pci As CURSORINFO) As Long)

What am I missing?

Here is my code:

Option Explicit

Private Sub Form_Load()

    Dim l&
    l = gettickcount
    

End Sub

[VanGoghGaming]

"GetTickCount" is not defined in oleexp, in fact many other API functions are missing as well. Some time ago I was looking for a comprehensive TypeLib that would expose a complete set of API functions but in time I came to appreciate the flexibility of your own API declarations since often times the TypeLib declaration is not well suited for your purposes. Still, oleexp is great for its COM interfaces which you cannot declare yourself in VB6 code.

[tmighty2]

Ok, and how should I handle LOGFONTA?

In oletlbexp.tlb it is declared as

Sub ConvertFontFaceToLOGFONT(Font As IDWriteFontFace, logFont As Any)
Member of oleexp.IDWriteGdiInterop

Currently I have declared it myself like this

Public Declare Function CreateFontIndirect Lib "gdi32" Alias "CreateFontIndirectA" (lpLogFont As LOGFONTA) As Long

I once copied it from somewhere and just used it. Now I have removed the "type LOGFONTA" because I thought it is contained in oletlbexp.tlb anyways, and now I have to back it back it, therefore I would like to ask how you others handle it.

I was so much hoping to be able to get away from having declare such things myself.

[VanGoghGaming]

Yeah, TypeLibs are definitely not the magic bullet you were hoping for. In this example you would need to declare the LOGFONT structure yourself before using it as a parameter in the function call. I would go for the LOGFONTW structure though since it's Unicode compatible.

You could use the Object Browser (press F2 in IDE) to check whether a certain function, type, constant or enum is already declared in oleexp or not.

[fafalone]

If you all moved on to twinBASIC, oleexp's successor, WinDevLib, that does have the extremely expansive API coverage you're looking for. 6,000+ APIs, 5,600+ UDTs and 5,400+ enums for them in addition to all the interfaces covered by oleexp. And you can of course override them with a local declare if you want a different prototype, though tB supports overloads so I've added many of the most popular alternates.

But you can pass a locally defined UDT to an interface expecting it via As Any or LongPtr in VB6/oleexp.

[tmighty2]

Thank you!

[tmighty2]

Can I create PWA (progressive web apps) with TB?

[fafalone]

Can a standard Win32 exe or DLL act as a progressive web app?

If it can than yes, since if you really want to you can drop down to writing your own entry point if need be. But it would probably not be worth the hassle.

[VanGoghGaming]

When you have a little free time could you take a look at the ARRAYDESC structure as it seems the MSDN definition is different from the one in oleexp? I've ran into this issue when doing some pro-bono work for xiaoyao! The structure still works as it is but it's incomplete and some features are unavailable...

[yereverluvinuncleber]

Wow! Working for xiao... how's that working out? Maybe you could become his unofficial translator


Good luck to you both in your new endeavour.

[fafalone]

The last element is a variable C-style array; VB6 doesn't support them (nor does tB for now). It says 1, but that's a placeholder, there will be cDims elements to rgbounds.

There's generally 3 options;

1) Use everything up to the array as just a header,

2) Take a guess at the highest number ever needed and use that, or

3) If it's for receiving data from outside sources only, substitute a SAFEARRAY, where you first copy the static part, determine the needed number of elements, redim, then copy the remaining data to arr(0).

The choice to use 1 here goes back to olelib; I generally prefer 2. (It's apparently missing from WinDevLib, next version will use 2 with it buffered to 16). But never saw a compelling reason to break compatibility.

[VanGoghGaming]

Yeah, number 2) looks like the preferred choice but from my testing there seems to be something wrong with cDims as well (it was populated with a random integer in the thousands and sometimes negative too)... The only member that works as expected is the first one, tdescElem.

Wow! Working for xiao... how's that working out? Maybe you could become his unofficial translator

LoL, chuckled prolly more than I should have at this one! Actually the only reason I engaged was he seemed genuinely interested in the thread and made an effort to sound quite intelligible for once. Hope he keeps it up.

[fafalone]

typedef unsigned short VARTYPE;
typedef struct tagTYPEDESC
    {
    /* [switch_is][switch_type] */ union 
        {
        /* [case()] */ struct tagTYPEDESC *lptdesc;
        /* [case()] */ struct tagARRAYDESC *lpadesc;
        /* [case()] */ HREFTYPE hreftype;
        /* [default] */  /* Empty union arm */ 
        } 	DUMMYUNIONNAME;
    VARTYPE vt;
    } 	TYPEDESC;

    typedef struct TYPEDESC {
        LONG pTypeDesc;
        short vt;
    } TYPEDESC;

typedef struct tagARRAYDESC
    {
    TYPEDESC tdescElem;
    USHORT cDims;
    /* [size_is] */ SAFEARRAYBOUND rgbounds[ 1 ];
    } 	ARRAYDESC;

    typedef struct ARRAYDESC {
        TYPEDESC tdescElem;
        short cDims;
    } ARRAYDESC;

It's all correct... if you're coping things around from memory pointers, are you accounting for the hidden padding? There's two hidden padding bytes at the end of TYPEDESC, and if you're working with ARRAYDESC, there's two padding bytes after cDims before rgbounds starts.

...

I try to help xiaoyao too but even when I go out of my way to translate 'We can't understand you, please use a different translator." into Chinese to get the point across, he just ignores it and continues unintelligibly most of the time.

[VanGoghGaming]

I'm not copying anything around from pointers, I let VB6 do the dirty work automatically behind the scene since that's far less error-prone:

Private Property Get GetArrayDesc(tArrayDesc As oleexp.ARRAYDESC, ByVal pArrayDesc As Long) As oleexp.ARRAYDESC
    If pArrayDesc Then PutMem4 ByVal VarPtr(pArrayDesc) - 4, pArrayDesc: GetArrayDesc = tArrayDesc
End Property

Private Property Get GetFuncDesc(tFuncDesc As oleexp.FUNCDESC, ByVal pFuncDesc As Long) As oleexp.FUNCDESC
    If pFuncDesc Then PutMem4 ByVal VarPtr(pFuncDesc) - 4, pFuncDesc: GetFuncDesc = tFuncDesc
End Property

Private Property Get GetTypeDesc(tTypeDesc As oleexp.TYPEDESC, ByVal pTypeDesc As Long) As oleexp.TYPEDESC
    If pTypeDesc Then PutMem4 ByVal VarPtr(pTypeDesc) - 4, pTypeDesc: GetTypeDesc = tTypeDesc
End Property

This code is for determining the types of function parameters at runtime using "ITypeInfo.GetFuncDesc". So far everything checked out spot-on (it even retrieves the default values of optional parameters when specified). Only the cDims member of ARRAYDESC failed so far but maybe the data wasn't there to begin with. I mean IntelliSense doesn't show array dimensions on array parameters so maybe cDims really is undefined (and they didn't zero-out the memory before allocating the pointer). Sample output at runtime:

Function ShowMsgBox(sMessage As String, [bCancel As Boolean], [ByVal vTestParameter As Variant = "Test Optional Variant Parameter Default Value"]) As Currency()

[fafalone]

PutMem4 is copying around from pointers... I'm not following why you're using -4

[VanGoghGaming]

It's a trick I've picked up from The Trick (amazingly enough). It copies the second parameter (which is a pointer) over the address of the first parameter which is at offset -4 bytes on the stack. Both parameters are on the stack (4 bytes each), the first one is the address of an UDT (that is declared outside the function). The second parameter must be declared "ByVal" so that VarPtr reports the address on the stack. After the operation, the UDT will no longer point to its original declaration but will reference the new pointer instead. This doesn't affect the UDT variable declared outside the function at all (that's just a placeholder).

Therefore it effectively allows read-write access to the pointer by means of an UDT (without copying the contents back and forth). Well in this case the UDT is copied via assignment to the return value of the Property Get. I'm pretty bad at explaining, haha.

I guess it's an equivalent to the new type-cast feature introduced in TwinBasic.

[VanGoghGaming]

Is there something wrong with the definition of "SHCreateMemStream" from oleexp?

Private Declare Function SHCreateMemStream Lib "shlwapi" (pInit As Any, ByVal cbInit As Long) As oleexp.IStream

Private Sub Form_Load()
Dim pStm As oleexp.IStream
    Set pStm = oleexp.SHCreateMemStream(ByVal 0&, 0) ' Compile error: Type mismatch
    Set pStm = SHCreateMemStream(ByVal 0&, 0) ' Okay
End Sub

[fafalone]

Yes it should just be IStream* instead of IStream**. Will be fixed in the next release.

Congrats, you also helped find a bug in twinBASIC because I tested it there too and there was no type mismatch, meaning it ignored the error.

[VanGoghGaming]

Sure, I'll add it.

I wasn't really planning on doing a large expansion of the included APIs though as oleexp's days are numbered... once twinBASIC supports exporting to .tlb, I'll only be updating the tbShellLib codebase as it will allow a single source for VB6, VBA7 32/64bit, and tB 32/64bit. If you (or anyone) wanted to create an automated tool that could take VB API declare syntax and convert it to IDL syntax, then it would just be a few minutes instead of weeks of work and it would be a different story; at least for the APIs I've added to tbShellLib (I didn't have SHCreateMemStream until today but I have added a whole lot of others on top of what was in oleexp-- including all of gdip... there's about 2800 now, compared to 1000 in oleexp). I already have them grouped by DLL, so there wouldn't be a need to sort them.

Just e.g.

Public DeclareWide PtrSafe Function SHCreateMemStream Lib "shlwapi" (pInit As Any, ByVal cbInit As Long) As IStream

    [entry("SHCreateMemStream")]
    IStream** SHCreateMemStream([in] LPVOID pInit, [in] ULONG cbInit);

Typedefs and enums are more straightforward.

There's a few less obvious things; like ByRef interfaces must be [out] IFoo**, ByVal must be [in] IFoo*.. but As Any can only be void*; and the VB declares don't consistently use ByRef explicitly or implicitly.

Looks like it's been only one and a half years since I asked for "SHCreateMemStream" to be included in oleexp so it's only fitting that I am the one to discover this bug!
On the bright side TB still doesn't support exporting TLBs but at least it has Naked functions now!

[fafalone]

Yeah unfortunately there;s been considerable delays, but adding features to support VB6 itself not involving running VB6 projects in tB is obviously a very low priority; I've definitely voted myself for asm support being a v1 target unlike tlbs... Naked functions and Emit took Wayne 2 days to add, so that's not to blame anyway.

If you want WinDevLib's expansive API support, use twinBASIC

Last month I did add a number of overloads for oleexp compatibility once tB supported rewritinng API defs to make the last [out] a return ([PreserveSig(False)] attribute now applying to API declares). And interface sig changes for compat with oleexp and The trick;s typelibs. To make the transition even easier.