Very good work.
Do you have an example with active scripting interfaces?
It can be used to control the program and objects.
Some look very interesting I'll try them.
All the best
Printable View
Very good work.
Do you have an example with active scripting interfaces?
It can be used to control the program and objects.
Some look very interesting I'll try them.
All the best
No example in VB yet but this C++ example would be fairly simple to convert.
what about ebmode vba6.dll?
CopyMemory ByVal VarPtr(LinkProc(4)) + 3, GetProcAddress(GetModuleHandle("vba6.dll"), "EbMode"), 4&
Which other TLB implements this interface?
That's not an interface and you don't need a typelib for it, you need a declare statement, for all uses besides multithreading.
Private Declare Function EbMode Lib "vba6" () As Long
in vb, not a TLB.
...if you did want to add it to a tlb,
Code:[dllname("vba6.dll")]
module msvbvm60
{
[entry("EbMode")]
long EbMode(void);
}
error,why?Code:Dim oITypeInfo As oleexp.ITypeInfo
Dim oITypeInfo2 As oleexp.ITypeInfo2
Dim oIDispatch As oleexp.IDispatch
Set oIDispatch = Object1 ' get the IDispatch interface
Set oITypeInfo = oIDispatch.GetTypeInfo(0, 2052)
set oITypeInfo2 =oITypeInfo
how to get COM OBJECT function or method address by oleexp.tlb?BUTVtableAddress1 NOT VTABLE OF method,how to do?Code:MethodName=“Navigate”
Dim IID_NULL As oleexp.UUID, DispIDA As Long
Dim VtableAddress1 As Long, Ptr As Long
oIDispatch.GetIDsOfNames IID_NULL, MethodName, 1, 0, DispIDA
VtableAddress1 = oITypeInfo.AddressOfMember(DispArr(0), INVOKE_FUNC)
\
get COM OBJECT Navigate address of WebBrowser1.Navigate
Dim fun As FUNCDESC
dim p as long
p=oITypeInfo.GetFuncDesc(i)
how to set fun=p?
The number of members cannot be obtained for VB6 class objects compiled into EXE.
Other third-party OCX controls can be obtained by adding .OBJECT
Code:Msgbox GetMethodCount(Class1A) '0
Msgbox GetMethodCount(WebBrowser1) '0
Msgbox GetMethodCount(Web) '19
Msgbox GetMethodCount(WebBrowser1.Object) '19
Msgbox GetMethodCount(WebBrowser1.Document) '379
Msgbox "DataGrid1 METHOD=" & GetMethodCount(DataGrid1) '0
Msgbox "DataGrid1.Object METHOD=" & GetMethodCount(DataGrid1.Object) '111
Code:Function GetMethodCount(Obj1 As Object) As Long
Dim oITypeInfo As olelib.ITypeInfo, vAttrs As TYPEATTR, vTable As Long
Dim oIDispatch As olelib.IDispatch, pAddress As Long, Fptr As Long
Set oIDispatch = Obj1 ' get the IDispatch interface
Set oITypeInfo = oIDispatch.GetTypeInfo(0, 0)
'Msgbox oITypeInfo.GetFuncDesc(0)
Dim fundisp As Long
On Error GoTo err1
'CallCOMInterface& ObjPtr(oITypeInfo), 6, 0&, VarPtr(fundisp)
fundisp = oITypeInfo.GetFuncDesc(0)
If fundisp <> 0 Then
pAddress = oITypeInfo.GetTypeAttr
CopyMemory vAttrs, ByVal pAddress, Len(vAttrs) ' copy that structure
oITypeInfo.ReleaseTypeAttr pAddress
GetMethodCount = vAttrs.cFuncs
End If
Exit Function
err1:
End Function
fafalone:
Want to use your old code ref'd in Core Audio - Change the system default audio device' 841167-VB6-Vista-Core-Audio-Change from
The page references oleexp.tlb v4.11 (or higher), using the .bas addons mIID, mCoreAudio and mPKEY. Is the old project compatible with your newest release (v6.3)? Or can we get something closer to 4.11 if that's necessary?
We have users from Win7 to Win11. Are there any known issues with those OS's? (We compile on a VB6 IDE)
[You mention also communicating via DM or email, but I don't see how to get an address for the latter. I could point you to a contact-us link on one of my sites if that'd be helpful.]
Thank you!
The Core Audio interfaces haven't changed since originally being added, besides a couple bugfixes and adding additional interfaces missing from earlier versions, so yes you can (and should) use the newest version. It still contains those addons in the download zip.
I haven't tested that particular code on Windows 11 -- as the page mentioned, it's undocumented, and has already been broken by MS once (you need a different version for Windows Vista), so there's no guarantees of working going forward. But some quick searches suggest the Windows 7+ version is still working on Windows 11.
Email is my username at gmail, but honestly I check VBF more often.
Downloaded oleexp63.zip and the core audio project.
Having trouble pointing Project/References OLEEXP to the location where the type library is stored.
The OLEEXP shows as missing, we select browse, open the location for oleexp.tlb, but then the panel showing location still points to D:\tl_ole\eexp.tlb.
Even putting the file there doesn't change the MISSING indication. What am I doing wrong?
Before selecting:
Attachment 188192
During:
Attachment 188193
After (still shows default D:\tl_ole):
Attachment 188191
try unchecking then click ok, then reopen and retick then click ok.
What k_zeon posted should fix it; by the looks of it, the project is referencing a version before GUID accidentally got switched, so selecting the new one doesn't satisfy it. Your list like already contains "OLEEXP - Modern Shell Interfaces for VB6, v6.3", but following the steps above will ensure it adds the newer one.
Still no luck. Unchecked, ok, reopen, retick, then browse to location, ok, still shows Location on main panel as this project's directory, not where I want to place them.
Unchecked:Attachment 188196
Checked - default location shows project directory:Attachment 188197
Browse, select dir: Attachment 188198
OK, then location is still wrong:Attachment 188199
Worse, when I put the library in the project directory, the compile crashes with "VB has stopped working" But I hope that's bec the library isn't referenced yet.
Thx for helping.
All those attachments are broken.
1) Uncheck
2) Click browse
3) Navigate to the one you want to use and select it
4) Look carefully at the list now: Do you have *two* items:
"OLEEXP - olelib with Modern Interfaces,,"
and
"OLEEXP - Modern Shell Interfaces for VB6, v6.3" (or another 5.x or 6.x version?)
5) If so, select the second one, "OLEEXP - Modern Shell Interfaces for VB6, v6.3"
6) Save project
This is awesome! However the TLB is missing a few important things in the kernel32 module. While it has VirtualAlloc, it's missing VirtualFree. So if you just use VirtualAlloc, you'll find yourself in a situation where you can't release the memory you allocated.
It is missing a lot of useful API declarations but you can always declare them yourself when needed... Manual declarations are arguably better since you can play around with the types of parameters.
Well you can use memory allocated with the TLB's VirtualAlloc with a locally defined VirtualFree (Declare Function ...)
Almost all the APIs in there are just what's in the original olelib this project was forked from; I have never intended for this project to become a comprehensive source of APIs. Not in the least because it's a metric crapton of work to rewrite everything VB-friendly and you can already do it in VB unlike interfaces/coclasses. But since a lot of people did apparently want that, I've done it with oleexp's successor, tbShellLib-- the 64bit compatible version for twinBASIC, which contains 100% coverage of oleexp. oleexp is now in end-of-life maintenance mode; I'm keeping the interfaces in sync with tbShellLib and doing bugfixes, but won't be adding the APIs. I've taken great care to not only manually double-check all the types for x64 compatibility, but also to provide enums wherever there's a limited set of values even where an enum isn't provided in C++, and to provide multiple versions for String/LongPtr and for the most common ones, ANSI String. It's currently up to the top 1500 or so most common APIs from the default Windows headers (I'm not including most specialized libraries; it would not only take years but grind intellisense and syntax adjusting/highlighting to a halt, main exception is GDI+) and also includes things like all the WM_ messages, all the WS_ and WS_EX_ styles, common errors, etc.
In the future, twinBASIC will support exporting TLBs. When that happens, oleexp will be replaced with a 32bit tbShellLib.tlb for VB6/VBA 32bit, and a 64bit tbShellLib.tlb for VBA 64bit.
*If somebody wrote a tool to convert VB API declares to MKTYPLIB-compatible IDL syntax, I'd put the APIs in oleexp. The tool would need to handle tB's DeclareWide, LongPtr, and LongLong. This would still leave some manual work to be done, e.g. since tB supports passing a null pointer instead of a UDT, many optional UDTs have been replaced with their true type rather than As Any, which is the only way VB6 can pass both a UDT and null pointer (ByVal 0), but it would be realistic.
You can try manually register it with RegTLibQuote:
Originally Posted by murspieg1
Still, there are some obviously missed very useful functions. The VirtualFree one is a good example. Each memory allocation function should have a matched memory free function.Quote:
Originally Posted by fafalone
I'll add it to the next release. any others you'd like added? Within reason, not doing more than 50. Unless you want to write the IDL declares 😉
Quote:
Originally Posted by fafalone
A long time ago a came across a book from MS Press Hardcore visual basic 2nd Edition, on the CD which was in the book they had A Type Library which had almost all API's Declared in it. the declaration were very well organized. additional it had quite a few interfaces. it could be compile in Unicode or ANSI.
I have been using it in all my projects, which saved me from typing all the API Declarations in my projects. although as windows evolved, I had to add many declarations myself, and in the many years it has evolved to include many more Declarations.
while I would not suggest that my TLB is perfect, (I only maintained Unicode, since the beginning of time I was an ANSI Denier). the source (in IDL) could help you if you are interested.
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.
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.Quote:
Originally Posted by Semke
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?
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.Quote:
Originally Posted by VanGoghGaming
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.
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...
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.
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!
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.
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) 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".Quote:
Originally Posted by fafalone
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.
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?
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.
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.
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.Quote:
Originally Posted by fafalone
The other situation was when experimenting with mediafoundation capturing video streams (based on a sample from TheTrick) - long ago...
Well, PROPRVARIANT has three additional dwReserved members between vt and value. So I guess it's not 100%.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.
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'. ;)
VARIANT also has those reserved members.
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;
} ;
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).
Very good. Thank you for your effort
Indeed. For the next release please change to:Quote:
Originally Posted by SaschaT
...although one will rarely use those effects while recording... :rolleyes:Code:Interface IDirectSoundCaptureBuffer8 : IDirectSoundCaptureBuffer {
HRESULT GetObjectInPath([in] UUID* rguidObject, [in] long dwIndex, [in] UUID* rguidInterface, [out, retval] IUnknown** ppObject);
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
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 :
in the functionCode:' RtlFreeUnicodeString strUnicode
Is it a problem if I don't use RtlFreeUnicodeString ?Code:Private Function FindFirstFileNt(ByVal strDirectory As String, bytBuffer() As Byte) As Long
Thank you for your help.
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.
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.
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?
and that the property for that is ok?Code:If (mHighPerfMode = True) And (mExtColPreload = False) Then
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?Code:Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = mHighPerfMode: End Property
Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = bVal: End Property
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.
Hi fafalone,
I confirm that on all the demos the IDE leaves immediately on Win10 and Win11.
This doesn't appear on Win7
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?
I have only tested the .CTL
Code:' * ucShellBrowse v11.2 *
' * Shell Browser Control *
' * *
' * Released: 18 Jun 2022 *
This line is not commented:
These lines are ok.Code:If (mHighPerfMode = True) And (mExtColPreload = False) Then
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 :
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:Private Const mDefHighPerfMode As Boolean = False
Now with mDefHighPerfMode=False, it's working.Code:Public Property Get HighPerformanceMode() As Boolean: HighPerformanceMode = False: End Property
Public Property Let HighPerformanceMode(bVal As Boolean): mHighPerfMode = False: End Property
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
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.
-Quits with no error.
-ucShellBrowse
-CTL
And there is nothing sprecial in my systems.
@ Crapahute
Congratulations !
Private Const mDefHighPerfMode As Boolean = False
All it's OK.
Thank you so much.
Maybe I will make mDefHighPerfMode a variable :
and use IsIDE to set its value.Code:'Private Const mDefHighPerfMode As Boolean = True
Private mDefHighPerfMode As Boolean
Code:Private Sub UserControl_Initialize()
If IsIDE = True Then
mDefHighPerfMode = False
Else
mDefHighPerfMode = True
End If
...
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).
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
oleexp v6.4
I guess the definition of the API OleCreatePictureIndirect in the TLB is wrong:
MSDN:Code:Function OleCreatePictureIndirect(lpPictDesc As PICTDESC, riid As UUID, fOwn As BOOL) As IPicture
I use this API definition in my code and it matches with 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
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
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:
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.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
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. :)
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
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.
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...
With my declaration above you can use any types you want (either your own or from the TypeLib), they all work! ;)
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.
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.