[VB6] Modern Shell Interface Type Library

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

I have it... no idea how to get it compile. Every version of midl I've tried has failed.

There's a number of things I don't like about the definitions and that would require manual editing. First, tons of APIs are inexplicably commented out. The APIs that aren't commented out, the flag sets aren't even converted to enums, much less associated with their api, unless they were that way in the header. Some descriptions are incorrect. I do the Unicode thing different: provide W, DeclareWide W, and sometimes A...

That's why I had wanted to convert from tbShellLib rather than use an existing API TLB along these lines. Spent a ton of time cleaning them up.

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

Quote:

Originally Posted by Semke

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.

If the guy says he has maintained that Unicode TLB over the years then it logically follows that compiling it shouldn't be all that complicated. I have never compiled a TLB myself, mind you, I am just trying to understand why your MIDL fails to compile your TLB while others don't seem to have any problems... However you're right to wait for TwinBasic to export TLBs rather than pulling your hair with the current version.

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

Microsoft Win32 API Loader
WIN32API.TXT
how to cange WIN32API.TXT to api.db?
but it's access 2000 or access97 format? i can't open it by office2013,who can upload access2000 or 2003 format mdb file?

Can it be directly converted into a WIN32ApI.TLB file, including all declarations, structures, and APIs? Or is there a ready-made one on the Internet?

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

Quote:

Originally Posted by VanGoghGaming

If the guy says he has maintained that Unicode TLB over the years then it logically follows that compiling it shouldn't be all that complicated. I have never compiled a TLB myself, mind you, I am just trying to understand why your MIDL fails to compile your TLB while others don't seem to have any problems... However you're right to wait for TwinBasic to export TLBs rather than pulling your hair with the current version.

There's problems with one very specific issue: When you need to redefine certain low-level COM/OLE stuff for VB compatibility. midl doesn't allow redefinitions, MKTYPLIB does. The main difference *may* be the renaming of interfaces in the hardcore VB typelib; he renames everything IVB____. I'm not willing to do that. I don't have any problems using midl when I'm not trying to redefine low level COM/OLE stuff. I didn't spend all that much time trying to compile it as-is; only did for reference after adapting it's techniques failed to see if it was just oleexp.

But actually... I probably could take the apis from the decompiled typelib, though it won't have the same unicode standards or immense effort put into making enums for everything.

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

Now that you mentioned it, I did see some IVB interfaces defined in Bruce McKinney's TLB, for example IVBStream. I saw that it was working as intended so I didn't think much of it that it has a different name...

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

From the end-user perspective the name wouldn't matter, but it would be a huge compatibility issue at this point (or even a couple years ago when I seriously looked at compiling a 64bit version), since me and many others have large codebases with the actual names.

But no matter, I anticipate tB supporting TLB export within the next year or so... it's waited this long. If you like having a massive set of APIs at your fingertips, I recommend upgrading to twinBASIC and using tbShellLib (although fair warning, as beta software, there's issues like *serious* performance issues with something the size of tbShellLib).

A final option might be; tB chokes on compiling the full project as an active-x DLL, but if I could make a separate one... I might be able to pull the APIs from it. Didn't know predeclared APIs were in this high demand for oleexp.

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

Hi fafalone,

Three points:

1. I always recompile the tlb. One reason is the declarations dealing with PROPVARIANTs. In most cases you declare the parameters (e.g in IPropertyStore.GetValue) as VARIANT*. This leads into trouble if the Vartype is incompatible with Visual Basic. I modify all those to PROPVARIANT* and it works. (Made an extended app derived from your Set Default Device sample -> GetValue throws an error if the value param is of type Variant here.)

2. There are some null length odl files in the source folder. Although they are not included in oleexp.old I wonder what they are good for? Especially dsound.odl would be nice to be filled in as it would make the use of my own tlb unnecessary.

3. For the definition of GUIDs you deliver those additional modules. This is somehow laborious. My approach is to define GUIDs as string consts in type libraries and then a.) use a loader function in apps that enumerates those consts (ITypeInfo-> members, get names, filter,...) and store them in a dictionary, b.) have a general function to get the UUIDs from this dictionary per IIDFromString using the GUID names as keys.

Again many thanks for your endless support of this type library!

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

1) I've found there's more problems that arise dealing with the struct like that; not all types are 4 bytes, for instance, VB has a lot of features to make handling Variants easy, you just need to, as mentioned, be careful with the typing. If you only deal with simple numbers, the struct is appealing, but if you're dealing with pointers, it's a lot less convenient to dereference or allocate manually. I've got routines to manage that I use; like if it's an unsigned long, I have a VariantSetType function to overwrite the first 2 bytes with VT_I4, making it into a compatible signed long. I'd need to see an example of the problem with GetValue there, as VARIANT and PROPVARIANT aren't actually different... they differ only in the types of data they officially support; but the memory layout is 100% identical. Note that like VB, other apps get crashy if the format isn't *exactly* what they're expecting.

2) In most cases these are stubs for future work, to remind myself 'hey you wanted to add this'... for example dsound.odl has been renamed exp_dsound.odl, is nearly finished, and will be in the next release :)

3) That sounds *a lot* more laborious. I have a tool that autogenerates those GUID functions. All I have to do is copy/paste the whole ODL file into a textbox, click, and copy/paste the result. It took a couple hours to make the tool, but it's saved the thousands of hours that would have otherwise taken. Then typing IID_IFoo is no more trouble than a dictionary lookup.

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

Project Updated - Version 6.4

I'm planning on releasing the simplest Ribbon demo as a VB project (currently tB only), the oleexp version of the interfaces had bugs.

Added Sensor API and Location API. Sensor pkeys added to mPKEY.
Added IStorageProviderHandler
Added DirectSound8, courtesy of The trick/mossSOFT DSVBLib
Added Distributed Transaction Manager basic interfaces
Bug fix: Ribbon interfaces were not Implements-compatible and one used a custom UDT instead of a Variant.

1 Attachment(s)

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

Quote:

Originally Posted by fafalone

1) I've found there's more problems that arise dealing with the struct like that; not all types are 4 bytes, for instance, VB has a lot of features to make handling Variants easy, you just need to, as mentioned, be careful with the typing. If you only deal with simple numbers, the struct is appealing, but if you're dealing with pointers, it's a lot less convenient to dereference or allocate manually. I've got routines to manage that I use; like if it's an unsigned long, I have a VariantSetType function to overwrite the first 2 bytes with VT_I4, making it into a compatible signed long. I'd need to see an example of the problem with GetValue there, as VARIANT and PROPVARIANT aren't actually different... they differ only in the types of data they officially support; but the memory layout is 100% identical. Note that like VB, other apps get crashy if the format isn't *exactly* what they're expecting.

2) In most cases these are stubs for future work, to remind myself 'hey you wanted to add this'... for example dsound.odl has been renamed exp_dsound.odl, is nearly finished, and will be in the next release :)

3) That sounds *a lot* more laborious. I have a tool that autogenerates those GUID functions. All I have to do is copy/paste the whole ODL file into a textbox, click, and copy/paste the result. It took a couple hours to make the tool, but it's saved the thousands of hours that would have otherwise taken. Then typing IID_IFoo is no more trouble than a dictionary lookup.

1) Ok. Dont know what I did. Maybe some projects (dsound/mediafoundation) that were made with older versions of oleexp (that I recompiled) now are incompatible with v6.3. Even VarType(varFromvarProp) raised the error "Type unsupported by VB".

2) Out already! :) I have to inspect if you've also transferred some mistakes I found meanwhile... :bigyello: (e.g. GetObjectInPath for CaptureBuffer -> *DSGUID)

3.) Anyway. I attach a small demo on how I accomplish this. The module inside has to be modified for every other project. GetIID() has the advantage that you can select the IID from the enumeration parameter. Pitfall: The TLB has to be stored beside the project and/or .exe.

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

I'm not sure why older projects would be incompatible... nothing old was touched besides the ribbon interfaces. VarType I think has to be used on an actual variant, not the PROPVARIANT udt. Could you be more specific with what happened?

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

This Type Library includes a Lot of Interfaces, Some Which i have never heard of and some which sound quite interesting (i have not been using interfaces so much).

is there a place which i can read up on these interfaces, i am sure that once i (or anybody else) know more about them, we can make major use out of them.

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

Just search for their name on Google etc, that will bring up Microsoft's documentation and usually lots of other info and examples.

Of course the 55 example projects on the first post in this thread cover a lot too, most of them have a list in small italicized font of what interfaces they're demonstrating.

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

Quote:

Originally Posted by fafalone

I'm not sure why older projects would be incompatible... nothing old was touched besides the ribbon interfaces. VarType I think has to be used on an actual variant, not the PROPVARIANT udt. Could you be more specific with what happened?

Sorry, I am not able to recreate the situation where I had the errors. One had happend with your sample app for setting the default sound devices which I altered slightly. Maybe when trying to find out which other device property keys work besides DeviceFriendly name. (Enumeration over IPropertyStore.GetCount()/.GetAt()). Some properties give back arrays, some other binary structs. PropVariantToVariant then resulted a in variant type that is unsupported by VB.
The other situation was when experimenting with mediafoundation capturing video streams (based on a sample from TheTrick) - long ago...

Quote:

...the problem with GetValue there, as VARIANT and PROPVARIANT aren't actually different... they differ only in the types of data they officially support; but the memory layout is 100% identical.

Well, PROPRVARIANT has three additional dwReserved members between vt and value. So I guess it's not 100%.
I disassembled propsys.dll (IDA) and looked into the routine for PropVariantToVariant. It spreads over about 300 lines. I think this would not be the case if the two types were identical?

But let's stop this academical discussion -your implemention works and mine also. If I am the only one that had those issues then there is absolutely no need to find out the 'real way'. ;)

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

VARIANT also has those reserved members.

Code:

typedef /* [wire_marshal] */ struct tagVARIANT VARIANT; struct tagVARIANT { union { struct __tagVARIANT { VARTYPE vt; WORD wReserved1; WORD wReserved2; WORD wReserved3; union { LONGLONG llVal; LONG lVal; BYTE bVal; SHORT iVal; FLOAT fltVal; DOUBLE dblVal; VARIANT_BOOL boolVal; VARIANT_BOOL __OBSOLETE__VARIANT_BOOL; SCODE scode; CY cyVal; DATE date; BSTR bstrVal; IUnknown *punkVal; IDispatch *pdispVal; SAFEARRAY *parray; BYTE *pbVal; SHORT *piVal; LONG *plVal; LONGLONG *pllVal; FLOAT *pfltVal; DOUBLE *pdblVal; VARIANT_BOOL *pboolVal; VARIANT_BOOL *__OBSOLETE__VARIANT_PBOOL; SCODE *pscode; CY *pcyVal; DATE *pdate; BSTR *pbstrVal; IUnknown **ppunkVal; IDispatch **ppdispVal; SAFEARRAY **pparray; VARIANT *pvarVal; PVOID byref; CHAR cVal; USHORT uiVal; ULONG ulVal; ULONGLONG ullVal; INT intVal; UINT uintVal; DECIMAL *pdecVal; CHAR *pcVal; USHORT *puiVal; ULONG *pulVal; ULONGLONG *pullVal; INT *pintVal; UINT *puintVal; struct __tagBRECORD { PVOID pvRecord; IRecordInfo *pRecInfo; } __VARIANT_NAME_4; } __VARIANT_NAME_3; } __VARIANT_NAME_2; DECIMAL decVal; } __VARIANT_NAME_1; } ;

Code:

struct tagPROPVARIANT { union { #endif struct tag_inner_PROPVARIANT { VARTYPE vt; PROPVAR_PAD1 wReserved1; PROPVAR_PAD2 wReserved2; PROPVAR_PAD3 wReserved3; /* [switch_is] */ /* [switch_type] */ union { /* [case()] */ /* Empty union arm */ /* [case()] */ CHAR cVal; /* [case()] */ UCHAR bVal; /* [case()] */ SHORT iVal; /* [case()] */ USHORT uiVal; /* [case()] */ LONG lVal; /* [case()] */ ULONG ulVal; /* [case()] */ INT intVal; /* [case()] */ UINT uintVal; /* [case()] */ LARGE_INTEGER hVal; /* [case()] */ ULARGE_INTEGER uhVal; /* [case()] */ FLOAT fltVal; /* [case()] */ DOUBLE dblVal; /* [case()] */ VARIANT_BOOL boolVal; /* [case()] */ VARIANT_BOOL __OBSOLETE__VARIANT_BOOL; /* [case()] */ SCODE scode; /* [case()] */ CY cyVal; /* [case()] */ DATE date; /* [case()] */ FILETIME filetime; /* [case()] */ CLSID *puuid; /* [case()] */ CLIPDATA *pclipdata; /* [case()] */ BSTR bstrVal; /* [case()] */ BSTRBLOB bstrblobVal; /* [case()] */ BLOB blob; /* [case()] */ LPSTR pszVal; /* [case()] */ LPWSTR pwszVal; /* [case()] */ IUnknown *punkVal; /* [case()] */ IDispatch *pdispVal; /* [case()] */ IStream *pStream; /* [case()] */ IStorage *pStorage; /* [case()] */ LPVERSIONEDSTREAM pVersionedStream; /* [case()] */ LPSAFEARRAY parray; /* [case()] */ CAC cac; /* [case()] */ CAUB caub; /* [case()] */ CAI cai; /* [case()] */ CAUI caui; /* [case()] */ CAL cal; /* [case()] */ CAUL caul; /* [case()] */ CAH cah; /* [case()] */ CAUH cauh; /* [case()] */ CAFLT caflt; /* [case()] */ CADBL cadbl; /* [case()] */ CABOOL cabool; /* [case()] */ CASCODE cascode; /* [case()] */ CACY cacy; /* [case()] */ CADATE cadate; /* [case()] */ CAFILETIME cafiletime; /* [case()] */ CACLSID cauuid; /* [case()] */ CACLIPDATA caclipdata; /* [case()] */ CABSTR cabstr; /* [case()] */ CABSTRBLOB cabstrblob; /* [case()] */ CALPSTR calpstr; /* [case()] */ CALPWSTR calpwstr; /* [case()] */ CAPROPVARIANT capropvar; /* [case()] */ CHAR *pcVal; /* [case()] */ UCHAR *pbVal; /* [case()] */ SHORT *piVal; /* [case()] */ USHORT *puiVal; /* [case()] */ LONG *plVal; /* [case()] */ ULONG *pulVal; /* [case()] */ INT *pintVal; /* [case()] */ UINT *puintVal; /* [case()] */ FLOAT *pfltVal; /* [case()] */ DOUBLE *pdblVal; /* [case()] */ VARIANT_BOOL *pboolVal; /* [case()] */ DECIMAL *pdecVal; /* [case()] */ SCODE *pscode; /* [case()] */ CY *pcyVal; /* [case()] */ DATE *pdate; /* [case()] */ BSTR *pbstrVal; /* [case()] */ IUnknown **ppunkVal; /* [case()] */ IDispatch **ppdispVal; /* [case()] */ LPSAFEARRAY *pparray; /* [case()] */ PROPVARIANT *pvarVal; } ; } ; #ifndef MIDL_PASS DECIMAL decVal; }; };

Variant is in oaidl.h, propvar in propidlbase.h

That's what VB's Variant looks like behind the scenes.

They're identical in *memory layout*... not in officially supported types. PropVariantToVariant attempts to convert the extra types a PROPVARIANT supports into a data type allowed in a VARIANT. The union contains a longer list of data types in a propvar, that's it (and none of them alter the total size or alignment under either x86 or x64).

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

Very good. Thank you for your effort

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

Quote:

Originally Posted by SaschaT

2) Out already! :) I have to inspect if you've also transferred some mistakes I found meanwhile... :bigyello: (e.g. GetObjectInPath for CaptureBuffer -> *DSGUID)

Indeed. For the next release please change to:

Code:

Interface IDirectSoundCaptureBuffer8 : IDirectSoundCaptureBuffer { HRESULT GetObjectInPath([in] UUID* rguidObject, [in] long dwIndex, [in] UUID* rguidInterface, [out, retval] IUnknown** ppObject);

...although one will rarely use those effects while recording... :rolleyes:

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

If IsEqualIID(tCF, GUID_ContainerFormatJpeg) Then mCodec = WFF_JPG
can it check is webp format?
webp file header:

Code:

RIFF ? WEBPVP8X

==============
question 2:how to change webp img file to jpg or png without hdc?

'cWICImage 0.2
'Windows Imaging Component Basic Usage Demo

it's use hdc:
Public Function OpenFile(sFile As String, ToHDC As Long, x As Long, y As Long, Optional nFrame As Long = 0&, Optional hWnd As Long) As Boolean

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

Hi,

All the demos of ucShellBrowse don't work on my PC with Windows 11. (I think it work on my old PC with Windows 7).
I have to comment the line :

Code:

' RtlFreeUnicodeString strUnicode

in the function

Code:

Private Function FindFirstFileNt(ByVal strDirectory As String, bytBuffer() As Byte) As Long

Is it a problem if I don't use RtlFreeUnicodeString ?

Thank you for your help.

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

It will cause a small memory leak as strings aren't freed until app exit but I don't believe it will cause further problems. If for some reason it does, that routine is part of the high performance loader, to disable: in the Properties in the form designer for the control, set HighPerformanceMode to False. The performance difference is negligible until you reach thousands of files in a folder, and then only more then 2-3s when you reach the tens of thousands.

I'll look into this issue, thanks for letting me know.

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

Thank you for your help.

It is the same behaviour with HighPerformanceMode = False. The IDE closes when the program reaches the Function FindFirstFileNt where RtlFreeUnicodeString strUnicode occurs.

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

That's extremely odd; do you have the most recent version (and of the VB6 version right, not the tB version?), and can you do me a favor and look at the beginning of LVLoadFolder, and verify this line hasn't been altered or commented out?

Code:

If (mHighPerfMode = True) And (mExtColPreload = False) Then

and that the property for that is ok?

Code:

Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = mHighPerfMode: End Property Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = bVal: End Property

FindFirstFileNt is only called from LVLoadFolderEx, and LVLoadFolderEx is only called from within that block requiring mHighPerfMode to be True; something more serious is afoot if something is causing it to jump into that without being called-- or it's been modified somehow and you should update it. I've checked against the version posted in this thread and the tB x64 version on GitHub, neither enter FindFirstFileNt when HighPerformanceMode = False for me. One little thing just to make sure; you saved before you hit run, right? Or if you're not running from the IDE, check if it's happening in both IDE and compiled?

Finally if nothing in this post is the issue, let me know your exact Windows 11 version so I can spin up a VM and check it out in there.

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

Hi fafalone,
I confirm that on all the demos the IDE leaves immediately on Win10 and Win11.

This doesn't appear on Win7

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

Just quits with no error? Is this also about ucShellBrowse? Definitely haven't seen or heard this before, likely something specific about your system.

Oh and for both of you, OCX or .CTL? And impacting .exe too?

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

I have only tested the .CTL

Code:

' * ucShellBrowse v11.2 * ' * Shell Browser Control * ' * * ' * Released: 18 Jun 2022 *

This line is not commented:

Code:

If (mHighPerfMode = True) And (mExtColPreload = False) Then

These lines are ok.

Code:

Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = mHighPerfMode: End Property Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = bVal: End Property

Now I have changed this line to False :

Code:

Private Const mDefHighPerfMode As Boolean = False

This time, it's ok. The last time, I had'nt set mDefHighPerfMode to False but quickly changed the properties directly to False. Something like that :

Code:

Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = False: End Property Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = False: End Property

Now with mDefHighPerfMode=False, it's working.

So if I don't set mDefHighPerfMode to False, the IDE crashes, but if mDefHighPerfMode = True, when I compile, the .exe works. Good to know.

Thanks

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

No problem, glad it's working now. I'll still definitely check out what the IDE issue with in on 11; odd that it would crash there but not in the compiled exe. Although IIRC I did have some issues with RtlDosPathNameToNtPathName_U, the original way of initializing that string, similarly crashing some Windows versions.

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

-Quits with no error.
-ucShellBrowse
-CTL

And there is nothing sprecial in my systems.

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

@ Crapahute

Congratulations !
Private Const mDefHighPerfMode As Boolean = False

All it's OK.
Thank you so much.

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

Maybe I will make mDefHighPerfMode a variable :

Code:

'Private Const mDefHighPerfMode As Boolean = True Private mDefHighPerfMode As Boolean

and use IsIDE to set its value.

Code:

Private Sub UserControl_Initialize() If IsIDE = True Then mDefHighPerfMode = False Else mDefHighPerfMode = True End If ...

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

Looking into this further, it appears RtlFreeUnicodeString should be removed.

MSDN states "The RtlFreeUnicodeString routine releases storage that was allocated by RtlAnsiStringToUnicodeString or RtlUpcaseUnicodeString."

So it looks like it's a mistake that was harmless on previous versions of Windows, but causing problems now; potentially a double-free, or use-after-free. The call is safe to comment out; it won't cause a memory leak as it turns out it just points to the existing string, and doesn't allocate anything itself. VB will free the string.

Embarrassingly, it appears I found that out a while ago and forgot, because the RtlFreeUnicodeString has already been removed from v12.0 (VB6 version unreleased, but available for twinBASIC).

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

Hi fafalone,

You're right "RtlFreeUnicodeString " must be removed.
I replace Private Const mDefHighPerfMode As Boolean = False by True
and removed RtlFreeUnicodeString sub and the line RtlFreeUnicodeString strUnicode
Now it works

Regards

API OleCreatePictureIndirect definition wrong?

oleexp v6.4

I guess the definition of the API OleCreatePictureIndirect in the TLB is wrong:

Code:

Function OleCreatePictureIndirect(lpPictDesc As PICTDESC, riid As UUID, fOwn As BOOL) As IPicture

MSDN:

Code:

WINOLECTLAPI OleCreatePictureIndirect( [in] LPPICTDESC lpPictDesc, [in] REFIID riid, [in] BOOL fOwn, [out] LPVOID *lplpvObj ); This function returns S_OK on success. Other possible return values: E_NOINTERFACE, E_POINTER

I use this API definition in my code and it matches with MSDN:

Code:

Private Declare Function OleCreatePictureIndirect Lib "oleaut32.dll" ( _ ByRef lpPictDesc As PICTDESC, _ ByRef riid As UUID, _ ByVal fOwn As Boolean, _ ByRef lplpvObj As Object) As Long

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

That definition from oleexp is not wrong on its own, it's just "different". If you use it "as is" you are constrained to also use the "PICTDESC" and "UUID" types from the same typelib. I use a more generic definition that is not restricted in any way as you can pass it any pointer you want:

Code:

Private Declare Function OleCreatePictureIndirect Lib "oleaut32" Alias "#419" (ByVal lpPictDesc As Long, ByVal lpIID As Long, ByVal fOwn As Long, ByVal lplpvObj As Long) As Long

I think the general consensus is that if you use UDTs in API declarations (except those from TypeLibs), they will be subject to Unicode to ANSI conversion even if there aren't any strings involved. Those conversions can be avoided by using pointers instead.

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

VB6 actually has extended support for string formats in typelibs. You can use LPWSTR and LPSTR, and they both work as they're supposed to.

But yes the API definition is just rewritten, not broken. When the last parameter is [out], you can rewrite it with [out, retval] to turn the last parameter into the return value instead. This is only allowed with typelibs, it won't work with API defs within VB6 with Declare Function. I'm not a fan of doing it that way either, you can direct your criticisms at the original author of olelib, which oleexp is forked from :)

It was kept for backwards compatibility with olelib. It's been dropped in WinDevLib, when you move into the future with oleexp's successor in twinBASIC, it covers 100% of oleexp interfaces, then adds over 5,500 APIs, not counting A/W alternates. :)

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

DON'T USE THE API's IN THE TYPELIB. USE THE API's FROM MSDN!!
I use this API this way and it works all the time..

Code:

Declare Function OleCreatePictureIndirect Lib "oleaut32.dll" ( _ ByRef lpPictDesc As PICTDESC, _ ByRef riid As GUID, _ ByVal fOwn As Boolean, _ ByRef lplpvObj As Any) As Long

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

People have used typelibs with APIs with final [out]s rewritten as [out, retval] for decades.

In fact be careful with nebeln's definition, you have to make sure GUID isn't referring to stdole2.GUID, because it's incompatible with VB due to use of unsigned types.

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

At first i thought i can get rid of all the API/const/Type/enum declarations in my projects when using only oleexp but now i dont change anything to not run into unnecessary problems coze of the possible different declarations...

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

With my declaration above you can use any types you want (either your own or from the TypeLib), they all work! ;)

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

Project Updated - Version 6.5

This brings oleexp.tlb up to date interface-wise with the latest Windows Development Library release, which I posted earlier today, adding a large expansion of DirectWrite coverage. oleexp was quite a bit behind, so there's a lot of new stuff in this release:

Code:

(oleexp 6.5 - Released 05 April 2024) -Added all newer DirectWrite interfaces (dwrite_1.h, dwrite_2.h, dwrite_3.h) -Added legacy Sync Manager interfaces/coclasses (mobsync.h, 100%) -Added Photo Acquisition interfaces and coclasses (photoacquire.h, 100%) -Added NetCon interfaces -Added IPrintDocumentPackage* interfaces and coclasses (DocumentTarget.idl, 100%) -Added Credential Provider interfaces -Added UI Animation interfaces and coclasses -Added IThumbnailStreamCache and coclass ThumbnailStreamCache. Note: Due to simple name potential conflicts, flags prefixed with TSC_. A ByVal SIZE is split into two Longs. -Added Radio Manager interfaces and some undocumented coclasses to use them. -Added IAccessControl/IAuditControl interfaces -Added certain shdeprecated.h interfaces still in undocumented use -Added security center interfaces from iwscapi.h -(Bug fix) Several WIC interfaces had improper ByRef String (as Long) types. -(Bug fix) IFilterCondition incorrect inheritance -(Bug fix) ICommDlgBrowser2,3 string members incorrect. -(Bug fix) DWRITE_RENDERING_MODE incomplete The following was listed as added in v5.3 but was never actually compiled in until now: -Added Sync Manager interfaces and coclasses (SyncMgr.h), including undocumented ITransferConfirmation/coclass TransferConfirmationUI.

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

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

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