Printable View
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.
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.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.
Hi fafalone. I like to use the PROPVARIANT struct in my projects, for example, in IMFAttributes::GetItemByIndex.
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.Code:HRESULT GetItemByIndex(
[in] UINT32 unIndex,
[out] GUID *pguidKey,
[in, out] PROPVARIANT *pValue
);
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
With oleexp.PROPVARIANT, a returned GUID looks like this: {00000000-54D6-4487-A2A4-EC7C0D1BD163}Code:Dim PropertyGuid As UUID
Dim PropertyVar As oleexp.PROPVARIANT 'Variant
Call MFActivate.GetItemByIndex(PropertyItem, PropertyGuid, PropertyVar)
Debug.Print GUIDToString(PropertyGuid)
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".
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:Quote:
Originally Posted by VanGoghGaming
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:
Then tB would know you want to export this API in the TypeLib. Just thinking out loud.Code:Declare PtrSafe Export Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
I've just encountered another case that makes a perfect example of such API functions with UDT parameters. Many WinRT methods use a DateTime structure which is defined as Int64. At first I thought that is compatible with VB6's Date type but that quickly turned up not to be the case so I had to use Currency instead. That needs to go through a bunch of conversions to make a usable Date out of it:
Declaring everything As Any is very handy here. :bigyello:Code:Private Declare PtrSafe Function FileTimeToSystemTime Lib "kernel32" (lpFileTime As Any, lpSystemTime As Any) As BOOL
Private Declare PtrSafe Function SystemTimeToTzSpecificLocalTimeEx Lib "kernel32" (lpTimeZoneInformation As Any, lpUniversalTime As Any, lpLocalTime As Any) As BOOL
Private Declare PtrSafe Function SystemTimeToVariantTime Lib "oleaut32" Alias "#184" (lpUniversalTime As Any, pvVariantTime As Any) As BOOL
Private Function ToDate(cDate As Currency) As Date
Dim SysTime As SYSTEMTIME
If FileTimeToSystemTime(cDate, SysTime) Then If SystemTimeToTzSpecificLocalTimeEx(ByVal vbNullPtr, SysTime, SysTime) Then SystemTimeToVariantTime SysTime, ToDate
End Function
P.S. I've written another lengthy reply on the previous page (at the bottom)!
Thanks. Works perfectly. :)Quote:
Originally Posted by fafalone
> 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.
Btw, in TB if you have Private Declare Function MyDeclare (MyParam As UDT1) As Long you can pass VarPtr(MyUDT2) instead i.e. a LongPtr to an instance of *other* UDT2 (as a consequence of the only pointer in the language LongPtr being typeless void *).
cheers,
</wqw>
Unless you're suggesting I lack experience with the Win32 api, I think I know exactly how often it comes up. I can name thousands of standard cases for every exception you point out, which is the point. I've redone close to 3000 interfaces and 9000 APIs myself from the SDK by hand for WDL, trust me when I say that no, it is absolutely not always true you can infer the type from the name. Thousands of pointers are just pSomething with no hint. Your own example; there's nothing to suggest to anyone who doesn't already know those are UDTs for FILETIME and SYSTEMTIME vs the other things plausible.Quote:
Originally Posted by VanGoghGaming
I tabbed over to an open project, 3 APIs in, ByRef NewState As ...? I'll give you $100 if you tell me how you know the UDT without guessing or me telling you the API and you've already memorized it. It's pure guesswork that it even is a udt instead of Long, Enum, etc.
I'm sure both of us could sit here and rattle off exceptions all day, but they remain exceptions. There's still 100+ times you want the real type/struct for every one you don't.
Btw you're doing a great job building up a WinRT tlb. Not a fan of using it where there's alternatives but increasingly there's not-- would love to see you expand it for general purpose use. Tip: Preserve LongPtr equivalents with typedef [public] long LongPtr; that way it's easy for both your typelib and code using it to be updated to native tB for x64 support.
If you want it, I have a function that strips the offset and size of comments from tB's typelib to native syntax view to make copying out of a tlb easier.
If the UDTs are equivalent, no VarPtr needed.Quote:
Originally Posted by wqweto
tB is smart enough to allow that.Code:Type fizz
a As Long
b As Long
c As Integer
End Type
Type buzz
d As Long
e As Long
f As Integer
End Type
Sub fizz(b As buzz)
End Sub
Sub test()
Dim f As fizz
fizz f
End Sub
> tB is smart enough to allow that.
Btw, VB6 allows this with same UDTs from different typelibs (sometimes) which probably is a bug in the compiler: https://github.com/twinbasic/twinbasic/issues/1219
cheers,
</wqw>
Seems like the same guid is key there? or does it work when they're not associated with a guid?
If it's only when same GUID, I'd say design over bug... that's supposed to uniquely identify a type, moreso than a name.
Hello Fafalone!
I've been using your oleexp.tlb and thank you for your dedication to the excellent work.
Excuse me:
1. Can WinDevLib.tlb be used in VB6?
2. Does oleexp.tlb contain the definition of 8500 APIs?
If WinDevLib.tlb is not available in VB6, it is recommended to add 8500 APIs to oleexp.tlb for easy use in VB6.
After all, twinBASIC has not yet been officially released and cannot be used as a development tool for actual production projects. My current development relies heavily on VB6.
Thank you very much!
1) It's not a type library it's a twinBASIC Package, so, no :)
In addition to the APIs and COM interfaces it has all the addin packages built in plus hundreds more inlined functions, macros, and small API-related helpers.
2) No, they mostly have the same COM interfaces (maybe a dozen or so aren't in oleexp, but they're obscure), but for a long time I preferred doing my own APIs per project, so never added them to oleexp. There's only about 1000 and a good fraction of those are obsolete olelib stuff for Win9x or W/A variants I exclude from the WDL count (with them it's over 12,000), and an even smaller fraction of related UDT coverage.
As mentioned I was considering whether I could apply some automation to the JSON representation tB generates to covert it back to ODL for oleexp, but that's missing some important info that would make it a much more involved project than I care to take on (specifically, is interface? has ANSI<->Unicode disabled? PreserveSig disabled?)... lots of things I want to do, little time. Plus there's now hundreds of overloads I'd have to fix manually since VB6 has no support for it.
tB isn't quite production ready yet but it's getting closer all the time (and there is some commercial production use; publicly XYPlorer now has frequent twinBASIC builds, for example)... in the mean time I'd advise writing all new code with 64bit in mind (LongPtr where applicable, oleexp defines it), and if you plan to use WDL in the future, pull your API defs from there. You'll need to make some minor adjustments sometimes, but it's largely compatible.
It's a tB ActiveX DLL, I can't put any "typedef" in it, but it can be compiled as both 32-bit and 64-bit. I just reference it "as is" in VB6 when I need to use it but vbForums doesn't allow DLLs in attachments so I had to extract the tlb resource from it when I posted these WinRT sample projects. I guess for tB it could be made into a package instead of an ActiveX DLL.Quote:
Originally Posted by fafalone
Oh thought you were going the other way.Quote:
Originally Posted by VanGoghGaming
#If Win64 = 0 Then
Public Enum LongPtr: [_]: End Enum
#End If
should preserve it when you build a tlb for vb6.
I'm hoping tB gets Alias support soon... only that, dispinterface, and a couple other little things would bring it to feature parity with what it supports via TLB and completely eliminate the need for them.
This is the only way I know how to make a tlb. Everything is already declared as LongPtr, tB automatically changes it to Long for 32-bit and LongLong for 64-bit at compile time.
Right but it shouldn't if you use that enum instead, the local definition supersedes the outside type.
If you can figure out that WinRT stuff it would take you 10min to figure out a tlb via mktyplib/midl though.
I am not using the ActiveX DLL outside VB6. It is not referenced in tB. If I need something from it in tB, I can just include the corresponding "twin" file with interface definitions. That's why I said it could be made into a package. Maybe I could publish one if you want to take a look at it.
You are probably right, it shouldn't take long to figure out mktyplib/midl but I'm still reluctant to start from scratch and I'm definitely not a fan of IDL syntax which is prone to so many errors. It is a lot more convenient to write interface definitions in the tB IDE (with all its quirks) using familiar VB-friendly syntax. tB will tell you in real time if you made a typing mistake or what interfaces still need to be declared. When there are no more errors in the immediate panel then you can be sure everything is ready to be compiled for testing.
WinRT stuff is definitely not hard to figure out once you overcome an initial learning curve that is inevitable when you are not familiar with .NET concepts. For example, each async method returns an IAsyncOperation of the desired type and in turn that invokes its corresponding IAsyncOperationCompletedHandler that can be implemented in VB/tB.
Also, Arrays are called Vectors, each Vector has a corresponding VectorView interface that is read-only and implements a pair of IIterable/IIterator interfaces that are used for enumerating the Vector (this is the "For Each..." syntax in .NET). All these interfaces have the same methods, just the parameter type is different and therefore they have a different GUID for each parameter type (Vector of strings, integers, booleans, objects, etc).
Exactly the same thing applies for a collection (which is called Map) where each element is a KVP (KeyValuePair) with the key always of type string and the value of whatever type you want to have in the collection.
Once you have figured this out, it all becomes just a tedious grind of copy-pasting interfaces and looking up GUIDs...
You have this:
Shouldn't it rather beCode:Function GetClassNameW(hwnd As Long, lpClassName As String, nMaxCount As Long) As Long
Member of oleexp.user32
?Code:Public Declare Function GetClassNameW Lib "user32" _
(ByVal hwnd As Long, ByVal lpClassName As Long, ByVal nMaxCount As Long) As Long
Object Browser in IDE does *not* show ByVal/ByRef param type on methods from typelibs and normal projects too.
Btw, you can use vbNullString to pass NULL to an As String parameter.
cheers,
</wqw>
And to further clarify, VB supports Unicode Strings in typelibs.
I mean Long vs. String. I thought that W requires a String pointer. I am asking because in my projects I have a lot of multiple declares, and I am just trying to consolidate them.
Hi Jon,
it starts to confuse me: this thread slightly tends to be more and more a tB thread. Although the work for oleexp is the base for both universes they are not the same. I am not using tB (besides some experiments) but extensively use olexep.tlb in my VB6 projects. So I have to sort out here which posts are refering VB6 and which tB. IMO theese should be devided into two separate threads.
Another example for this is your github rep. The source for oleexp is included there but not updated to the current version(s). So it makes no sense for me to collaborate on github.
Background: At the moment I am working on a DirectShow project. I decided to switch back to DS from MF because it is not supported in the same way as DS was. For more advanced tasks it is much easier to develop using DS - MF is a nightmare here. (I constantly watch the blog posts on alax.info). So I found several missing DS components in oleexp (e.g. IMediaSeeking, IMediaParamInfo, IMediaParams, DMO parts, ...) and expanded ext_dshow.odl myself to make my own TLB. Works now but it is cumbersome to update this include component in every new version of oleexp you publish.
If the oleexp source would reside on github I could participate instead of always doing my private work. But only if it was separate from tB. Sure I could post my modifications to ext_dshow.odl here in the thread but it would be more comfortable to make changes on github (commited by you). You called it an opensource project, so github would be the right way. Your opinion?
Not if the declare is in a typelib and typed right, and it's an input. If it's not in a typelib, such as Declare statements in .frm, .bas etc, then yes you need Long/StrPtr in VB6. tB you can use DeclareWide instead of Declare to disable ANSI conversion and use String for _WSTR/WCHAR* Unicode arguments.Quote:
Originally Posted by tmighty2
Apart from followups to specific comments I always say 'in tB' or similar. It's not exactly the same but it's in the sense of VB3 is still the same language; it's de facto VB7, albeit in a beta stage of the kind Microsoft doesn't do publicly. So there's just too much overlap to fully sequester the two, especially since WinDevLib is the official follow-up to oleexp, suggested to use in place of oleexp in tB, and oleexp is the base for its interfaces and I try to keep them reasonably compatible (also APIs, lots of work adding overloads for oleexp compat).Quote:
Originally Posted by SaschaT
I know some people don't use tB yet and some projects aren't compatible yet, but I'm not going to pretend it's like I'm here talking about Python, .NET, or some other off topic different language. oleexp.tlb adds LongPtr to VB6 and the code differences range from none to minor such that I consider tB code a perfectly serviceable response to questions... this is my hobby not my job.
The copy of oleexp in the WDL repo is purely for reference; you'll find no links to it anywhere and I haven't even mentioned it. Definitely not meant as the main source or for editing; it's not even complete, no addon bas files or compiled tlbs.
I've been keeping my VB6 projects to the VB6 CodeBank... but even with tB I'm still a bit of a luddite with git for my hobby projects... when someone submits a PR I just manually merge it into my local source by copy/paste from the diff, source has no automatic sync ability.
If you've expanded DirectShow I'd be excited to include it in the main source and credit you for it (I've recently started some expansion too); but are the changes so much more than exp_show.odl that you couldn't just attach it here? Then i'll make sure the new releases are in sync with the latest file posted here (and yes you don't care but they'll also appear in WDL first, signatures matched with your version).
If the changes involve a bunch of files yeah I guess github makes more sense; let me know if that's the case and I'll make a dedicated git repo so it's easier for you.
Ok, understood.
No, in summary there are not so much modifications and additions I did to the source. As for you VB6 is just a hobby and I spend most of my time with python. Unfrequently I stumble upon an interesting topic and launch VB6 because there is no faster way for me to develop some routines.
But I really forgot all the places where I added or altered the source, so I will have to do a text comparison to the orginals and extract them. Will post them here - probably along with a graph based DirectShow demo similar to this one: https://www.vbforums.com/showthread....=1#post5612190
(BTW: I can reveal that I change most lpwstr/bstr parameters I find to long . :bigyello: There a still many places.)
Long is king, he just doesn't want to admit it! ;)Quote:
Originally Posted by SaschaT
It's a compatibility issue. Probably 99% of lpwstr use is from the original olelib base... In a ton of commonly used stuff so I didn't want to just break large amounts of existing code .. still don't.. can merge additions as is, or if there's an lpwstr*, but can't just break everything...
BSTR is another matter though. That's the exact type of String VB6 uses, length prefix and all. So I don't see a good reason to change that.
This project was never updated to midl because midl prohibits redefinitions-- important for this. If you *always* want them as Long you should be able to simply redefine in typedef.odl
then the individual instances don't need to be modified and you can compile a custom version easily.Code:typedef long LPWSTR;
typedef long BSTR;
Well that's the reason I began to change it. Several projects didn't compile after I updated from oleexp V4.xx to 6.xx or so: Type mismatch. Had to modify all the places from String to StrPtr().Quote:
Originally Posted by fafalone
Retrieving a pointer only may be also a (small) performance advantage in some cases: depending on a function result I use the pointer (SysAllocString) or not.
Quote:
Originally Posted by fafalone
Good hint!
Btw, if you mark these typedefs [public] you'll get type hints in VBIDE the way you see OLE_COLOR and similar Long aliasing types.
cheers,
</wqw>
err delete
Function CreateCoreWebView2EnvironmentWithOptions(browserExecutableFolder As LongPtr, UserDataFolder As LongPtr, environmentOptions As ICoreWebView2EnvironmentOptions, environmentCreatedHandler As ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler) As Long
can't use browserExecutableFolder
can it use bstr (browserExecutableFolder as string)
or ?browserExecutableFolder as long?
webview sdk :109.0.1518.78 x86 fixed,i can't set by browserExecutableFolder
only can use by install ,and write to reg key:
[HKEY_CURRENT_USER\Software\Microsoft\EdgeUpdate\ClientState\{F3017226-FE2A-4295-8BDF-00C3A9A7E4C5}]
"EBWebView"="C:\\Users\\admin\\AppData\\Local\\Microsoft\\EdgeWebView\\Application\\109.0.1518.7 8"
"pv"="109.0.1518.78"
maybe need make 2 tlb:x86 oleexp.tlb,x64 oleexp.tlb?
Sub Navigate(URI As Long)
oleexp.ICoreWebView2 ???
can it use URI AS STRING?
Public Function DocumentTitle() As String
DocumentTitle = GetBstr(webA.DocumentTitle)
End Function
-Use StrPtr(str) where you see a ByVal Long and need to pass a String. If it's ByRef Long or function return, use a helper like LPWSTRtoStr found in most of my
-oleexp.tlb will always be x86 only. For x64, my package "Windows Development Library for twinBASIC" (WinDevLib) should be used instead. It covers 100% of oleexp.tlb plus far, far more, including more recent WebView2 updates.
I'm officially deprecating oleexp into maintenance mode.
MAINTENANCE MODE: oleexp will no longer receive feature updates, only bug fixes, as I've moved to twinBASIC, the backwards compatible true successor to VB6. There, oleexp is superseded by my Windows Development Library for twinBASIC (WinDevLib) project, which contains 100% of oleexp plus 10,000+ APIs and an increasingly large number of interfaces not available in this tlb, all with x64 support.
Thanks for the past and for the future!
Project Updated - Version 6.8
With the project going into maintenance mode, I'm releasing all previously completed work and pending bug fixes as a new version.
NOTE: The ridiculous attachment size constraints have once again caused the need to rearrange files: oleexp68-core.zip now only contains oleexp.tlb and mIID.bas. mPKEY and oleexpimp.tlb are now in oleexp68-addons.zip.
Changelog:
Code:(oleexp 6.8 - Released 06 November 2025)
- **BREAKING CHANGE** :: Shell functions taking pidl arrays were inconsistently defined. Some took
ByVal and some took ByRef (VarPtr(pidls(0)) vs just pidls(0)). For the sake of consistency,
correctness, and WDL API standards, SHCreateShellItemArray, SHCreateShellItemArrayFromIDLists, SHCreateDataObject,
SHCreateFileDataObject, and IDefaultFolderMenuInitialize::Initialize have now been changed to
use the more correct ByRef semantics. Where you passed VarPtr(pidls(0)) you'll need to change
that to just pidls(0).
-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.
-Added additional Media Foundation interfaces/APIs from wmcontainer.h (100%)
-Added DirectShow BDA
-(API Standards) Changed numerous byte array inputs typed as Byte to As Any to conform with standard.
-(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)
-(Bug fix) ISubItemCallback, IPropertyValue had incorrect methods.
-(Bug fix) ISecurityInformation::GetSecurity missing argument
Just wondering, was CoClass for ShellFolderShortCut added?
When I realized that was missing I did hint you about that for a time ago. (CLSID_FolderShortCut).
Yes it was added as FolderShortcut
Code:[uuid(0afaced1-e828-11d1-9187-b532f1e9575d)
]
coclass FolderShortcut {
[default] interface IShellLinkW;
interface IPersistFile;
};
Hi fafalone, I noticed that your project link, "List of New Interfaces In OLEEXP (as of v5.01)", lists many interfaces exposed from WIC. I'm specifically interested in the IWICFormatConverter class, so I downloaded the latest version you suggested (v6.8). However, after referencing the library in my IDE, I wasn't able to find the class. Have you removed some classes in this latest version, or am I missing something? Thanks!
It's there. VB6 has a bug where if an interface is the default for a coclass (an object you can create with New ...), only the coclass name is visible in the Object Browser and intellisense/autocomplete for Dim. But you can still declare a variable with it; Dim pFC As IWICFormatConverter and then you'll see the members come up in intellisense when you type pFC. etc.
Wow, you’re right. I’ve never seen anything like this before. Even though some of the classes are hidden, once they’re declared and referenced, all their methods become visible. A bit weird. Many thanks, fafalone!Quote:
Originally Posted by fafalone
Maybe it's time to get a.net TLB wrapper that wraps common functions.
oleexp.tlbDnetExp. TLB, it can even cross platforms. It also provides XML and JSON format type library interfaces
VanGoghGaming is doing that with WinRT, e.g. here..
Though I'm sure you'll be horrified that like oleexp.tlb the WinRT TLB is also several MB.