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

I don't understand. Why are you talking about me? I haven't left a message on this subject for a long time. I think the type Kuti currency file has two versions of 64 bit and 32 bit.

It would be even better if there was a way to extract parts of the TLB for different needs.
Because a 5mb TLB is not very convenient to carry after all.
Sometimes Excel, 64-bit and 32-bit, needs a small amount of functions.
The TLB needs to be registered successfully before it can be referenced in Excel.

Pecially the TLB files generated by the VB net DLL. Do not know whether it can be used without importing the registry?

Nobody has mentioned you here in months, there's still no 64bit oleexp (and there probably won't be), and it's silly complaining about a few mb when every else requires hundreds of MB if not GB of SDKs, frameworks, or libraries. It's an open source project if you want to just use some small part, the source is there.

It would be nice if twinbasic supported automatically extracting a function or module from a project.
For example, the Enterprise Control has a total of 30 files. If I only need a text box control for Unicode.Redundant modules and lines of code are automatically removed.
Is a function or a module that depends on which APIs declare DLLs or other functions.
If you need to compile some of the TLB types separately. It is not known which dependencies he used. Maybe ai can handle it automatically in the future.

Is the current chatGPT, it can not directly import hundreds of kb or even several megabytes of source code, and then it automatically clean up the redundant code.

This thread is about oleexp.tlb, not twinBASIC features.

I do use TwinBasic if I "have to", I am subscriber, but its editor (the one I currently use is from Dec 2024) is a real pain to use unfortunately. It behaves like the .NET editor. It is just slow and does nasty things.
I will fully switch to TwinBasic fully once I can work with it as fast as in VB6.

There were some IDE performance issues after the first releases in December that were fixed in recent builds; but other than that not sure what you mean... nasty things? Personally I love all the modern features the VB6 IDE lacks. I work a lot faster with things like regions, code folding, advanced info popup, global search that displays all results at a glance, all the issues detected before running you can jump to with a click, the IDE not throwing up a message box on every syntax error, etc. It's a little bit of an adjustment but well worth it.

If something you're working on is causing the IDE to be slow, please file a bug report.

Quote:

---

Originally Posted by tmighty2

... TwinBasic... editor is a real pain to use unfortunately. It behaves like the .NET editor. It is just slow and does nasty things.

---

Don't complain in general, raise specific issues on github here, https://github.com/twinbasic/twinbasic/issues. My experience is that many of our suggestions or bugs raised are being definitely being addressed. There is no chance your voice will be heard if you just moan that the IDE is a real pain. I've raised several so far, feel free to raise your own.

Why hasn't Wayne released the official version yet? It means that it is constantly adding new features to make it more compatible with VB6. It is like a child of all of us. If everyone could contribute to the cost, the development would be faster and Wayne would have enough money to recruit new employees.Without increasing the volume of the program as much as possible. Make up for some of the most important shortcomings of returning to B6. Become a more advanced and convenient programming language, which can be used in 51 or newer computer systems. Currently, his program is only 30 megabits. Maybe version 2, version 3, it will go up to 300 megabytes, two gigabytes.

It's a little off topic. But I hope you can know more people. In the past, the administrator of this forum liked to delete all the topics about special qualifications and transfer them to the corner where no one saw them at all.Now we should all think of it as a VB6 IDE. Upgrade version.

As someone said a few days ago, it is too difficult to add some new sections in this forum. Maybe this forum will go bankrupt in two years.With the rapid development of the Internet and AI, it is more and more difficult for traditional websites to make money, and it is only a matter of time before they are closed. It is possible that all the source code will be lost directly, and he will not copy it to us.

It is VERY off topic.

Quote:

---

Originally Posted by tmighty2

I noticed that even though I deleted a variable named "y" in code, it would still compile.
Then I noticed that "y" is declared as a constant in oleexp.
This was not intended, right?

Attachment 193716

---

Hi! I guess you have forgotten to remove "y" from oleexp.SIOI_Flags.
It's still present in oleexp66-core.zip.

Edit: Hmm, I guess I misunderstood something in the versioning as I just noticed that oleexpimp.tlb's last edit date was 2024-06-07 in the oleexp66-core.zip.
Edit2: Sorry, I completed confused the edit year 2024 with 2025.

Edit3: In your first post you state that people requiring an update due to a bug should not compile their own version but instead contact you. May I ask you if you could update oleexpimp.tlb?

I believe I am struggeling with a math problem where your "y" (which is 0) is being used, but I don't find the exact spot without having an updated oleexpimp.tlb.

It's in "\source\exp_security.odl"
SI_NO_TREE_APP,Y = 0x00000400,

Thank you very much.

Your edits are right .. 6.6 is from June 2024, no updates since. I'll post 6.7 this week... But the y in the typelib would only be used if you don't have y declared in your own code. In the screenshot you posted, should you maybe be using the uTop variable in the arguments instead of y?

If not, Dim y As Long: y = (correct value) will override the typelib in that method. Or Public y As Long in a .bas to override project-wide.

As it stands right now, an updated tlb without y but no code changes would change nothing without Option Explicit, or with it result in an undefined variable error. That's why I hadn't been considering it a high enough priority for an unplanned update. But still, there's a number of other pending additions and fixes so I'll still aim for this week.

webview2 ICoreWebView2 is nothing

why use LongPtr??
CreateCoreWebView2EnvironmentWithOptions(browserExecutableFolder As LongPtr, UserDataFolder As LongPtr, environmentOptions As ICoreWebView2EnvironmentOptions, environmentCreatedHandler As ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler) As Long



Implements oleexp.ICoreWebView2CreateCoreWebView2ControllerCompletedHandler
Private Sub ICoreWebView2CreateCoreWebView2ControllerCompletedHandler_Invoke(ByVal errorCode As Long, ByVal createdController As oleexp.ICoreWebView2Controller)



dim Web As oleexp.ICoreWebView2
Set Web = createdController.CoreWebView2
'it's error
If Web Is Nothing Then???



Private Sub ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler_Invoke(ByVal errorCode As Long, ByVal createdEnvironment As oleexp.ICoreWebView2Environment)

Set Ob_ControllerCompletedHandler = New WebViewLib

createdEnvironment.CreateCoreWebView2Controller ParentWindow, Ob_ControllerCompletedHandler
'it's ok
End Sub

maybe lost get_Bounds method?

Code:

---

  [propget]
    HRESULT _stdcall get_Bounds(
                    [out, retval] long boundsLeft,
                    [out, retval] long boundsTop,
                    [out, retval] long boundsRight,
                    [out, retval] long boundsBottom);
    [propput]
    HRESULT _stdcall put_Bounds(
                    [in] long boundsLeft,
                    [in] long boundsTop,
                    [in] long boundsRight,
                    [in] long boundsBottom);

---

Ah right I forgot.

There's a bug in MKTYPLIB. The property get is present in the source, but it's dropped when compiling. Some weird bug where you can't have a method with "get" in the name if it's a propget.

I actually fixed that and some other bugs but I wanted to finish some other things... I don't know when I'll officially release 6.7 but here's a patched version of 6.6 with the bug fixes I've done so far:

Code:

---

-Added CompressedFolder coclass that creates an instance of the Zip Folder extension; replaces CoCreateInstance of {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}.
-(Bug fix) MFCreateADTMediaSink should be MFCreateADTSMediaSink
-(Bug fix) IMFMediaType.GetMajorType, IQueueCommand methods used stdole.GUID instead of UUID, leading to automation type incompatible errors.
-(Bug fix) IPropertyBag2::Read/Write last args should be ByRef.
-(Bug fix) A bug in mktyplib silently dropped interfaces with [propget] commented out or starting with get_; this resulted in many WebView2
          interfaces being broken. Methods with ByVal POINT/RECT property lets have been renamed e.g.
          pgtPointerDeviceRect(ByRef RECT) (was retval)
          pptPointerDeviceRect([in] LONG pointerDeviceRectLeft, [in] LONG pointerDeviceRectTop, ...
          pgt is a Property Get, ppt Property Let.
-(Bug fix) SHCreateMemStream definition incorrect.
-(Bug fix) ITransferAdviseSink bugs
-(Bug fix) SI_NO_TREE_APPLY name typo

---

The naming restrictions were *insane*... I tried everything reasonable but now they're no longer Property Get/Let, they're separate

Code:

---

        HRESULT pgtBounds([out] RECT* bounds);
        HRESULT pptBounds([in] LONG boundsLeft, [in] LONG boundsTop, [in] LONG boundsRight, [in] LONG boundsBottom);

---

(attachment removed; fixes incorporated into v6.7, now released)

Maybe you need to write a tool to automatically detect if the number of interfaces is missing?Or even if the data type has been changed?

Quote:

---

Originally Posted by fafalone

Ah right I forgot.

There's a bug in MKTYPLIB. The property get is present in the source, but it's dropped when compiling. Some weird bug where you can't have a method with "get" in the name if it's a propget.

I actually fixed that and some other bugs but I wanted to finish some other things... I don't know when I'll officially release 6.7 but here's a patched version of 6.6 with the bug fixes I've done so far:


The naming restrictions were *insane*... I tried everything reasonable but now they're no longer Property Get/Let, they're separate

Code:

---

        HRESULT pgtBounds([out] RECT* bounds);
        HRESULT pptBounds([in] LONG boundsLeft, [in] LONG boundsTop, [in] LONG boundsRight, [in] LONG boundsBottom);

---

---

WebView2 Win32 C++ ICoreWebView2 | Microsoft Learn
https://learn.microsoft.com/en-us/mi..._documenttitle

The title for the current top-level document.

public HRESULT get_DocumentTitle(LPWSTR * title)

If the document has no explicit title or is otherwise empty, a default that may or may not match the URI of the document is used.

The caller must free the returned string with CoTaskMemFree. See API Conventions.

CAN RESULT IS A vb6 STRING?

your tlb return a long type "DocumentTitle"

Code:

---

HRESULT GetDocumentTitle(ICoreWebView2* webView, std::wstring& title) {
 
    if (!webView) {
        return E_INVALIDARG;
    }

 
    LPWSTR titlePtr = nullptr;
    HRESULT hr = webView->get_DocumentTitle(&titlePtr);

    if (SUCCEEDED(hr) && titlePtr) {
 
        title = titlePtr;

 
        CoTaskMemFree(titlePtr);
    }

    return hr;

---

Code:

---

Private Declare Function lstrcpyW Lib "kernel32" (ByRef Buffer As Any, ByVal Bstr_address As Long) As Long
Private Declare Function lstrlenW Lib "kernel32" (ByVal lpData As Long) As Long


Public Function StrFormPtr(lPtr As Long) As String
    Dim Buff() As Byte, Len1 As Long '????Byte??
    Len1 = lstrlenW(lPtr) * 2
    ReDim Buff(0 To Len1 - 1) As Byte '??????,??????Unicode?????2
    lstrcpyW Buff(0), lPtr    '?????Buff?
    StrFormPtr = Buff()
    'lstrcpyW VarPtr(Buff(0)), ByVal lPtr  '?????Buff?
End Function

---

Code:

---

Private Declare Function lstrcpyW_Long Lib "kernel32" Alias "lstrcpyW" (ByVal lpString1 As Long, ByVal lpString2 As Long) As Long
Public Function StrFormPtr2(ByVal lPtr As Long) As String
    StrFormPtr2 = String(lstrlenW(lPtr), " ")
    lstrcpyW_Long StrPtr(StrFormPtr2), lPtr    '?????Buff?
End Function

---

i do clear string by lptr,why also can read string from this address?
maybe need fill memory with 0?

Code:

---

Private Declare Function SysReAllocString Lib "oleaut32.dll" (ByVal pBSTR As Long, Optional ByVal pszStrPtr As Long) As Long
Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByVal hMem As Long)
 Function LPWSTRtoStr(lPtr As LongPtr, Optional ByVal fFree As Boolean = True) As String
SysReAllocString VarPtr(LPWSTRtoStr), lPtr
If fFree Then
    Call CoTaskMemFree(lPtr)
End If
End Function

---

Which IDL or ODL files are dedicated to WEBVIEW2? Can it be made into an independent TLB?
What development environment does compiler need to install? vc++2017? Still VC++6.0, MIDL.EXE?

The function or interface is marked as restricted, or the function uses an automatic type that is not supported in Visual Basic
maybe error by "BOOL"??

ICoreWebView2_21.ExecuteScriptWithResult Js, me

Code:

---

Private Sub ICoreWebView2ExecuteScriptWithResultCompletedHandler_Invoke(ByVal errorCode As Long, ByVal result As oleexp.ICoreWebView2ExecuteScriptResult)

        ICoreWebView2ExecuteScriptResult (MEMbers:)
        Property Succeeded As BOOL
        Sub TryGetResultAsString(stringResult As LongPtr, Value As BOOL)

---

you can add new interface?

Code:

---

  interface      ICoreWebView2ExecuteScriptWithResultCompletedHandler_Long
        Private Sub ICoreWebView2ExecuteScriptWithResultCompletedHandler_Long_Invoke(ByVal errorCode As Long, ByVal ICoreWebView2ExecuteScriptResultA AS Long)

---

so i can call by vtable:call com by index:ICoreWebView2ExecuteScriptResultA

oleview.exe open your oleexp.tlb:
ICoreWebView2_21 IS FROM ICoreWebView2_20
ICoreWebView2_20 IS FROM ICoreWebView2_19

I DON'T KHNOW WHICH CLASS
There are 20 classes nested layer by layer, with inheritance relationships. I don't know which class, interface, or method has parameter types that are incompatible with VB6. I wonder if there are any tools that can enumerate and detect specific parameter types?


edit by idl or odl format:
muse use same uuid? or can use any uuid?

if we have 10 Handler objects?
something is 2 argmemuent count? something 3 args,4args?
we can only use 3 Handler ?

arg2Handler(byval a as long ,byval b as lon)
arg3Handler(byval a as long,byval b as long,byval c as long)
?
ICoreWebView2ExecuteScriptWithResultCompletedHandler

Code:

---

[
  odl,
  uuid(1BB5317B-8238-4C67-A7FF-BAF6558F289D)
]
interface ICoreWebView2ExecuteScriptWithResultCompletedHandler : IUnknown {
    HRESULT _stdcall Invoke(
                    [in] HRESULT errorCode,
                    [in] ICoreWebView2ExecuteScriptResult* result);
};

---

ICoreWebView2ExecuteScriptResult

Code:

---

[
  odl,
  uuid(0CE15963-3698-4DF7-9399-71ED6CDD8C9F)
]
interface ICoreWebView2ExecuteScriptResult : IUnknown {
    [propget]
    HRESULT _stdcall Succeeded([out, retval] BOOL* Value);
    [propget]
    HRESULT _stdcall ResultAsJson([out, retval] LongPtr* jsonResult);
    HRESULT _stdcall TryGetResultAsString(
                    [out] LongPtr* stringResult,
                    [out] BOOL* Value);
    [propget]
    HRESULT _stdcall Exception([out, retval] ICoreWebView2ScriptException** Exception);
};

---

Code:

---

ICoreWebView2ScriptException

[
  odl,
  uuid(0CE15963-3698-4DF7-9399-71ED6CDD8C9F)
]
interface ICoreWebView2ExecuteScriptResult : IUnknown {
    [propget]
    HRESULT _stdcall Succeeded([out, retval] BOOL* Value);
    [propget]
    HRESULT _stdcall ResultAsJson([out, retval] LongPtr* jsonResult);
    HRESULT _stdcall TryGetResultAsString(
                    [out] LongPtr* stringResult,
                    [out] BOOL* Value);
    [propget]
    HRESULT _stdcall Exception([out, retval] ICoreWebView2ScriptException** Exception);
};

---

Attachment 194303

Webview2.Navigate strptr("https://www.bing.com") webView->get_DocumentTitle(&titlePtr);
str=webView.sources
dim js as.string
webview.executescript(js,callback)

Can you convert these parameters and return values directly into ordinary string types on tlb,idl?
thanks

If it's not in an Implements scenario you'd actually have to call something with an incompatible type to get an error.

Search for LPWSTRtoStr for how to get a string from a Long.

I'm not recompiling the tlb with your preferred methods. All the WebView stuff is in exp_webview2.odl in the oleexp source. I don't see any problems with any interface you mentioned and I can't understand what you are saying. Maybe just post a project with a minimal reproduction of the problem.

CoTaskMemFree(lPtr)
I will sort out some questions and update them at that time.
In SQLite, query the data or read the value of each field. Since it is of type UTF8, it is fine to return the integer type directly.
It also needs to be converted manually with the API.
In webview2, many data types are directly bstr types, and the return integer type also needs to call the API to convert, and also needs to use the API to release.
This creates a memory leak and adds a lot of code.

Data Type Correspondence and Release Issues (from VC++ to VB6)

- Web source: In VC++, when obtaining the Web source, it may involve data types such as strings. In VB6, the corresponding data type is the String type. Generally, after obtaining the web page source code from the WebView in VB6, if it is no longer needed, there is no need to perform complex memory management manually as in VC++. The garbage collection mechanism of VB6 will clean up the memory occupied by unused strings and other objects at an appropriate time.
- The url in navigate(url) : In VC++, the url parameter of the navigate method is usually of the string type. In VB6, it also corresponds to the String type. After using the Navigate method of the WebView in VB6 to load a website URL, generally, there is no need to release the url string itself manually. VB6 will manage its memory automatically.

Sorry to bother with a question:

Since I am using oleexp.tlb, I am being offered "BOOL" when I type for example "Dim b as bo".
I found out that "BOOL" is declared in that .tlb.

I am used to hitting Tab right after the first 2 characters, so I end up with "Dim b as BOOL" which is not what I want.
I have to improve it each time.

Am I the only one having this problem and caring about it?
I guess I can remove it from the tlb, and it will hopefully not break anything.

But I would be really interested if there isn't any smarter / better solution.
And again: I wonder why I am the only one asking this question.

Thank you!

It's one of a handful of Windows API types that I think are worth preserving; so no chance I'm removing it from the official tlb or stop using it in my samples. With all the API I use, using BOOL is as common at least as Boolean, probably more so.

If you're going to remove it just change typedef [public] long BOOL; to typedef long BOOL; in typedef.odl. That way you don't have worry about changing dozens of files.

PROJECT UPDATED - Version 6.7

This includes several additional bug fixes and updates compared to the oleexp66-bugfix posted elsewhere in this thread.

Code:

---

(oleexp 6.7 - Released 14 April 2025)
-Added DirectStorage interfaces
-Update WebView2 to 1.0.3124.44
-Added interface IFileOperation2.
-Added IMenuPopup, IDeskBar
-Added CompressedFolder coclass that creates an instance of the Zip Folder extension; replaces CoCreateInstance of {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}.
-(Bug fix) MFCreateADTMediaSink should be MFCreateADTSMediaSink
-(Bug fix) IMFMediaType.GetMajorType, IQueueCommand methods used stdole.GUID instead of UUID, leading to automation type incompatible errors.
-(Bug fix) IPropertyBag2::Read/Write last args should be ByRef.
-(Bug fix) A bug in mktyplib silently dropped interfaces with [propget] commented out or starting with get_; this resulted in many WebView2
          interfaces being broken. Methods with ByVal POINT/RECT property lets have been renamed e.g.
          pgtPointerDeviceRect(ByRef RECT) (was retval)
          pptPointerDeviceRect([in] LONG pointerDeviceRectLeft, [in] LONG pointerDeviceRectTop, ...
          pgt is a Property Get, ppt Property Let.
-(Bug fix) SHCreateMemStream definition incorrect.
-(Bug fix) ITransferAdviseSink bugs
-(Bug fix) SI_NO_TREE_APPLY name typo
-(Bug fix) FORMATETC.cfFormat corrected from Long to Integer.
-(Bug fix) MKTYPLIB bug allows predeclared interfaces in inheritance chain but ignores their vtables. Interfaces ITrackShellMenu, IMFMediaSession,
          ID2D1RectangleGeometry, ICoreWebView2PrintSettings2, ICoreWebView2WebResourceRequestedEventArgs2, IDirect3DSurface9, and IDirect3DTexture9
          were broken due to this.
-(NEW ADDON) mMF.bas contains numerous GUIDs and PROPERTYKEY defs for use with Media Foundation interfaces.

---

Note that the new mMF.bas just includes (most of) the GUIDs and PROPERTYKEYs associated with Media Foundation. It does not include various inlined helper functions, macros, and constants available via WinDevLib in twinBASIC; i.e. it is not a straight port of wdMF.twin. oleexp.tlb is deprecated and while I'm doing bugfixes and keeping the interfaces available in both (mostly, a handful haven't been added to oleexp yet), the 8500+ API defs and other features of WDL will not be coming to oleexp, and I recommend moving on to twinBASIC.

Hi fafalone. I like to use the PROPVARIANT struct in my projects, for example, in IMFAttributes::GetItemByIndex.

Code:

---

HRESULT GetItemByIndex(
  [in]      UINT32      unIndex,
  [out]    GUID        *pguidKey,
  [in, out] PROPVARIANT *pValue
);

---

PROPVARIANT isn't quite right in oleexp. It's only 12 bytes in size there. It should be at least 16 bytes. Because the PROPVARIANT in the oleexp is incorrect, IMFAttributes::GetItemByIndex returns an incorrect GUID for pguidKey.

I can add another Long but a PropVariant can't hold a GUID; the only 16 byte type that has a union with the whole struct is DECIMAL which only works because it has 2 reserved bytes that get used for VT_DECIMAL; a GUID has none. If it's VT_CLSID it's (for 32bit purposes) a 4 byte pointer to a GUID and the existing type would be fine.

IMFPMediaItem, which calls IMFAttributes under the hood, returns such VT_CLSID propvariants... see here

If you mean the literal pguidkey parameter it's passed by pointer so I can't see how its size matters.

In any case I'll post a version with an additional Long later (I think that's the best way; a byte array would require CopyMemory for all cases where the Long can be used directly in the majority).

Quote:

---

Originally Posted by fafalone

If you mean the literal pguidkey parameter it's passed by pointer so I can't see how its size matters.

---

Code:

---

Dim PropertyGuid As UUID
Dim PropertyVar As oleexp.PROPVARIANT 'Variant
Call MFActivate.GetItemByIndex(PropertyItem, PropertyGuid, PropertyVar)
Debug.Print GUIDToString(PropertyGuid)

---

With oleexp.PROPVARIANT, a returned GUID looks like this: {00000000-54D6-4487-A2A4-EC7C0D1BD163}
With Variant the same GUID looks like this: {DE7046BA-54D6-4487-A2A4-EC7C0D1BD163} and this is correct (MF_DEVSOURCE_ATTRIBUTE_SOURCE_TYPE_VIDCAP_HW_SOURCE).

If I use my struct, the GUID is also correct.

Code:

---

Private Type PROPVARIANT
    vt As Integer
    wReserved1 As Integer
    wReserved2 As Integer
    wReserved3 As Integer
    Data1 As Long
    Data2 As Long
End Type

---

Weird... it must be stored contiguously in memory with the 4 bytes after getting zeroed somehow. Anyway, it will be a while before another release so here's an early test version of 6.7 with additional changes and fixes...

Code:

---

-Added basic Direct3D 10 coverage
-IWICImageEncoder methods now use proper ID2D1Image type.
-ID2D1DeviceContext::CreateBitmapFromDxgiSurface, IWICBitmapDecoder::GetFrame, IWICImagingFactory::CreateFormatConverter last param to retval to match The trick's typelib and WinDevLib.
-(Bug fix) OleCreatePropertyFrameIndirect incorrect alias.
-(Bug fix) WICImageParameters improperly substituted Long for D2D1_PIXEL_FORMAT (now used).
-(Bug fix) PROPVARIANT should have an additional 4 bytes for some data types (split as 2 Longs now instead of 1)

---

I am absolutely no pro at this, but shouldn't a function like GetWindowLong be declared with the real type arguments and not "As Any"?

I am asking because I am just having the problem of some APIs being declare in WinSubHook.tlb (by Paul Caton) and some in OleExp, and they differ.

Depends on the case but generally yes, though in some cases it is the explicit proper type (void*) or usage and language restrictions make it the best option (LPARAM, or cases where a UDT is optional-- an empty one isn't the same, and VB doesn't support Optional for them, so you need As Any to be able to pass ByVal 0&.. tB allows substituting a pointer for a UDT so WinDevLib uses the UDT. Or cases where you need to pass a buffer merely starting with the real type.

Sometimes people use it because of specifics usages where it's more convenient. But for libraries I only consider the first paragraph unless it's a compatibility issue with another library.

Anyway, GetWindowLong does use the proper types in oleexp:
Function GetWindowLong(hwnd As Long, nIndex As GWL_INDEX) As Long

Note that which API is called depends on the order of the libraries in references -- that's why there's up and down arrows. If WinSubHook is before oleexp in the list order, its GetWindowLong will be called unless you explicitly direct it otherwise by using oleexp.GetWindowLong()

Thank you and sorry for the confusion. You are right that it is declared explicitely. It also is in WinSubHook2.tlb.
I will correct me fully once I found out what exactely I was looking at.

I meant to be talking about

Sub CopyMemory(Dst As Any, Src As Any, Length As Long)
Member of oleexp.kernel32

Not about GetWindowLong...
Sorry for the confusion.

"As Any" is the preferred declaration for any parameter that is a pointer. This offers maximum flexibility if you know what you're doing.

In the case of CopyMemory you might be passing a numeric type either ByVal or ByRef, a UDT, object... the actual type is void* so As Any is the most correct: it's literally unchanged from the SDK types used in C/C++; a standard Windows type recognized by both mktyplib without typedef and VB6 unmodified, it's not like others where it's been substituted. Yes you could reduce everything to a pointer by using VarPtr, ObjPtr, etc, so you could declare it as ByVal Long, but that's both less convenient and "not the real type".

Quote:

---

Originally Posted by VanGoghGaming

"As Any" is the preferred declaration for any parameter that is a pointer. This offers maximum flexibility if you know what you're doing.

---

Only insane people would declare every pointer As Any... you notably do not in your own code, though you are almost as bad with changing most of them to LongPtr instead :wave:


ETA...

Maybe this should be standardized once and for all... tB can generate JSON describing everything, I could theoretically parse that back to MKTYPLIB-compatible signatures and bring WinDevLib to VB6 sooner rather than wait for tlb exporting... would have to resolve overloads but there's only a couple hundred.

(in twinBASIC, with my oleexp successor you can tick a box for a package and have everything remotely common from the Win32 API defined, no need to copy and paste, or define yourself, standard system APIs... and I don't mean like winu.tlb; WDL dwarfs it in coverage)

There are many, many examples where "As Any" or indeed "As LongPtr" is the preferred choice.

For example you have a function expecting a GUID but you only have a pointer to a GUID, this would save an additional call to "CopyMemory" to copy the pointer contents into a variable declared as GUID. Of course tB can work around this restriction but VB6 is still stuck in the stone age so if you want compatibility you don't have much choice. This is the main reason I still include my own API declarations instead of using a library like WinDevLib.

... and "tlb exporting" is unlikely to ever happen especially since you can do it manually with "Resource Hacker" from an ActiveX DLL like I've been doing with my WinRT examples. That also has limitations, for example ActiveX DLLs don't export API declarations but you can't have it all I guess...

But how often are you only going to have a pointer for a GUID? For most functions, almost never. The extra time spent looking up what type was actually needed for arguments where it's not clear would absolutely dwarf the time you spent writing an extra CopyMemory call for the 1 in 1000 circumstance where you need a pointer instead. And even if so, if you're talking about redoing *every* API for that reason? And for non-UDT pointers? Instead of just doing it for the one offs where you need it? Now you're talking about spending hours and hours to save seconds. The bigger issue in VB6 is coverage. I don't use winu.tlb (the largest API set for VB6; oleexp has less coverage of APIs (but far more interfaces); win32api.txt has more (still less than 1/5th WDL), but is so riddled with errors it would be a major project to make work as a bas) for instance because I still had to declare my own APIs (and everything associated with them like constants, types, enums.,..) so often it was frustrating. Why bother when you still have to break up your coding every few minutes to go get a missing API anyway? WDL is a whole different ballgame where you can code for weeks without running into something missing.

And Wayne has previously stated exporting typelibs is a planned feature. Not for v1.0, but at some point. You cannot "do it manually" for anything besides ActiveX component typelibs, which are quite different from general purpose things that are typically distributed as plain .tlb files instead of embedded in a dll or ocx. There's no way to get the APIs in WDL into a TLB file in bulk via ActiveX. It can't even compile as one anymore, but when it did, it dropped 100% of them for not being used.

It's a lot more often than you think or I wouldn't have brought it up. Obviously UDTs are the main offenders and not just GUID (that was just an example), there are tons of other UDTs suffering from this affliction. Not to mention that declaring them as pointers overcomes VB6's pesky ANSI conversion.

Then there's also the problem of rewriting UDTs in different ways (such as a GUID as 4 Longs so that they could be easily passed ByVal). A pointer doesn't care how you rewrite your UDTs as long as the size is a match.

There's absolutely no time spent looking up the type of arguments since that is always inferred from their names (rIID, lpSomeStruct, etc). I know CopyMemory doesn't take much time (both in writing the code and execution time) but I think it's a silly workaround and I just don't want to use it unless absolutely necessary.

I used to reference winu.tlb a lot in the past but I gave it up since it always comes short when you need something like you already mentioned. By now I got a lot of APIs already declared and it's rare that I stumble over a new one. Also many of them have WinRT object equivalents since I don't care about supporting anything below Windows 10.

I would have written my own TypeLib by now but I am reluctant to delve into the intricacies of MIDL and IDL language since I don't have your years of experience with that. Also I much prefer the VB-friendly syntax of tB over IDL syntax. So far I've seen that an ActiveX DLL can export interfaces, public types and public enums in its TypeLib. It'll have to do for now.

If you scroll a few pages back in this thread, we've already discussed tlb exporting in tB, and that was more than two years ago. Not even interfaces were supported at that time. It may be implemented some time in the future but the timeframe is just too long.

Maybe an easier workaround to implement would be adding another attribute to the Declare statement like this:

Code:

---

Declare PtrSafe Export Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

---

Then tB would know you want to export this API in the TypeLib. Just thinking out loud.