No problem, Fafalone. I (for one) appreciate all the work you've done with this thing. Also, not sure I see the problem with returning HRESULT. :)Quote:
Originally Posted by fafalone
Printable View
No problem, Fafalone. I (for one) appreciate all the work you've done with this thing. Also, not sure I see the problem with returning HRESULT. :)Quote:
Originally Posted by fafalone
Thanks :)
HRESULT... In C/C++ there's no automatic error handling... an interface method informs you an error occurred by returning a negative HRESULT. VB consumes this and hides it for its automatic error handling system. In C/++ you have to check it yourself; in VB, VB checks it, and raises an error you can handle with 'On Error GoTo' on 'On Error Resume Next'.
The problem is VB is essentially treating every error as a critical failure with the 'GoTo' option... a lot of the time, you don't want to jump out to an error handler and abandon the entire method, for example with enumerators-- running out of items is the inevitable end of a COM enumeration. On Error GoTo sucks for that. But Resume Next, you often don't want to disable VB's natural error handling for all the VB-native code too, so you might find yourself needing to change error handling tons of times.
Personally I wish there was an option for 'Ignore errors for interfaces I've defined' option. That's what nebeln is essentially trying to do. The problem is a lot of people don't *want* to be responsible for all the error handling themselves, and VB (and tB for now) never built the special handling required to allow Implements where there's no HRESULT. (It's more complex than you'd think, after talking to Wayne about how it can be implemented-- essentially in tB when this is supported, you'll be forfeiting automatic error handling and will have to both handle internal errors yourself and be responsible for HRESULT codes returned to outside callers). Another issue is all the SDK examples are in C++, and it's tough when you're just learning how to use all these interfaces to re-architect the code you're porting to account for not doing like the SDK and handling errors with SUCCEECED but instead jumping out of the code flow. Struggled with it myself at the beginning; still forget to handle it right sometimes.
VB6 adds to the complications in that if you do leave it as HRESULT, it sometimes messes with the error info. tB has Err.LastHResult to help with this; it guarantees accuracy for the last HRESULT independent from the VB translation of Err.Number.
There's a very strong bias against OERN in the community, but I find myself more and more wanting to just use it for entire methods in oleexp/WDL-heavy calls. Especially when I don't really understand what I'm doing; like my DirectComposition example, every method is OERN so I could follow the SDK as closely as possible.
[EDIT]
Ignore the post below.
The old TLB did not need to be unregistered. I just had to read and follow the upgrade instructions fafalone provided here.
=====
I have an older version of this type lib (v4.2 from 2017) which I'm trying to unregister so that I can register the new one so that I can use your ucShellBrowse control which is my ultimate goal in this. But I'm coming up against the following error when I try to run "regsvr32 /u" on the old version of the TLB:
"The module oleexp.tlb may not be compatible with the version of Windows that you're running. Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe."
I'm on Windows 10, 64 bit. I've tried both the 32 and 64 bit versions of regsvr32. I'm running the Command Line as admin. Nothing works.
I don't normally have issues registering and unregistering files.
Help! Anyone???
Regsvr32 only works with DLL and OCX files. Just overwrite your old oleexp file with the latest version and you're done.
Yeah, I knew that years ago when I regularly worked with TLB files. It's been a while since I've had to update one. Thanks for the refresher!Quote:
Originally Posted by VanGoghGaming
There's some benefits to a TLB that needs to be registered/reregistered properly every upgrade, but I've avoided triggering that requirement just so you never need to worry about registration with oleexp.
Specifically, you know that error you sometimes get with passing UDTs 'Only publicly defined blahblahblah'... well those can be avoided if you associate a GUID with the UDT. But then you can't just overwrite the old typelib or things go off the rails; you have to unregister it, overwrite, and register (albeit not with regsvr32, but a typelib-specific tool).
Project Updated - oleexp v6.6
(oleexp 6.6 - Release 06 June 2024)
-Added Direct3D 9 interfaces(courtesy of The trick for the core interface set
-Added DXVA2 and DXVAHD interfaces
-Added all Background Intelligent Transfer Service interfaces and coclasses
-Large expansion of Direct3D 12 interfaces
-Added Direct3D 12 Video interfaces
-Some misssing Direct3D 11 interfaces
-Added Windows Media Device Manager interfaces and coclasses
-Added DirectML interfaces (directml.h, 100%)
-Added Virtual Disk Service interfaces
-Added UPnP interfaces (upnp.h, upnphost.h, 100%)
-Added INATExternalIPAddressCallback Interface, for use with NATUPnP Type Library v1.0 (NATUPNPLib, included with Windows)
-Added VBA-related interfaces from vbinterf.h (100% coverage)
-(Bug fix) MFMEDIASOURCE_CHARACTERISTICS, MF_SOURCE_READER_FLAG, and MF_SOURCE_READER_CONTROL_FLAG enums all values incorrect.
-(Bug fix) SHCreateStreamOnFileEx was defined in wrong dll.
-(Bug fix) The following UDTs contained unsupported types: LOGPALETTE, NETRESOURCE, OLEUICONVERT, PUBAPPINFO, KSJACK_SINK_INFORMATION, D3D12_META_COMMAND_DESC, D3D12_AUTO_BREADCRUMB_NODE1, D3D12_FEATURE_DATA_PROTECTED_RESOURCE_SESSION_TYPES, D3D12_VIDEO_EXTENSION_COMMAND_PARAMETER_INFO, SPDISPLAYPHRASE, BASEBROWSERDATAXP, BASEBROWSERDATALH, TOOLBARITEM, and DML_ADAM_OPTIMIZER_OPERATOR_DESC.
IMPORTANT: DUE TO ATTACHMENT SIZE LIMITS, THE DOWNLOAD STRUCTURE HAS CHANGED. READ ZIP CONTENTS.
It took several years to make this TLB registration DLL registration tool. Because sometimes there are some TLBs referenced in the system, it is impossible to re-register after changing the path. Activex DLLs require administrator privileges to register, and.net DLLs are often registered successfully on different computers but cannot be used. It's really a headache, so I developed this small tool, and it's better to drag files later. The top function is added, but the pop-up dialog box will run to the back of the window and can not be clicked, all kinds of conflicts. Running under LINUX WINE, I accidentally searched out all the DLLs in the C disk. There are more than tens of thousands of data, and the total number has become negative. Then I can only use the API to locate a certain line and get the current data. But the event of the control cannot be used again. Widgets are also sometimes a lot of work, containing 10-50 technical difficulties.
I can't understand what you're talking about and it seems unrelated to oleexp.
oleexp has lighter registration requirements than OCX controls or some other typelibs because it doesn't use registered types; you can just overwrite old versions with new versions or use a register/unregister tool that calls these simple APIs;
Code:Declare Function LoadTypeLib Lib "oleaut32" _
(ByVal szFileName As Long, _
lplptlib As Any) As Long ' lplptlib As Long
Declare Function RegisterTypeLib Lib "oleaut32" _
(ByVal ptlib As Any, _
ByVal szFullPath As String, _
ByVal szHelpDir As String) As Long
Declare Function UnRegisterTypeLib Lib "oleaut32" _
(GUID As GUID, _
ByVal wVerMajor As Long, _
ByVal wVerMinor As Long, _
ByVal lcid As Long, _
ByVal SYSKIND As SYSKIND) As Long
'or newer x64 compat defs
Public DeclareWide PtrSafe Function RegisterTypeLib Lib "oleaut32" (ByVal ptlib As ITypeLib, ByVal szFullPath As String, Optional ByVal szHelpDir As String) As Long
Public Declare PtrSafe Function UnRegisterTypeLib Lib "oleaut32" (ByRef libID As UUID, ByVal wVerMajor As Integer, ByVal wVerMinor As Integer, ByVal lcid As Long, ByVal SYSKIND As SYSKIND) As Long
Public DeclareWide PtrSafe Function RegisterTypeLibForUser Lib "oleaut32" (ByVal ptlib As ITypeLib, ByVal szFullPath As String, ByVal szHelpDir As String) As Long
Public Declare PtrSafe Function UnRegisterTypeLibForUser Lib "oleaut32" (ByRef libID As UUID, ByVal wVerMajor As Integer, ByVal wVerMinor As Integer, ByVal lcid As Long, ByVal SYSKIND As SYSKIND) As Long
fafalone, just to follow up on this and to clear out any confusion xiaoyao's post may have created. I have "OLEEXP - Modern Shell Interfaces for VB6, v4.7" as oleexp.tlb in SysWow64. So I can just overwrite that one with version 6.6, right?
Yes that's correct.Quote:
Originally Posted by 7edm
There's an issue with doing that for 4.6 or earlier since I inadvertently changed the project GUID in 4.7, but it's been the same ever since so simple overwriting is only a problem for 4.6 and earlier. 4.7 and up are good. You'd only need to use the unregister/register method if you wanted to change the path of newer versions.
Ok, that was interesting/useful information, because when I look in VB6's references dialog I also see OLEEXP - olelib With Modern Interfaces v4.62, but in a local forder outside of system folders. Is this your old version then? I have no clear memory of why I have it there so that's why I ask, but it's not "in use" by any of my projects so can just be deleted then?
Ops, at a closer look I see that the oleexp.tlb file is not even present in that non-system folder anymore, so this is obviously some leftover in the registry. Which leads to the question, is it possible to unregister it without the file present?
EDIT: Found the old zip file so nop with missing file.
It should be possible. So my registration tool is based on this principle, first-register the old version, then un registration, and then register the new version.Quote:
Originally Posted by 7edm
At the earliest time, my tool was only dedicated to t1b registration.Because after the TLB reference, if you move the location of the file, you will fail to re-register. Especially the one with the same name but a different GUID.
The first step is to find the old version, re-register it first, and then uninstall the registration.You can put tlb file in any director.
Then register a new tlb file, which basically requires three steps.
Great, go make your own thread for your tool.
Here's a much simpler one by Brad Martinez (his website is long-since defunct, there were tons of great projects on it).
https://www.vbforums.com/images/ieimages/2024/06/2.jpg
Great! Did the job.
about regtypelib.zip
Does he have a 64-bit version of the source code?
Test whether the 64-bit system can be used.
In the future, if a piece of code can support both 32-bit and 64-bit.
At the same time, it is more convenient to do the attributes of the two platforms.
You can add such a flag attribute to it.
(for x64/x86)
Because Vba and twinbasic need 64 bits.
You are the biggest contributor in the world to the expansion of TLB's various functions.
You use your spare time to complete these free products. Contributed hundreds of thousands of dollars of intellectual power to our CP community.
oleexp.tlb is for 32bit only, it will not work with 64bit tB or VBA.
For 64bit tB, as the first post notes, I have a replacement called 'Windows Development Library for twinBASIC' (WinDevLib). It covers 100% of oleexp.tlb and also has 6000+ of the most common APIs declared.
I am trying to use GetTickCount.
I have referenced OLEEXP - Modern Shell Interfaces for VB6, v6.6 (oldexp.tlb) to my project, thinking that having to declare the function is no longer required.
Yet VB6 does not recognize it and tells "Variable not found". Same as with GetCursorInfo (which I had declared as Private Declare Function GetCursorInfo Lib "user32" (pci As CURSORINFO) As Long)
What am I missing?
Here is my code:
Code:Option Explicit
Private Sub Form_Load()
Dim l&
l = gettickcount
End Sub
"GetTickCount" is not defined in oleexp, in fact many other API functions are missing as well. Some time ago I was looking for a comprehensive TypeLib that would expose a complete set of API functions but in time I came to appreciate the flexibility of your own API declarations since often times the TypeLib declaration is not well suited for your purposes. Still, oleexp is great for its COM interfaces which you cannot declare yourself in VB6 code.
Ok, and how should I handle LOGFONTA?
In oletlbexp.tlb it is declared as
Sub ConvertFontFaceToLOGFONT(Font As IDWriteFontFace, logFont As Any)
Member of oleexp.IDWriteGdiInterop
Currently I have declared it myself like this
Public Declare Function CreateFontIndirect Lib "gdi32" Alias "CreateFontIndirectA" (lpLogFont As LOGFONTA) As Long
I once copied it from somewhere and just used it. Now I have removed the "type LOGFONTA" because I thought it is contained in oletlbexp.tlb anyways, and now I have to back it back it, therefore I would like to ask how you others handle it.
I was so much hoping to be able to get away from having declare such things myself.
Yeah, TypeLibs are definitely not the magic bullet you were hoping for. In this example you would need to declare the LOGFONT structure yourself before using it as a parameter in the function call. I would go for the LOGFONTW structure though since it's Unicode compatible.
You could use the Object Browser (press F2 in IDE) to check whether a certain function, type, constant or enum is already declared in oleexp or not.
If you all moved on to twinBASIC, oleexp's successor, WinDevLib, that does have the extremely expansive API coverage you're looking for. :D 6,000+ APIs, 5,600+ UDTs and 5,400+ enums for them in addition to all the interfaces covered by oleexp. And you can of course override them with a local declare if you want a different prototype, though tB supports overloads so I've added many of the most popular alternates.
But you can pass a locally defined UDT to an interface expecting it via As Any or LongPtr in VB6/oleexp.
Thank you!
Can I create PWA (progressive web apps) with TB?
Can a standard Win32 exe or DLL act as a progressive web app?
If it can than yes, since if you really want to you can drop down to writing your own entry point if need be. But it would probably not be worth the hassle.
When you have a little free time could you take a look at the ARRAYDESC structure as it seems the MSDN definition is different from the one in oleexp? I've ran into this issue when doing some pro-bono work for xiaoyao! The structure still works as it is but it's incomplete and some features are unavailable...
Wow! Working for xiao... how's that working out? Maybe you could become his unofficial translator
:)
Good luck to you both in your new endeavour.
The last element is a variable C-style array; VB6 doesn't support them (nor does tB for now). It says 1, but that's a placeholder, there will be cDims elements to rgbounds.
There's generally 3 options;
1) Use everything up to the array as just a header,
2) Take a guess at the highest number ever needed and use that, or
3) If it's for receiving data from outside sources only, substitute a SAFEARRAY, where you first copy the static part, determine the needed number of elements, redim, then copy the remaining data to arr(0).
The choice to use 1 here goes back to olelib; I generally prefer 2. (It's apparently missing from WinDevLib, next version will use 2 with it buffered to 16). But never saw a compelling reason to break compatibility.
Yeah, number 2) looks like the preferred choice but from my testing there seems to be something wrong with cDims as well (it was populated with a random integer in the thousands and sometimes negative too)... The only member that works as expected is the first one, tdescElem.
LoL, chuckled prolly more than I should have at this one! Actually the only reason I engaged was he seemed genuinely interested in the thread and made an effort to sound quite intelligible for once. Hope he keeps it up.Quote:
Originally Posted by yereverluvinuncleber
It's all correct... if you're coping things around from memory pointers, are you accounting for the hidden padding? There's two hidden padding bytes at the end of TYPEDESC, and if you're working with ARRAYDESC, there's two padding bytes after cDims before rgbounds starts.Code:typedef unsigned short VARTYPE;
typedef struct tagTYPEDESC
{
/* [switch_is][switch_type] */ union
{
/* [case()] */ struct tagTYPEDESC *lptdesc;
/* [case()] */ struct tagARRAYDESC *lpadesc;
/* [case()] */ HREFTYPE hreftype;
/* [default] */ /* Empty union arm */
} DUMMYUNIONNAME;
VARTYPE vt;
} TYPEDESC;
typedef struct TYPEDESC {
LONG pTypeDesc;
short vt;
} TYPEDESC;
typedef struct tagARRAYDESC
{
TYPEDESC tdescElem;
USHORT cDims;
/* [size_is] */ SAFEARRAYBOUND rgbounds[ 1 ];
} ARRAYDESC;
typedef struct ARRAYDESC {
TYPEDESC tdescElem;
short cDims;
} ARRAYDESC;
...
I try to help xiaoyao too but even when I go out of my way to translate 'We can't understand you, please use a different translator." into Chinese to get the point across, he just ignores it and continues unintelligibly most of the time.
I'm not copying anything around from pointers, I let VB6 do the dirty work automatically behind the scene since that's far less error-prone:
This code is for determining the types of function parameters at runtime using "ITypeInfo.GetFuncDesc". So far everything checked out spot-on (it even retrieves the default values of optional parameters when specified). Only the cDims member of ARRAYDESC failed so far but maybe the data wasn't there to begin with. I mean IntelliSense doesn't show array dimensions on array parameters so maybe cDims really is undefined (and they didn't zero-out the memory before allocating the pointer). Sample output at runtime:Code:Private Property Get GetArrayDesc(tArrayDesc As oleexp.ARRAYDESC, ByVal pArrayDesc As Long) As oleexp.ARRAYDESC
If pArrayDesc Then PutMem4 ByVal VarPtr(pArrayDesc) - 4, pArrayDesc: GetArrayDesc = tArrayDesc
End Property
Private Property Get GetFuncDesc(tFuncDesc As oleexp.FUNCDESC, ByVal pFuncDesc As Long) As oleexp.FUNCDESC
If pFuncDesc Then PutMem4 ByVal VarPtr(pFuncDesc) - 4, pFuncDesc: GetFuncDesc = tFuncDesc
End Property
Private Property Get GetTypeDesc(tTypeDesc As oleexp.TYPEDESC, ByVal pTypeDesc As Long) As oleexp.TYPEDESC
If pTypeDesc Then PutMem4 ByVal VarPtr(pTypeDesc) - 4, pTypeDesc: GetTypeDesc = tTypeDesc
End Property
Quote:
Function ShowMsgBox(sMessage As String, [bCancel As Boolean], [ByVal vTestParameter As Variant = "Test Optional Variant Parameter Default Value"]) As Currency()
PutMem4 is copying around from pointers... I'm not following why you're using -4
It's a trick I've picked up from The Trick (amazingly enough). It copies the second parameter (which is a pointer) over the address of the first parameter which is at offset -4 bytes on the stack. Both parameters are on the stack (4 bytes each), the first one is the address of an UDT (that is declared outside the function). The second parameter must be declared "ByVal" so that VarPtr reports the address on the stack. After the operation, the UDT will no longer point to its original declaration but will reference the new pointer instead. This doesn't affect the UDT variable declared outside the function at all (that's just a placeholder).
Therefore it effectively allows read-write access to the pointer by means of an UDT (without copying the contents back and forth). Well in this case the UDT is copied via assignment to the return value of the Property Get. I'm pretty bad at explaining, haha.
I guess it's an equivalent to the new type-cast feature introduced in TwinBasic. ;)
Is there something wrong with the definition of "SHCreateMemStream" from oleexp?
Code:Private Declare Function SHCreateMemStream Lib "shlwapi" (pInit As Any, ByVal cbInit As Long) As oleexp.IStream
Private Sub Form_Load()
Dim pStm As oleexp.IStream
Set pStm = oleexp.SHCreateMemStream(ByVal 0&, 0) ' Compile error: Type mismatch
Set pStm = SHCreateMemStream(ByVal 0&, 0) ' Okay
End Sub
Yes it should just be IStream* instead of IStream**. Will be fixed in the next release.
Congrats, you also helped find a bug in twinBASIC because I tested it there too and there was no type mismatch, meaning it ignored the error.
Looks like it's been only one and a half years since I asked for "SHCreateMemStream" to be included in oleexp so it's only fitting that I am the one to discover this bug! :DQuote:
Originally Posted by fafalone
On the bright side TB still doesn't support exporting TLBs but at least it has Naked functions now! ;)
Yeah unfortunately there;s been considerable delays, but adding features to support VB6 itself not involving running VB6 projects in tB is obviously a very low priority; I've definitely voted myself for asm support being a v1 target unlike tlbs... Naked functions and Emit took Wayne 2 days to add, so that's not to blame anyway.
If you want WinDevLib's expansive API support, use twinBASIC :)
Last month I did add a number of overloads for oleexp compatibility once tB supported rewritinng API defs to make the last [out] a return ([PreserveSig(False)] attribute now applying to API declares). And interface sig changes for compat with oleexp and The trick;s typelibs. To make the transition even easier.
I noticed that even though I deleted a variable named "y" in code, it would still compile.
Then I noticed that "y" is declared as a constant in oleexp.
This was not intended, right?
Attachment 193716
It's not intended; I'll remove it in the next release, thanks for letting me know.
I don't understand. Why are you talking about me? I haven't left a message on this subject for a long time. I think the type Kuti currency file has two versions of 64 bit and 32 bit.
It would be even better if there was a way to extract parts of the TLB for different needs.
Because a 5mb TLB is not very convenient to carry after all.
Sometimes Excel, 64-bit and 32-bit, needs a small amount of functions.
The TLB needs to be registered successfully before it can be referenced in Excel.
Pecially the TLB files generated by the VB net DLL. Do not know whether it can be used without importing the registry?
Nobody has mentioned you here in months, there's still no 64bit oleexp (and there probably won't be), and it's silly complaining about a few mb when every else requires hundreds of MB if not GB of SDKs, frameworks, or libraries. It's an open source project if you want to just use some small part, the source is there.
It would be nice if twinbasic supported automatically extracting a function or module from a project.
For example, the Enterprise Control has a total of 30 files. If I only need a text box control for Unicode.Redundant modules and lines of code are automatically removed.
Is a function or a module that depends on which APIs declare DLLs or other functions.
If you need to compile some of the TLB types separately. It is not known which dependencies he used. Maybe ai can handle it automatically in the future.
Is the current chatGPT, it can not directly import hundreds of kb or even several megabytes of source code, and then it automatically clean up the redundant code.
This thread is about oleexp.tlb, not twinBASIC features.
I do use TwinBasic if I "have to", I am subscriber, but its editor (the one I currently use is from Dec 2024) is a real pain to use unfortunately. It behaves like the .NET editor. It is just slow and does nasty things.
I will fully switch to TwinBasic fully once I can work with it as fast as in VB6.
There were some IDE performance issues after the first releases in December that were fixed in recent builds; but other than that not sure what you mean... nasty things? Personally I love all the modern features the VB6 IDE lacks. I work a lot faster with things like regions, code folding, advanced info popup, global search that displays all results at a glance, all the issues detected before running you can jump to with a click, the IDE not throwing up a message box on every syntax error, etc. It's a little bit of an adjustment but well worth it.
If something you're working on is causing the IDE to be slow, please file a bug report.
Don't complain in general, raise specific issues on github here, https://github.com/twinbasic/twinbasic/issues. My experience is that many of our suggestions or bugs raised are being definitely being addressed. There is no chance your voice will be heard if you just moan that the IDE is a real pain. I've raised several so far, feel free to raise your own.Quote:
Originally Posted by tmighty2
Why hasn't Wayne released the official version yet? It means that it is constantly adding new features to make it more compatible with VB6. It is like a child of all of us. If everyone could contribute to the cost, the development would be faster and Wayne would have enough money to recruit new employees.Without increasing the volume of the program as much as possible. Make up for some of the most important shortcomings of returning to B6. Become a more advanced and convenient programming language, which can be used in 51 or newer computer systems. Currently, his program is only 30 megabits. Maybe version 2, version 3, it will go up to 300 megabytes, two gigabytes.
It's a little off topic. But I hope you can know more people. In the past, the administrator of this forum liked to delete all the topics about special qualifications and transfer them to the corner where no one saw them at all.Now we should all think of it as a VB6 IDE. Upgrade version.
As someone said a few days ago, it is too difficult to add some new sections in this forum. Maybe this forum will go bankrupt in two years.With the rapid development of the Internet and AI, it is more and more difficult for traditional websites to make money, and it is only a matter of time before they are closed. It is possible that all the source code will be lost directly, and he will not copy it to us.
It is VERY off topic.
Hi! I guess you have forgotten to remove "y" from oleexp.SIOI_Flags.Quote:
Originally Posted by tmighty2
It's still present in oleexp66-core.zip.
Edit: Hmm, I guess I misunderstood something in the versioning as I just noticed that oleexpimp.tlb's last edit date was 2024-06-07 in the oleexp66-core.zip.
Edit2: Sorry, I completed confused the edit year 2024 with 2025.
Edit3: In your first post you state that people requiring an update due to a bug should not compile their own version but instead contact you. May I ask you if you could update oleexpimp.tlb?
I believe I am struggeling with a math problem where your "y" (which is 0) is being used, but I don't find the exact spot without having an updated oleexpimp.tlb.
It's in "\source\exp_security.odl"
SI_NO_TREE_APP,Y = 0x00000400,
Thank you very much.
Your edits are right .. 6.6 is from June 2024, no updates since. I'll post 6.7 this week... But the y in the typelib would only be used if you don't have y declared in your own code. In the screenshot you posted, should you maybe be using the uTop variable in the arguments instead of y?
If not, Dim y As Long: y = (correct value) will override the typelib in that method. Or Public y As Long in a .bas to override project-wide.
As it stands right now, an updated tlb without y but no code changes would change nothing without Option Explicit, or with it result in an undefined variable error. That's why I hadn't been considering it a high enough priority for an unplanned update. But still, there's a number of other pending additions and fixes so I'll still aim for this week.
webview2 ICoreWebView2 is nothing
why use LongPtr??
CreateCoreWebView2EnvironmentWithOptions(browserExecutableFolder As LongPtr, UserDataFolder As LongPtr, environmentOptions As ICoreWebView2EnvironmentOptions, environmentCreatedHandler As ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler) As Long
Implements oleexp.ICoreWebView2CreateCoreWebView2ControllerCompletedHandler
Private Sub ICoreWebView2CreateCoreWebView2ControllerCompletedHandler_Invoke(ByVal errorCode As Long, ByVal createdController As oleexp.ICoreWebView2Controller)
dim Web As oleexp.ICoreWebView2
Set Web = createdController.CoreWebView2
'it's error
If Web Is Nothing Then???
Private Sub ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler_Invoke(ByVal errorCode As Long, ByVal createdEnvironment As oleexp.ICoreWebView2Environment)
Set Ob_ControllerCompletedHandler = New WebViewLib
createdEnvironment.CreateCoreWebView2Controller ParentWindow, Ob_ControllerCompletedHandler
'it's ok
End Sub
maybe lost get_Bounds method?
Code:[propget]
HRESULT _stdcall get_Bounds(
[out, retval] long boundsLeft,
[out, retval] long boundsTop,
[out, retval] long boundsRight,
[out, retval] long boundsBottom);
[propput]
HRESULT _stdcall put_Bounds(
[in] long boundsLeft,
[in] long boundsTop,
[in] long boundsRight,
[in] long boundsBottom);
Ah right I forgot.
There's a bug in MKTYPLIB. The property get is present in the source, but it's dropped when compiling. Some weird bug where you can't have a method with "get" in the name if it's a propget.
I actually fixed that and some other bugs but I wanted to finish some other things... I don't know when I'll officially release 6.7 but here's a patched version of 6.6 with the bug fixes I've done so far:
The naming restrictions were *insane*... I tried everything reasonable but now they're no longer Property Get/Let, they're separateCode:-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
Code:HRESULT pgtBounds([out] RECT* bounds);
HRESULT pptBounds([in] LONG boundsLeft, [in] LONG boundsTop, [in] LONG boundsRight, [in] LONG boundsBottom);
(attachment removed; fixes incorporated into v6.7, now released)
Maybe you need to write a tool to automatically detect if the number of interfaces is missing?Or even if the data type has been changed?
WebView2 Win32 C++ ICoreWebView2 | Microsoft LearnQuote:
Originally Posted by fafalone
https://learn.microsoft.com/en-us/mi..._documenttitle
The title for the current top-level document.
public HRESULT get_DocumentTitle(LPWSTR * title)
If the document has no explicit title or is otherwise empty, a default that may or may not match the URI of the document is used.
The caller must free the returned string with CoTaskMemFree. See API Conventions.
CAN RESULT IS A vb6 STRING?
your tlb return a long type "DocumentTitle"
Code:HRESULT GetDocumentTitle(ICoreWebView2* webView, std::wstring& title) {
if (!webView) {
return E_INVALIDARG;
}
LPWSTR titlePtr = nullptr;
HRESULT hr = webView->get_DocumentTitle(&titlePtr);
if (SUCCEEDED(hr) && titlePtr) {
title = titlePtr;
CoTaskMemFree(titlePtr);
}
return hr;
Code:Private Declare Function lstrcpyW Lib "kernel32" (ByRef Buffer As Any, ByVal Bstr_address As Long) As Long
Private Declare Function lstrlenW Lib "kernel32" (ByVal lpData As Long) As Long
Public Function StrFormPtr(lPtr As Long) As String
Dim Buff() As Byte, Len1 As Long '????Byte??
Len1 = lstrlenW(lPtr) * 2
ReDim Buff(0 To Len1 - 1) As Byte '??????,??????Unicode?????2
lstrcpyW Buff(0), lPtr '?????Buff?
StrFormPtr = Buff()
'lstrcpyW VarPtr(Buff(0)), ByVal lPtr '?????Buff?
End Function
Code:Private Declare Function lstrcpyW_Long Lib "kernel32" Alias "lstrcpyW" (ByVal lpString1 As Long, ByVal lpString2 As Long) As Long
Public Function StrFormPtr2(ByVal lPtr As Long) As String
StrFormPtr2 = String(lstrlenW(lPtr), " ")
lstrcpyW_Long StrPtr(StrFormPtr2), lPtr '?????Buff?
End Function
i do clear string by lptr,why also can read string from this address?
maybe need fill memory with 0?
Which IDL or ODL files are dedicated to WEBVIEW2? Can it be made into an independent TLB?Code:Private Declare Function SysReAllocString Lib "oleaut32.dll" (ByVal pBSTR As Long, Optional ByVal pszStrPtr As Long) As Long
Private Declare Sub CoTaskMemFree Lib "ole32.dll" (ByVal hMem As Long)
Function LPWSTRtoStr(lPtr As LongPtr, Optional ByVal fFree As Boolean = True) As String
SysReAllocString VarPtr(LPWSTRtoStr), lPtr
If fFree Then
Call CoTaskMemFree(lPtr)
End If
End Function
What development environment does compiler need to install? vc++2017? Still VC++6.0, MIDL.EXE?
The function or interface is marked as restricted, or the function uses an automatic type that is not supported in Visual Basic
maybe error by "BOOL"??
ICoreWebView2_21.ExecuteScriptWithResult Js, me
Code:Private Sub ICoreWebView2ExecuteScriptWithResultCompletedHandler_Invoke(ByVal errorCode As Long, ByVal result As oleexp.ICoreWebView2ExecuteScriptResult)
ICoreWebView2ExecuteScriptResult (MEMbers:)
Property Succeeded As BOOL
Sub TryGetResultAsString(stringResult As LongPtr, Value As BOOL)
you can add new interface?
so i can call by vtable:call com by index:ICoreWebView2ExecuteScriptResultACode:interface ICoreWebView2ExecuteScriptWithResultCompletedHandler_Long
Private Sub ICoreWebView2ExecuteScriptWithResultCompletedHandler_Long_Invoke(ByVal errorCode As Long, ByVal ICoreWebView2ExecuteScriptResultA AS Long)
oleview.exe open your oleexp.tlb:
ICoreWebView2_21 IS FROM ICoreWebView2_20
ICoreWebView2_20 IS FROM ICoreWebView2_19
I DON'T KHNOW WHICH CLASS
There are 20 classes nested layer by layer, with inheritance relationships. I don't know which class, interface, or method has parameter types that are incompatible with VB6. I wonder if there are any tools that can enumerate and detect specific parameter types?
edit by idl or odl format:
muse use same uuid? or can use any uuid?
if we have 10 Handler objects?
something is 2 argmemuent count? something 3 args,4args?
we can only use 3 Handler ?
arg2Handler(byval a as long ,byval b as lon)
arg3Handler(byval a as long,byval b as long,byval c as long)
?
ICoreWebView2ExecuteScriptWithResultCompletedHandler
Code:[
odl,
uuid(1BB5317B-8238-4C67-A7FF-BAF6558F289D)
]
interface ICoreWebView2ExecuteScriptWithResultCompletedHandler : IUnknown {
HRESULT _stdcall Invoke(
[in] HRESULT errorCode,
[in] ICoreWebView2ExecuteScriptResult* result);
};
ICoreWebView2ExecuteScriptResult
Code:[
odl,
uuid(0CE15963-3698-4DF7-9399-71ED6CDD8C9F)
]
interface ICoreWebView2ExecuteScriptResult : IUnknown {
[propget]
HRESULT _stdcall Succeeded([out, retval] BOOL* Value);
[propget]
HRESULT _stdcall ResultAsJson([out, retval] LongPtr* jsonResult);
HRESULT _stdcall TryGetResultAsString(
[out] LongPtr* stringResult,
[out] BOOL* Value);
[propget]
HRESULT _stdcall Exception([out, retval] ICoreWebView2ScriptException** Exception);
};
Attachment 194303Code:ICoreWebView2ScriptException
[
odl,
uuid(0CE15963-3698-4DF7-9399-71ED6CDD8C9F)
]
interface ICoreWebView2ExecuteScriptResult : IUnknown {
[propget]
HRESULT _stdcall Succeeded([out, retval] BOOL* Value);
[propget]
HRESULT _stdcall ResultAsJson([out, retval] LongPtr* jsonResult);
HRESULT _stdcall TryGetResultAsString(
[out] LongPtr* stringResult,
[out] BOOL* Value);
[propget]
HRESULT _stdcall Exception([out, retval] ICoreWebView2ScriptException** Exception);
};
Webview2.Navigate strptr("https://www.bing.com") webView->get_DocumentTitle(&titlePtr);
str=webView.sources
dim js as.string
webview.executescript(js,callback)
Can you convert these parameters and return values directly into ordinary string types on tlb,idl?
thanks