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

Project Updated - Version 6.1

Since the bugs discussed above are fairly significant, I wanted to update the full version now (especially since if you want to use oleexpimp.tlb it needs to be compiled against the current oleexp.tlb to avoid error 32810). This version contains the DirectWrite string interface bugfixes, a bug fix for INameSpaceTreeControlEvents that should hopefully help with right-click crashes, and the Vista+ TrayBand/DeskBand interfaces and coclasses that were inexplicably missing.

Full changelog:

(oleexp 6.1 - Released 02 March 2023)

• Added ITrayBand, IDeskBand2, IDeskBandInfo, IBandHost, and IBandSite interfaces, IMenuBand, and coclasses TrayDeskBand, TrayBandSiteServices
• Added IRegTreeItem interface
• Added IPrintDialogCallback/IPrintDialogServices interfaces.
• Bug fix: Certain DirectWrite interface members had ByRef Long for strings where they should have had ByVal.
• Bug fix: SHELLSTATE had an extra member on the end (shouldn't have impacted use, but if MS changed the API to look for an exact size it would be an issue).
• Bug fix: Attempted to correct INameSpaceTreeControlEvents context menu crashing.

These changes have also been made to tbShellLib as of v3.3.41.

---

NOTE: The file with INameSpaceTreeControl changes didn't save properly, so if you were among the first 3 people to download oleexp 6.1, before 11:50PM Eastern US time, you'll need to redownload to get those changes. Sorry, something is wrong with my VS install where it's indicating the file was saved and removing the *, only for the changes to be gone when reloaded or checked.

does it support webview2?
what's webview2 tlb for vb6？

It contains all of the COM interface definitions, Enums, and initialization APIs for WebView2.

It's for if you want to build your own implementation of it like Olaf did in RC6; it's not an implementation itself.

For an example of using these interfaces directly, twinBASIC has a WebView2 implementation using the interfaces directly (but not tbShellLib-based so expanding it would require extra steps since it doesn't contain every interface). New project->Samples->Sample 0 or Sample 9.

anyone translate oleexp.tlb to 64bit?

Quote:

---

Originally Posted by loquat

anyone translate oleexp.tlb to 64bit?

---

For VBA or for twinBASIC?

For twinBASIC, yes. tbShellLib contains all interfaces/APIs/etc from oleexp, compatible with 64bit. There's only a few small adjustments for a small number of differences (run replace-alls for changing oleexp.IUnknown with IUnknownUnrestricted, replacing several public aliases as tB doesn't yet have those, then delete all instances of 'oleexp.'; then a small percentage of APIs need return values moved back to being the last argument instead, as some legacy olelib APIs were rewritten to change a final [out] to [out, retval], a language feature not supported by VBx/tB Declare syntax).

For VBA, I'm waiting for twinBASIC to support exporting tbShellLib as a .TLB (a planned feature). It's not possible to compile a project like oleexp with midl, as midl force-includes some low level types and COM interfaces and refuses to allow you to replace them with vb6-compatible versions; I've spent a couple dozen hours trying to work around that with no success. oleexp is compiled with MKTYPLIB, which does not support targeting x64. Alternatives would have been far, far too much work.

Project Updated - Version 6.2

While I noted in another thread I won't be bringing expanded API sets to oleexp (unless someone writes a converter from VBA7->MKTYPLIB-compat IDL or wants to contribute)-- I am adding them to tbShellLib, which will eventually replace oleexp when twinBASIC supports exporting TLBs; I'm still maintaining all the same interfaces between the two. This update adds tons of new stuff over hundreds of interfaces:

(oleexp 6.2 - Released 01 April 2023)

• Added accessibility UI Automation interfaces and APIs.
  NOTE: This API had a number of *very* generically named enums, like FillMode and ToggleState; these have been prefixed with Uia_ to avoid conflicts. In most cases, the actual members were left alone, with the exception of LiveSetting (renamed Uia_LiveSetting), which had Off, Polite, and Assertive; these have been prefixed with Uia_ as well.
  NOTE: IUIAutomationAndCondition and IUIAutomationOrCondition have members that return a SAFEARRAY of IUIAutomationCondition... MKTYPLIB does not support this so these return a pointer you'll need to dereference.
• Completed Media Foundation interfaces up through the most recent Windows 11 SDK. This includes the capture engine and other entirely new feature sets.
• Added CoreAudio Spatial Audio interfaces (newer Win10 versions/Win11 only)
• Added IActiveScript and all related ActiveX Script Host / Engine interfaces.
• Added IPinnedList (Vista), IPinnedList2 (7 < Win10 1809), IPinnedList3 (>= Win10 1809), and coclass TaskBandPin. Added IStartMenuPin. Don't abuse these-- always ask user permission to pin.
• Added ITrayNotify and INotificationCB, coclass TrayNotify
• Added coclass TaskBand
• Added IHandlerInfo2, IDeskBar, IDeskBarClient amd IShellFolderBand
• Added IHostDialogHelper, coclass HostDialogHelper
• Added IFileSearchBand, coclass FileSearchBand
• Added IPropertyPage[2] and IPropertyPageSite interfaces.
• Added ISimpleFrameSite interface
• Added IDispatchEx interface and related interfaces IDispError, IVariantChangeType, IProvideRuntimeContext, IObjectIdentity, and ICanHandleException
• Added misc. interfaces ICurrentWorkingDirectory, IPropertyKeyStore, ISortColumnArray, IBannerNotificationHandler, IDelayedPropertyStoreFactory, IStorageProviderCopyHook, IDesktopGadget/Coclass DesktopGadget, IQueryCodePage, IStreamUnbufferedInfo, IUserAccountChangeCallback, IOpenSearchSource (with Implements- version in oleexpimp), IDestinationStreamFactory, ICreateProcessInputs, and ICreatingProcess.
• (mIID) Added EP_* GUIDs for IExplorerPaneVisibility
• (mIID) Added some missing SID_ guids.
• Bug fix: AUDCLNT_RETURNCODES were all incorrect.

Most of this was already in tbShellLib, what wasn't is now.

There's a bug in the declaration of "D3D11CreateDevice":

Code:

---

Dim lRet As Long, pID3D11Device As Long, pID3D11DeviceContext As Long, objID3D11Device As ID3D11Device, objID3D11DeviceContext As ID3D11DeviceContext

lRet = oleexp.D3D11CreateDevice(Nothing, D3D_DRIVER_TYPE_HARDWARE, 0&, D3D11_CREATE_DEVICE_BGRA_SUPPORT, 0&, 0&, D3D11_SDK_VERSION, objID3D11Device, 0&, objID3D11Device)
' returns error "887A0004"

Private Declare Function D3D11CreateDevice Lib "D3D11.dll" (ByVal pAdapter As Long, ByVal DriverType As Long, ByVal Software As Long, ByVal flags As Long, ByVal pfeatureLevels As Long, ByVal featureLevels As Long, ByVal SDKVersion As Long, ByRef ppDevice As Long, ByRef pFeatureLevel As Long, ByRef ppImmediateContext As Long) As Long

lRet = D3D11CreateDevice(0&, D3D_DRIVER_TYPE_HARDWARE, 0&, D3D11_CREATE_DEVICE_BGRA_SUPPORT, 0&, 0&, D3D11_SDK_VERSION, pID3D11Device, 0&, pID3D11DeviceContext)
' returns zero (S_OK)

lRet = VBD3D11.D3D11CreateDevice(Nothing, D3D_DRIVER_TYPE_HARDWARE, 0&, D3D11_CREATE_DEVICE_BGRA_SUPPORT, ByVal 0&, 0&, D3D11_SDK_VERSION, objID3D11Device, 0&, objID3D11DeviceContext)
' also returns zero (S_OK)

---

VBD3D11 is another TypeLib for D3D11 by wqweto

It seems that the "pFeatureLevels" parameter needs to be declared either as "ByVal Long" (as in the manual Declare above) or as "Any" (as in wqweto's TypeLib). Yours is declared as an "Enum" and you can't put "ByVal" in front of it (Type mismatch).

That's weird... I would have thought if FeatureLevels (the number of elements in pFeatureLevels) was 0, it wouldn't attempt to read it.

It's specified in the documentation, if it's zero then it's a combination of ALL features put together.

The next parameter is supposed to be a count of the elements you passed... If that's 0, why wouldn't you expect it to treat it as null/invalid?

Anyway, it will be As Any in the next update. Since it's an API declare it's interchangeable with locally defined ones.

While you're at it could you please add SHCreateMemStream as well? CreateStreamOnHGlobal is already included but SHCreateMemStream is so much better for creating streams! "shlwapi.dll" has many useful APIs that would make a great addition to oleexp...

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.

Code:

---

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.

I think I should really jump on this TwinBasic bandwagon and see what the hype is all about... It does sound like a preferable alternative to .NET!

Hello, I was seeing that Oleexp has ICoreWebView2, is there any example of use? Could the same be done with cWebView2 from RC6.dll?

thank!

@LeandroA
RC6 contains an implementation of WebView2... the interface definitions in oleexp are what you would need to create your own wrapper like RC6 does.

There are examples of using these interfaces directly-- twinBASIC has 2 built in WebView samples that create a browser directly from these low level interfaces. You could substitue the oleexp ones to create a VB6 port (and tbShellLib for tB has a complete set as well, the built in tB demos only have a minimal set to support the examples).


@VanGoghGaming

You really should check it out. I was surprised too at just how very far along it was after so many empty promises and projects that went nowhere fast. It can't run 100% of VB6 code yet, but it's getting awfully close. It even runs complex Active-X controls... I've made 64bit versions of my ucShellTree and ucShellBrowse control that can be used in tB like a VB .ctl, or compiled to an ocx and used in 64bit Office and .NET (and to a 32bit OCX to use in VB6).

On top of support VBA7 64bit syntax and all VB6 syntax, it's got tons of new features *right now*... not planned, but already implemented, I've been making a list, since the www site is very, very out of date:

• LongPtr data type (4 bytes on 32bit, 8 on 64bit)
• LongLong data type, available in both 32bit and 64bit (VBA LongLong is only available in 64bit Office)
• True Decimal data type instead of just inside a Variant.
• All the standard accessories for the new data types, e.g. DefDec/DefLngLng/DefLongPtr, CDec/CLngLng/CLongPtr, and vbDecimal/vbLongLong/vbLongPtr constants for type checking.
• Define interfaces and coclasses in language
• Implements allowed on inherited interfaces-- e.g. you can just implement IShellFolder2, and provide all the methods for IShellFolder, and tB will automatically respond to QI for IShellFolder *and* IShellFolder2.
• If you have an interface multiple others extend from, you can write multiple implementations, or specify one implementation for all: e.g. IOleWindow_GetWindow() As LongPtr Implements IOleWindow.GetWindow, IShellBrowser.GetWindow, IShellView2.GetWindow
• Implements allowed on interfaces with 'As Any' parameters-- you can substitute LongPtr.
• Implements Via to extend classes
• vbNullPtr allows passing null pointers to UDT members of APIs/interfaces (in VB6 you'd have to declare them As Any and then could pass ByVal 0)
• Short-circuit conditional operators OrElse and AndAlso
• Support for modern image formats
• Transparency on forms
• Bitshift operators << and >>
• New assignment operators: += -= /= *= ^= &= <<= >>=
• Thread safety/multithreading support-- no native language syntax yet (planned), but you can call CreateThread directly with no hacks
• Ability to define custom packing for UDTs with [ PackingAlignment(n) ] attribute
• AddressOf can be used on class/form/UC members, including from outside the class by specifying the instance. Also, no need for FARPROC-type functions, you can use it like Ptr = AddressOf Func
• Overloading, both with type of argument and number of arguments
• Generics
• DeclareWide to disable Unicode-ANSI conversion on API declares
• CDecl support for API calls (though The trick has a patch for VB6 that adds this)
• Continue For, Continue While, Continue Do, Exit While
• Return syntax for functions
• Err.LastHResult and Err.ReturnHResult to get/set COM interface hresults
• Parameterized class constructors
• [ Description("text") ] attribute for APIs, UDTs , and Consts that are shown in popups when you hover over uses of them
• Built in support for making standard DLLs with simple [ DllExport ] attribute
• Built in support for making kernel-mode drivers
• Built in support for overriding entry point
• Option to put all API declares in the import table rather than runtime calls like VB6 (VB6 puts TLB-declared APIs in the import table; tB replicates this too but further provides an option for in-project declares).
• Built in support to mark projects DEP-aware and LARGEADDRESSAWARE
• [ RunAfterBuild ] attribute-- you can specify a function that runs after your exe is built (there's App.LastBuildPath to know where it is if you're e.g. signing the exe)
• Register ActiveX builds to HKEY_LOCAL_MACHINE option
• Private/Public modifiers for modules and classes
• All tB-implemented controls support Unicode
• Detects stale/dangling pointers for strings, replacing them with warning symbols
• Warnings for likely-incorrect hex literals &H8000-&HFFFF and &H80000000-&HFFFFFFFF (these almost always should be e.g. &H8000& to avoid being interpreted as a negative Integer).
• tB-implemented controls all support x64 and are all dpi aware (Currently available ones: CommandButton, TextBox, ComboBox, CheckBox, OptionButton, Label, Frame, PictureBox, Line, Shape, VScrollBar, HScrollBar, Timer, DriveListBox, DirListBox, FileListBox, Image, TreeView, ProgressBar, DTPicker, MonthView, Slider, and UpDown. The Microsoft-provided OCXs for others will work but the x64 version of MSComCtl.ocx doesn't come with Windows and isn't legally redistributable-- but if you have Office 64bit, it works in tB).
• Form.DpiScaleX/Y properties
• Per-procedure [ IntegerOverflowChecks(False) ], [ FloatingPointErrorChecks(False) ] and [ ArrayBoundsChecks(False) ] attributes to disable those checks on performance-critical routines while leaving them generally in place.
• Constant function folding: You can specify a [ ConstantFoldable ] attribute for functions where when called with non-variable input, will be computed at compile time, rather than runtime. For example, a function to converted string literals to ANSI. The result would never change, so the resulting ANSI string is stored, rather than recomputing every run.
• Removal of limits on line continuations, procedure size, etc.
• Handles and Implements procedure syntax so you can use different names if you wish, for instance instead of Form_Load you can have Sub AppStart() Handles Form.Load
• IsNot operator
• CurrentComponentName CurrentProcedureName CurrentProjectName CurrentSourceFile and CurrentComponentCLSID variables; easily make boilerplate code like error handlers.
• Compiler warnings for common bad practices or likely oversights, with ability to set them to ignore or turn them into an error both project-wide and per-procedure with [ IgnoreWarnings(TB___)], [ EnforceWarnings(TB____) ], and [ EnforceErrors(TB____) ] attributes
• Customize COM initialization call used by hidden entry point (CoInitialize STA, CoInitializeEx MTA, OleInitialize STA)
• Built-in ability to make a console project rather than a GUI project with default Console class for reading/writing console IO and provided debug console.
• Form .MinWidth, .MinHeight, .MaxWidth, and .MaxHeight properties
• Control anchors-- control x/y/cx/cy can made relative, so they're automatically moved/resized with the Form.'
• Form.Opacity property for alpha blending
• Form.TopMost property
• TextBox.NumbersOnly
• PictureDpiScaling property for Forms/UCs/PB
• CodeLens allows running Subs in modules with no arguments right from the editor without starting the full program
• Internal functions like MsgBox now support Unicode
• IDE features long desired that VB6 lacks: Code folding (with ability to define Regions that can also be folded), sticky scroll, multiple modules/classes per file, Unicode support in editor/properties, info on hover, advanced info option for hover shows Len/LenB/alignment for UDTs and offsets for UDTs and interface methods, and the full inheritance chain for interfaces. Also History panel, parenthesis/bracket color matching, minimap, and Variables panel that dumps the values of ones in use by that procedure on break, controls with Visible=False are faded, Outline panel with control over what's outlined. Type library viewer shows the entire source in tB language syntax.
• Online package server for code packages that can contain any type of tB code-- modules, classes, etc. (They can be used offline too. Note: Ability to publish not yet added to IDE but still available via old VSCode plugin).
• Inline initialization of variables (e.g. Dim x As Long = 1)
• [ Unimplemented ] attribute for methods allows showing a compiler warning about it being unimplemented wherever it's called (you can upgrade it to error too).
• Can have module-level declares in between Subs/Functions instead of needing to all be above them (while often bad coding practice this is good for e.g. very simple 1-line macros directly related to declares).
• [ SetDllDirectory (True/False) ] attribute to allow an explicitly loaded DLL to load it's own dependencies from it's load path. Also has the effect of allowing searching the app path for the DLLs in the base app's declare statements (used per-declare).
• Support for block and inline comments with /* */ syntax, e.g. Sub Foo(bar As Long /* out */)
• [ TypeHint() ] attribute allows populating Intellisense with an enum for types other than Long.

And I guarantee I'm missing some (still-- I've been updating this post as I remember or am reminded about others). There's a whole bunch more planned, including unsigned types, aliases defined in language, inheritance, etc.

So there's *already* a lot of compelling reasons to use tB over VB6.

can oleexp.tlb make new IUnknown object?
and add some vtable

Code:

---

.VTable(3) = GetAddress(AddressOf invoke)
.VTable(4) = GetAddress(AddressOf ExecuteScriptCompleted)

---

Code:

---

Public Function InitializeDemonBlog(LE As DemonBlog) As IUnknown 'IDemonBlog
    If m_pVTable = 0 Then
        With m_VTable
            .VTable(0) = GetAddress(AddressOf QueryInterface)
            .VTable(1) = GetAddress(AddressOf AddRef)
            .VTable(2) = GetAddress(AddressOf Release)
            .VTable(3) = GetAddress(AddressOf ExecuteScriptCompleted)

            m_pVTable = VarPtr(.VTable(0))
        End With
    End If
   
    With LE
        .pVTable = m_pVTable
        CopyMemory InitializeDemonBlog, VarPtr(.pVTable), 4
    End With
End Function

---

Implements WebView2.IUnknown
webview.tlb , WebView2.idl WebView2Loader.dll
from https://globalcdn.nuget.org/packages....1774.30.nupkg (rename as zip file)

maybe can't use vb6 class file for IUnknown

No idea what you're doing or how it relates to oleexp.

There is a problem with oleexp related to HRESULTs in callbacks, I'll get that fixed, and add active scripting, this week.

i make More new class by IUnknown with vtable.
if only one class,it's easy
if have 10 class,

Virtual table simulation class, create IUnknown object for WEBVIEW2 callback event

Different functions execute callbacks on different source objects.
Now I want to make the virtual VTABLE and IUnknown objects into simpler codes. A module can support dozens or hundreds of different class objects. It can also deal with the release. If the same callback comes from different objects, the THIS pointer should be different, but there will be no problem with the virtual pointer. I will test these.

I most want to turn the CLASS1 file of VB6 into an IUnknown object, but he has more than 5 and 8 interfaces by default, while IUnknown only has 3 interfaces, so this way is doomed to fail

i want to find easy way to create More IUnknown object for vc++ dll call back

[VB6] Creating/Using COM Interfaces without TLBs-VBForums
https://www.vbforums.com/showthread....s-without-TLBs

Project Update - Version 6.3

This version adds Active Scripting interfaces, Package Manager interfaces, completes Core Audio interfaces, and adds additional WebView2 interfaces to catch it up to the latest version. Also on the WebView2 front, removed use of HRESULT in interfaces used with Implements, which should take care of the errors with those. Also added UI Ribbon interfaces, completing a source file that had been hanging around the source folder unfinished for years, and some others.

Full changelog:

(oleexp 6.3 - Released 09 June 2023)

• Added active scripting interfaces (ActivScp.h)
  
• Completed Core Audio interfaces
  
• Added Package Manager interfaces from msopc.idl/coclass OpcFactory
  
• Added DirectComposition Presentation Manager interfaces.
  
• Added some missing base OLE/COM interfaces: IDataAdviseHolder, IOleAdviseHolder, IDropSourceNotify, IEnterpriseDropTarget, IContinue, IQuickActivate, IAdviseSinkEx, IPointerInactive, IOleUndoManager, IEnumOleUndoUnits, IOleParentUndoUnit, IOleUndoUnit, IViewObjectEx, IOleInPlaceSiteWindowless, IOleInPlaceSiteEx, IOleInPlaceObjectWindowless.
  
• ribbon.odl, UI Ribbon interfaces, had been sitting around in the source folder unfinished forever; it's now complete and added (source file renamed exp_ribbon.odl).
  
• Added IContextCallback interface with coclass ContextSwitcher.
  
• Added Disk Quota interfaces IDiskQuotaControl (with coclass DiskQuotaControl), IDiskQuotaUser, IDiskQuotaUserBatch, IEnumDiskQuotaUsers, and IDiskQuotaEvents.
  
• Added missing Direct2D DrawText option flag to enable color fonts (e.g. colored emojis).
  
• Updated WebView2 interfaces to version 1.0.1774.30
  
• (oleexpimp) Added IAdviseSink and IAdviseSinkEx.
  
• (Bug fix) VB6 did not play nice with Implements where one argument was an HRESULT.
  
• (Bug fix) D3D11CreateDevice pFeatureLevels now As Any to allow passing ByVal 0.
  
• (Bug fix) DirectComposition vtable ordering to correct undocumented vtable reversal.

All of these updates have already been added to tbShellLib.

Very good work.
Do you have an example with active scripting interfaces?
It can be used to control the program and objects.

Some look very interesting I'll try them.

All the best

No example in VB yet but this C++ example would be fairly simple to convert.

what about ebmode vba6.dll?
CopyMemory ByVal VarPtr(LinkProc(4)) + 3, GetProcAddress(GetModuleHandle("vba6.dll"), "EbMode"), 4&

Which other TLB implements this interface?

That's not an interface and you don't need a typelib for it, you need a declare statement, for all uses besides multithreading.

Private Declare Function EbMode Lib "vba6" () As Long

in vb, not a TLB.

...if you did want to add it to a tlb,

Code:

---

[dllname("vba6.dll")]
module msvbvm60
{
    [entry("EbMode")]
    long EbMode(void);
}

---

Code:

---

Dim oITypeInfo As oleexp.ITypeInfo
 Dim oITypeInfo2 As oleexp.ITypeInfo2
  Dim oIDispatch As oleexp.IDispatch
  Set oIDispatch = Object1  ' get the IDispatch interface
  Set oITypeInfo = oIDispatch.GetTypeInfo(0, 2052)

set oITypeInfo2 =oITypeInfo

---

error,why?

how to get COM OBJECT function or method address by oleexp.tlb?

Code:

---

MethodName=“Navigate”
 Dim IID_NULL As oleexp.UUID, DispIDA As Long
 Dim VtableAddress1 As Long, Ptr As Long
 oIDispatch.GetIDsOfNames IID_NULL, MethodName, 1, 0, DispIDA

VtableAddress1 = oITypeInfo.AddressOfMember(DispArr(0), INVOKE_FUNC)

---

BUTVtableAddress1 NOT VTABLE OF method,how to do?
\
get COM OBJECT Navigate address of WebBrowser1.Navigate

Dim fun As FUNCDESC
dim p as long
p=oITypeInfo.GetFuncDesc(i)

how to set fun=p?

The number of members cannot be obtained for VB6 class objects compiled into EXE.

Other third-party OCX controls can be obtained by adding .OBJECT

Code:

---

Msgbox GetMethodCount(Class1A) '0
Msgbox GetMethodCount(WebBrowser1) '0
Msgbox GetMethodCount(Web) '19
Msgbox GetMethodCount(WebBrowser1.Object) '19
Msgbox GetMethodCount(WebBrowser1.Document) '379

Msgbox "DataGrid1 METHOD=" & GetMethodCount(DataGrid1) '0
Msgbox "DataGrid1.Object METHOD=" & GetMethodCount(DataGrid1.Object)  '111

---

Code:

---

Function GetMethodCount(Obj1 As Object) As Long
 Dim oITypeInfo As olelib.ITypeInfo, vAttrs As TYPEATTR, vTable As Long
 Dim oIDispatch As olelib.IDispatch, pAddress As Long, Fptr As Long
    Set oIDispatch = Obj1  ' get the IDispatch interface
 
  Set oITypeInfo = oIDispatch.GetTypeInfo(0, 0)

  'Msgbox oITypeInfo.GetFuncDesc(0)
  Dim fundisp As Long
  On Error GoTo err1
  'CallCOMInterface& ObjPtr(oITypeInfo), 6, 0&, VarPtr(fundisp)
  fundisp = oITypeInfo.GetFuncDesc(0)
 
 If fundisp <> 0 Then
  pAddress = oITypeInfo.GetTypeAttr
  CopyMemory vAttrs, ByVal pAddress, Len(vAttrs)  ' copy that structure
  oITypeInfo.ReleaseTypeAttr pAddress
  GetMethodCount = vAttrs.cFuncs
  End If
  Exit Function
err1:
End Function

---

fafalone:
Want to use your old code ref'd in Core Audio - Change the system default audio device' 841167-VB6-Vista-Core-Audio-Change from

The page references oleexp.tlb v4.11 (or higher), using the .bas addons mIID, mCoreAudio and mPKEY. Is the old project compatible with your newest release (v6.3)? Or can we get something closer to 4.11 if that's necessary?

We have users from Win7 to Win11. Are there any known issues with those OS's? (We compile on a VB6 IDE)

[You mention also communicating via DM or email, but I don't see how to get an address for the latter. I could point you to a contact-us link on one of my sites if that'd be helpful.]

Thank you!

The Core Audio interfaces haven't changed since originally being added, besides a couple bugfixes and adding additional interfaces missing from earlier versions, so yes you can (and should) use the newest version. It still contains those addons in the download zip.

I haven't tested that particular code on Windows 11 -- as the page mentioned, it's undocumented, and has already been broken by MS once (you need a different version for Windows Vista), so there's no guarantees of working going forward. But some quick searches suggest the Windows 7+ version is still working on Windows 11.

Email is my username at gmail, but honestly I check VBF more often.

Downloaded oleexp63.zip and the core audio project.
Having trouble pointing Project/References OLEEXP to the location where the type library is stored.

The OLEEXP shows as missing, we select browse, open the location for oleexp.tlb, but then the panel showing location still points to D:\tl_ole\eexp.tlb.
Even putting the file there doesn't change the MISSING indication. What am I doing wrong?
Before selecting:
Attachment 188192
During:
Attachment 188193
After (still shows default D:\tl_ole):
Attachment 188191

try unchecking then click ok, then reopen and retick then click ok.

What k_zeon posted should fix it; by the looks of it, the project is referencing a version before GUID accidentally got switched, so selecting the new one doesn't satisfy it. Your list like already contains "OLEEXP - Modern Shell Interfaces for VB6, v6.3", but following the steps above will ensure it adds the newer one.

Still no luck. Unchecked, ok, reopen, retick, then browse to location, ok, still shows Location on main panel as this project's directory, not where I want to place them.
Unchecked:Attachment 188196
Checked - default location shows project directory:Attachment 188197
Browse, select dir: Attachment 188198
OK, then location is still wrong:Attachment 188199

Worse, when I put the library in the project directory, the compile crashes with "VB has stopped working" But I hope that's bec the library isn't referenced yet.
Thx for helping.

All those attachments are broken.

1) Uncheck

2) Click browse

3) Navigate to the one you want to use and select it

4) Look carefully at the list now: Do you have *two* items:

"OLEEXP - olelib with Modern Interfaces,,"

and

"OLEEXP - Modern Shell Interfaces for VB6, v6.3" (or another 5.x or 6.x version?)

5) If so, select the second one, "OLEEXP - Modern Shell Interfaces for VB6, v6.3"

6) Save project

This is awesome! However the TLB is missing a few important things in the kernel32 module. While it has VirtualAlloc, it's missing VirtualFree. So if you just use VirtualAlloc, you'll find yourself in a situation where you can't release the memory you allocated.

It is missing a lot of useful API declarations but you can always declare them yourself when needed... Manual declarations are arguably better since you can play around with the types of parameters.

Well you can use memory allocated with the TLB's VirtualAlloc with a locally defined VirtualFree (Declare Function ...)

Almost all the APIs in there are just what's in the original olelib this project was forked from; I have never intended for this project to become a comprehensive source of APIs. Not in the least because it's a metric crapton of work to rewrite everything VB-friendly and you can already do it in VB unlike interfaces/coclasses. But since a lot of people did apparently want that, I've done it with oleexp's successor, tbShellLib-- the 64bit compatible version for twinBASIC, which contains 100% coverage of oleexp. oleexp is now in end-of-life maintenance mode; I'm keeping the interfaces in sync with tbShellLib and doing bugfixes, but won't be adding the APIs. I've taken great care to not only manually double-check all the types for x64 compatibility, but also to provide enums wherever there's a limited set of values even where an enum isn't provided in C++, and to provide multiple versions for String/LongPtr and for the most common ones, ANSI String. It's currently up to the top 1500 or so most common APIs from the default Windows headers (I'm not including most specialized libraries; it would not only take years but grind intellisense and syntax adjusting/highlighting to a halt, main exception is GDI+) and also includes things like all the WM_ messages, all the WS_ and WS_EX_ styles, common errors, etc.

In the future, twinBASIC will support exporting TLBs. When that happens, oleexp will be replaced with a 32bit tbShellLib.tlb for VB6/VBA 32bit, and a 64bit tbShellLib.tlb for VBA 64bit.

*If somebody wrote a tool to convert VB API declares to MKTYPLIB-compatible IDL syntax, I'd put the APIs in oleexp. The tool would need to handle tB's DeclareWide, LongPtr, and LongLong. This would still leave some manual work to be done, e.g. since tB supports passing a null pointer instead of a UDT, many optional UDTs have been replaced with their true type rather than As Any, which is the only way VB6 can pass both a UDT and null pointer (ByVal 0), but it would be realistic.

Quote:

---

Originally Posted by murspieg1

Still no luck.

---

You can try manually register it with RegTLib

Quote:

---

Originally Posted by fafalone

Well you can use memory allocated with the TLB's VirtualAlloc with a locally defined VirtualFree (Declare Function ...)

Almost all the APIs in there are just what's in the original olelib this project was forked from; I have never intended for this project to become a comprehensive source of APIs. Not in the least because it's a metric crapton of work to rewrite everything VB-friendly and you can already do it in VB unlike interfaces/coclasses. But since a lot of people did apparently want that, I've done it with oleexp's successor, tbShellLib-- the 64bit compatible version for twinBASIC, which contains 100% coverage of oleexp. oleexp is now in end-of-life maintenance mode; I'm keeping the interfaces in sync with tbShellLib and doing bugfixes, but won't be adding the APIs. I've taken great care to not only manually double-check all the types for x64 compatibility, but also to provide enums wherever there's a limited set of values even where an enum isn't provided in C++, and to provide multiple versions for String/LongPtr and for the most common ones, ANSI String. It's currently up to the top 1500 or so most common APIs from the default Windows headers (I'm not including most specialized libraries; it would not only take years but grind intellisense and syntax adjusting/highlighting to a halt, main exception is GDI+) and also includes things like all the WM_ messages, all the WS_ and WS_EX_ styles, common errors, etc.

In the future, twinBASIC will support exporting TLBs. When that happens, oleexp will be replaced with a 32bit tbShellLib.tlb for VB6/VBA 32bit, and a 64bit tbShellLib.tlb for VBA 64bit.

*If somebody wrote a tool to convert VB API declares to MKTYPLIB-compatible IDL syntax, I'd put the APIs in oleexp. The tool would need to handle tB's DeclareWide, LongPtr, and LongLong. This would still leave some manual work to be done, e.g. since tB supports passing a null pointer instead of a UDT, many optional UDTs have been replaced with their true type rather than As Any, which is the only way VB6 can pass both a UDT and null pointer (ByVal 0), but it would be realistic.

---

Still, there are some obviously missed very useful functions. The VirtualFree one is a good example. Each memory allocation function should have a matched memory free function.

I'll add it to the next release. any others you'd like added? Within reason, not doing more than 50. Unless you want to write the IDL declares 😉

Quote:

---

Originally Posted by fafalone

*If somebody wrote a tool to convert VB API declares to MKTYPLIB-compatible IDL syntax, I'd put the APIs in oleexp. The tool would need to handle tB's DeclareWide, LongPtr, and LongLong. This would still leave some manual work to be done, e.g. since tB supports passing a null pointer instead of a UDT, many optional UDTs have been replaced with their true type rather than As Any, which is the only way VB6 can pass both a UDT and null pointer (ByVal 0), but it would be realistic.

---

A long time ago a came across a book from MS Press Hardcore visual basic 2nd Edition, on the CD which was in the book they had A Type Library which had almost all API's Declared in it. the declaration were very well organized. additional it had quite a few interfaces. it could be compile in Unicode or ANSI.

I have been using it in all my projects, which saved me from typing all the API Declarations in my projects. although as windows evolved, I had to add many declarations myself, and in the many years it has evolved to include many more Declarations.

while I would not suggest that my TLB is perfect, (I only maintained Unicode, since the beginning of time I was an ANSI Denier). the source (in IDL) could help you if you are interested.