Ahh, I see. Implements by other native interfaces.
Yes, after that fix, program is stable. I edited my exampe.
Printable View
Ahh, I see. Implements by other native interfaces.
Yes, after that fix, program is stable. I edited my exampe.
Just if somebody will expect the same issue:
I wrote a little parser that modify your all 676 Static in mIID.bas to module-level variable:Quote:
Compile error:
Fixed or static data can't be larger than 64K"
+ you need add in top something like:Code:Option Explicit
Private Sub Form_Load()
Dim ff As Integer
Dim ff2 As Integer
Dim sz As Long, n&
Dim s$, r$
ff = FreeFile()
n = 0
Open "iid.txt" For Input As #ff
ff2 = FreeFile()
Open "iid_2.txt" For Output As #ff2
Do While Not EOF(ff)
s = String(sz, 0)
Line Input #ff, s
If InStr(s, "Static iid As UUID") <> 0 Then
n = n + 1
ElseIf InStr(s, " = iid") <> 0 Then
s = Replace(s, " = iid", " = iid(" & n & ")")
Print #ff2, s
ElseIf InStr(s, "If (iid.Data1 = 0") <> 0 Then
s = Replace(s, "iid.", "iid(" & n & ").")
s = Replace(s, "iid,", "iid(" & n & "),")
Print #ff2, s
Else
Print #ff2, s
End If
Loop
Close #ff2
Close #ff
End Sub
Code:Private iid(700) As UUID
Have you found a way to reliably reproduce the error? Would love to take a look into it, but still haven't encountered it even in my largest projects that use upwards of 100 mIID refs.
Edit: btw, does this occur in the IDE, when compiled, or both?
This error bored me already enough. That's why at last I decided to replace those "Static".
No way to reproduce it reliably.
It just happen. Depens on what I do, how many run/stop e.t.c., I think.
The only I know, it never happen on first run after starting the project.
I think that somewhere in runtime this counter of 'Static' accumulates for some reason.
LOL dude I think you cursed me. Never gotten that error before but tonight it just hit me. In an existing project that hadn't had any code related to static variables touched. It occured after some other errors caused an API call to behave erratically; continuing just made the triggering line change. Restarted the IDE and haven't seen it again since. Running/quitting over and over again hasn't reproduced it. Do you run MZ-Tools or CodeSMART by chance? CodeSMART frequently produces odd errors like this.
ahah. Epidemic =))
No, currently the only plugin I'm using it's a mouse wheel fix + patched manifest and icon resource for VB.exe + linker v14.14.
Hello,
I am using a MS Access database to manage my projects at work. On a form I use a WebBrowser Control to show the content of the selected project folder, which is stored on a local network drive. It just provides Explorer functionality. My OS was recently upddated to windows 10 with the result that a warning window pops up, each time I want to open or right-click a file in the webcontrol. In the past that was fixed by reducing the security settings for the "local intranet" zone, but it seems like this is not possible any more. Thus I searched for an alternative for this control and found this project.
Unfortunately I have no idea how to place an Explorer like control onto a form using VBA / MS Access. The samples above are for VB6 only.
It would be great if you could give me a hint. My programming skills are not very high, but with google's help I can write some VBA to get things done.
Greetings
Jörg
Attachment 161067
The best option would be to use IExplorerBrowser which lets you put a frame of Explorer nearly identical to your pic on the form.
See [VB6, Vista+] Host Windows Explorer on your form: navigation tree and/or folder
You can use this object in VBA with just the normal adjustments, and I'd recommend forgoing the event sink. I tested this in Excel 2013 64-bit, and it ran fine.
This creates an ExplorerBrowser open to C:\Windows inside a frame (Frame1) on a VBA UserForm:
To change directories again manually, in another sub, you just need the ILCreateFromPathW and pEBrowse.BrowseToIDList functions again; you don't need to re-initialize the whole thing.Code:Option Explicit
Private pEBrowse As oleexp.ExplorerBrowser
Private pidlt As Long
Private lpck As Long
Private Declare PtrSafe Function ILCreateFromPathW Lib "shell32" (ByVal pwszPath As LongPtr) As Long
Private Declare PtrSafe Function GetClientRect Lib "user32" (ByVal hWnd As Long, lpRect As oleexp.RECT) As Long
Private Declare PtrSafe Sub CoTaskMemFree Lib "ole32" (ByVal pv As Long)
Private Sub UserForm_Activate()
Dim prc As oleexp.RECT
Dim rcf As oleexp.RECT
Dim pfs As FOLDERSETTINGS
Dim sPath As String
Dim lFlag As oleexp.EXPLORER_BROWSER_OPTIONS
sPath = "C:\Windows"
pidlt = ILCreateFromPathW(StrPtr(sPath))
pfs.fFlags = FWF_ALIGNLEFT
pfs.ViewMode = FVM_DETAILS
prc.Top = 18
GetClientRect Me.Frame1.[_GethWnd], rcf
prc.Bottom = rcf.Bottom - 8
prc.Left = 4
prc.Right = rcf.Right - 8
Set pEBrowse = New ExplorerBrowser
pEBrowse.Initialize Me.Frame1.[_GethWnd], prc, pfs
pEBrowse.SetOptions lFlag
pEBrowse.BrowseToIDList pidlt, 0 'if you want to use the desktop, for its own sake, or want a quick substitute
'for not having C:\ , instead of pidlt use VarPtr(0) -NOT just 0.
CoTaskMemFree pidlt
End Sub
Thanks a lot for your support!
One (maybe) stupid question: I created an empty form and added a Microsoft Forms 2.0 ActiveX Frame object and named it Frame1.
Unfortunately I get an error message that the object cannot be found (GetClientRect Me.frame1.[_GethWnd], rcf).
What am I doing wrong?
Regards
Jörg
Next attempt was to try it in Excel (I use office365): I created a user form, placed a frame on it (this control should be the same as the control I used in Access, but in Access I did not have a frame inside the frame.
This time Excel stops working, when the line "pEBrowse.BrowseToIDList pidlt, 0" is executed.
Regards
Jörg
For the frame, when you click on it the name should be there in the properties window. And the code is in the UserForm right, so the 'Me' is valid?
For the error, try putting an error handler in the sub to see what's going on, and a check to make sure pidlt isn't 0. And talking about when you run the form right.. it crashed a couple times on me when I wrote on that line.
to add:
Code:Private Sub UserForm_Activate()
On Error GoTo e0
'(...)
pidlt = ILCreateFromPathW(StrPtr(sPath))
If pidlt = 0& Then
Debug.Print "Couldn't get pidl"
Exit Sub
End If
'(...)
Exit Sub
e0:
Debug.Print "Error->" & Err.Description & ", " & Err.Number
End Sub
Edit: I noticed in Access 2013 there's no option to add a form in VBA... is that the case in 365? Were you trying to put it in a frame like in the table? Then yeah the 'Me' wouldn't be valid and you'd have to change it to whatever object held the frame.
That did not help, as I do not get an Error when trying it in Excel. The app just crashes.
Attachment 161121
Attachment 161123
Hm and you're sure it's on the .BrowseToIDList line, not the .Initialize line or on CoTaskMemFree?
Could try an alternate method... like check to see if we can navigate to an IShellFolder instead...
Then change the navigate command...Code:Private Declare PtrSafe Function SHGetDesktopFolder Lib "shell32" (ppshf As IShellFolder) As Long
Should open the desktop. Try removing the CoTaskMemFree call and the pidlt create / check block too in case it's that line and a memory issue.Code:'pEBrowse.BrowseToIDList pidlt, 0 'if you want to use the desktop, for its own sake, or want a quick substitute
'for not having C:\ , instead of pidlt use VarPtr(0) -NOT just 0.
Dim psf As IShellFolder
SHGetDesktopFolder psf
pEBrowse.BrowseToObject psf, SBSP_DEFMODE
With IShellFolder it worked without crashing.
I had to comment out the CoTaskMemFree line as you proposed, even with IShellFolder method.
Yeah it's not needed since pidlt isn't being used anymore. So if that's the problem, and IShellFolder works, IShellItem should work too, and it's a lot easier to use non-desktop paths without dealing with pidls.
So to go back to any sPath value, try IShellItem instead...
Then instead of Dim psf... BrowseToObject psf...Code:Private Declare PtrSafe Function SHCreateItemFromParsingName Lib "shell32" (ByVal pszPath As LongPtr, ByVal pbc As Long, riid As UUID, ppv As Any) As Long
it's
Hoppefully that should work as well as IShellFolder. It's finicky for me too; SHCreateItemFromParsingName crashed with the standard declare, had to switch the 2nd param from IBindCtx to Long-- make sure you copy that version of the declare from this post, because it's defined the other way in the TLB and that will crash.Code:Dim tiid As UUID
'IID_IShellItem={43826d1e-e718-42ee-bc55-a1e261c37bfe}
tiid.Data1 = &H43826D1E: tiid.Data2 = CInt(&HE718): tiid.Data3 = CInt(&H42EE): tiid.Data4(0) = &HBC: tiid.Data4(1) = &H55: tiid.Data4(2) = &HA1: tiid.Data4(3) = &HE2: tiid.Data4(4) = &H61: tiid.Data4(5) = &HC3: tiid.Data4(6) = &H7B: tiid.Data4(7) = &HFE
Dim psi As IShellItem
SHCreateItemFromParsingName StrPtr(sPath), 0&, tiid, psi
pEBrowse.BrowseToObject psi, SBSP_DEFMODE
This also worked fine. The next question would be how to get the same thing done in Access. There is also a frame control in Access, but is seems to be different to the frame object in Excel.
"GetClientRect Me.Frame1.[_GethWnd], rcf"
results in:
"Error->Object doesn't support this property or method, 438"
This also worked fine. The next question would be how to get the same thing done in Access. There is also a frame control in Access, but is seems to be different to the frame object in Excel.
"GetClientRect Me.Frame1.[_GethWnd], rcf"
results in:
"Error->Object doesn't support this property or method, 438"
I found a similar task here: http://www.access-im-unternehmen.de/1096 but it is in German.
The combination of their solution to get the hwnd of the Detail area of the Access form and your method to navigate to the path seems to be a solution for my problem:
Code:Option Compare Database
Private Const GW_CHILD As Long = 5
Private Const GW_HWNDNEXT As Long = 2
Private oExplBrowser As oleexp.ExplorerBrowser
Private hwndDetail As Long
Private Declare PtrSafe Function GetClassName Lib "user32.dll" Alias "GetClassNameA" (ByVal hWnd As Long, _
ByVal lpClassName As String, ByVal nMaxCount As Long) As Long
Private Declare PtrSafe Function GetWindow Lib "user32.dll" (ByVal hWnd As Long, ByVal wCmd As Long) As Long
Private Declare PtrSafe Function SHCreateItemFromParsingName Lib "shell32" (ByVal pszPath As LongPtr, ByVal pbc As Long, riid As UUID, ppv As Any) As Long
Private Function GetDetailHwnd() As Long
Dim hWnd As Long
Dim ret As Long
Dim rct As RECT
Dim sClass As String
hWnd = GetWindow(Me.hWnd, GW_CHILD)
Do
sClass = String(255, 0)
ret = GetClassName(hWnd, sClass, 255)
sClass = Left(sClass, ret)
hWnd = GetWindow(hWnd, GW_HWNDNEXT)
Loop Until sClass = "OFormSub"
GetDetailHwnd = hWnd
End Function
Private Sub Form_Load()
Dim rct As oleexp.RECT
Dim pfs As oleexp.FOLDERSETTINGS
pfs.fFlags = FWF_ALIGNLEFT 'Or FWF_NOWEBVIEW
pfs.ViewMode = FVM_DETAILS
rct.Bottom = Me.Section(acDetail).Height \ 15
rct.Right = Me.InsideWidth \ 15
Set oExplBrowser = New oleexp.ExplorerBrowser
oExplBrowser.Initialize GetDetailHwnd, rct, pfs
'oExplBrowser.SetOptions EBO_SHOWFRAMES
sPath = "C:\"
Dim tiid As UUID
tiid.Data1 = &H43826D1E: tiid.Data2 = CInt(&HE718): tiid.Data3 = CInt(&H42EE): tiid.Data4(0) = &HBC: tiid.Data4(1) = &H55: tiid.Data4(2) = &HA1: tiid.Data4(3) = &HE2: tiid.Data4(4) = &H61: tiid.Data4(5) = &HC3: tiid.Data4(6) = &H7B: tiid.Data4(7) = &HFE
Dim psi As IShellItem
SHCreateItemFromParsingName StrPtr(sPath), 0&, tiid, psi
oExplBrowser.BrowseToObject psi, SBSP_DEFMODE
End Sub
Private Sub Form_Unload(Cancel As Integer)
oExplBrowser.Destroy
End Sub
Yeah you can draw it on any container hWnd, it doesn't have to be a frame. You could even just put it right on the form (the RECT doesn't have to fill the whole thing) since in Access there seems to be a Form.hWnd property.
And hey that article actually uses my typelib :D Cool stuff :afrog:
Edit: And btw if you wanted to display a custom file list instead of a folder, or customize the columns that are shown, I recently posted this project.
Thank a lot for your great support!
You're welcome, any other issues pop up don't hesitate to ask. :thumb:
I am wondering how to read out the actual path of the explorer. Is there an easy solution?
First post, new to this forum, have been using oleexp for a couple of months. Thank you, it is great that people are still putting all this effort into VB6.
My interest is audio (and VB6)
oleexp has finally given me full access to CoreAudio Device Topology, thank you.
Yesterday I was evaluating AudioCapture but had compile error issues with IAudioClient.GetMixformat. I have just found your latest tlb version and this now works.
I am curious, why do we have to use a Long and then memorycopy into a WaveFormatX type? I do not understand why WaveFormatX is not a valid VB data type, especially as it works ok with IAudioClient.Initialize ?????
Sorry to bother you!!!! I think can answer my own question.
WaveformatX is ok as a "read" or input parameter, but CoreAudio can NOT write into a supplied WaveFormatX. I think it creates its own WaveFormatX and so can only return the address of that WaveFormatX, hence the need to a memorycopy into a local WaveFormatX type.
I'll have to adjust it for VBA later but in the mean time here's the VB6 code
Edit: You can also use the event sink (see the original explorer browser demo I posted) which has events for OnNavigationPending and OnNavigationComplete, so you'd get a pidl for each new location as it happened which can be readily turned into a path with SHGetPathFromIDListW. But I'm not sure how well or even if it would work in VBA.Code:Dim pfv As IFolderView
Dim lp As Long
Dim sPath As String, lpPath As Long
Dim pFol As IShellItem
pEBrowse.GetCurrentView IID_IFolderView, pfv
pfv.GetFolder IID_IShellItem, lp
vbaObjSetAddRef pFol, lp
If (pFol Is Nothing) = False Then
pFol.GetDisplayName SIGDN_DESKTOPABSOLUTEPARSING, lpPath
sPath = LPWSTRtoStr(lpPath)
Debug.Print sPath
End If
WAVEFORMATEX is itself a valid VB data type, but that particular method returns a pointer to a pointer. VB doesn't support passing a user-defined type in that manner. Initialize is just a regular pointer instead of a pointer-to-pointer. That was fixed in the most recent version, along with a few others (including other audio interfaces). Other languages do support passing UDT/arrays in that manner though, which is why the original definition (and oleexp until the issue was discovered) was set up differently.
Single * vs. Double ** pointer.Code:HRESULT GetMixFormat(
WAVEFORMATEX **ppDeviceFormat
);
HRESULT Initialize(
...
const WAVEFORMATEX *pFormat,
I receive errors for "IID_IFolderView", "vbaObjSetAddRef" and "LPWSTRtoStr"Quote:
I'll have to adjust it for VBA later but in the mean time here's the VB6 code
Greetings
They were all defined in the original IExplorerBrowser demo; the IIDs in mIID.bas from the oleexp download... in any case here they all are again:
It's just some of those might be a little iffy converting to VBA so I was going to rewrite it a bit... should have time tomorrow but there's the defs if you want to have a go at it.Code:Public Declare Function SysReAllocString Lib "oleaut32.dll" (ByVal pBSTR As Long, Optional ByVal pszStrPtr As Long) As Long
Public Declare Function vbaObjSetAddRef Lib "msvbvm60.dll" Alias "__vbaObjSetAddref" (ByRef objDest As Object, ByVal pObject As Long) As Long
Public Function LPWSTRtoStr(lPtr As Long, Optional ByVal fFree As Boolean = True) As String
SysReAllocString VarPtr(LPWSTRtoStr), lPtr
If fFree Then
Call CoTaskMemFree(lPtr)
End If
End Function
Public Function IID_IShellItem() As UUID
Static iid As UUID
If (iid.Data1 = 0) Then Call DEFINE_UUID(iid, &H43826D1E, CInt(&HE718), CInt(&H42EE), &HBC, &H55, &HA1, &HE2, &H61, &HC3, &H7B, &HFE)
IID_IShellItem = iid
End Function
Public Function IID_IFolderView() As UUID
'{cde725b0-ccc9-4519-917e-325d72fab4ce}
Static iid As UUID
If (iid.Data1 = 0) Then Call DEFINE_UUID(iid, &HCDE725B0, CInt(&HCCC9), CInt(&H4519), &H91, &H7E, &H32, &H5D, &H72, &HFA, &HB4, &HCE)
IID_IFolderView = iid
End Function
Public Sub DEFINE_UUID(Name As UUID, L As Long, w1 As Integer, w2 As Integer, B0 As Byte, b1 As Byte, b2 As Byte, B3 As Byte, b4 As Byte, b5 As Byte, b6 As Byte, b7 As Byte)
With Name
.Data1 = L
.Data2 = w1
.Data3 = w2
.Data4(0) = B0
.Data4(1) = b1
.Data4(2) = b2
.Data4(3) = B3
.Data4(4) = b4
.Data4(5) = b5
.Data4(6) = b6
.Data4(7) = b7
End With
End Sub
Using oleexp for CoreAudio. Some Help and Advice needed please.
I am exploring data capture with IAudioClient and IAudioCaptureClient (working in Exclusive Mode) using VB6. I would like to do some essential buffer handling in a CallBack Event using IAudioClient.SetEventHandle.
I just can not work out how to do this, is it even possible in VB6???? What do I supply as the long EventHandle required in SetEventHandle? And where does my buffer handling code go????
In the past I have used "addressof" to supply a callback subroutine in a code module, but I think that a CallBack Event is a very different thing.
I am hoping that the BufferFull event can be executed in a high priority callback so that it can execute even if my code is otherwise busy. If its all about sending a windows message to a Form then this is likely no good as VB6 message handling stops when my code is busy.
I'm assuming you would use CreateEvent to create your event handle.
https://docs.microsoft.com/en-us/win...i-createeventa
https://docs.microsoft.com/en-us/win...-event-objects
Have you seen this awful example? MS basically just sleeps and poles GetNextPacketSize. *shrugs*
https://docs.microsoft.com/en-us/win...uring-a-stream
This code here is on the other end of the spectrum, it sets up another thread, and uses WaitForMultipleObjects, and waits for the capture event to be raised, but at least it's complete.
https://graphics.stanford.edu/~mdfis...pture.cpp.html
Thanks, I have seen these links whilst searching for info. The CreateEvent API call looks like the likely way to go but I don't know how to get the resulting event in VB6. I really want the event to invoke some CallBack code rather than just a windows message.
There is some stuff on the www about people using the Create Event then just doing await loop waiting for the event to occur!!!!.
I am hoping to use the Event/Callback to simulate a bit of multi threading.
As a last resort I can use a timer to poll the buffer state but this might loose data as it looks like the internal buffer is only 2 seconds long maximum which is a bit tight for my needs.
Hi fafalone,
I have a very large project here (around 350,000 lines) with lots of everything (variables, controls, procedures), and recently I'm getting "Out of memory" errors in the VB6 IDE when I try to declare a new variable. Clearly I'm touching the limits of the IDE (see VB6 Project Limitations: https://docs.microsoft.com/en-us/pre...28v%3dvs.60%29). Now oleexp.tlb is very big and growing (which is good!), but I need only 10% of what's in it. So here's my question: How can I create a smaller custom version of it?
Thanks,
voxy
Hi fafalone,
I have a very large project here (around 350,000 lines) with lots of everything (variables, controls, procedures), and recently I'm getting "Out of memory" errors in the VB6 IDE when I try to declare a new variable. Clearly I'm touching the limits of the IDE (see VB6 Project Limitations: https://docs.microsoft.com/en-us/pre...28v%3dvs.60%29). Now oleexp.tlb is very big and growing (which is good!), but I need only 10% of what's in it. So here's my question: How can I create a smaller custom version of it?
Thanks,
voxy
Hmm.. I'm not even sure why TLB contents would effect this; only the portions that get used should be touched outside the object browser. If you compile a tiny exe that only uses a single variable or API from a typelib, the exe still just comes out to a KB or two above normal, so clearly the whole 1.2MB isn't being carried around. So first I'd be sure external depend's unused definitions even count (I highly suspect oleexp+standard refs exceeds 32k identifiers as defined in that article just by themselves).
But if that is the case, the easiest-to-deal-with targets would be the separate systems like TaskScheduler, NetCon, Devices, CoreAudio, and DirectShow if you're not using them. Those can be removed simply by removing their includes from oleexp.odl. Also the ListView interfaces/definitions added to support undocumented features.
There's a few more easily removable parts, mostly exp_ files, but they're a lot smaller. There's also API declares in modules named for their respective DLLs that most people declare locally instead.Code:#include "tasksch.odl"
#include "exp_audio.odl";
#include "exp_dshow.odl";
#include "exp_device.odl";
#include "exp_netcon.odl";
#include "exp_listview.odl";
Of course, this all presumes interfaces and APIs, count, even if the whole TLB does. Removing enums outside of those files you can remove entirely might be difficult, since most of them are used by interfaces, which you'd then have to replace with a generic 'long', or remove the interface, provided it's not among the ones passed specifically by type to another interface.
(Edit: Also in oleexp.odl is the GUID, which is advisable to change to avoid a conflict)
Well, I am the author. :wave:
I intent to publish a series of acticles from time to time to support your library. It's a pity that so many VBA developers overlook VB6 sites like this. oleexp has the potential to realize tasks that could not be acheived in any other way.
Wow... well, nice article! By all means continue with other articles and even put up demo projects with them if you want; it's as fully open as its foundation olelib is. :thumb::thumb:
And yeah, that's been oleexp's mission from the beginning, to pick up where Edanmo left off and take all the cool new shell features that have come between Vista and 10 and bring VB6 into this millennium. Some people prefer calling the v-table directly with DispCallFunc to implement the interfaces, but the way I see it is apart from the simplicity and time investment (few interfaces have already been implemented in classes), the TLB approach is much more efficient for things like having your current file as an IShellItem, then pass it directly to tons of other interfaces and APIs that call for an IShellItem.
So many VB6 apps look exactly like you'd expect from a IDE and language from the 90s; I take great pride in helping apps to look and behave indistinguishable from ones made in the latest shiny, along with others like LaVolpe and his manifest maker, and Leandro with clsMenuImage et al.
From time to time I've considered making an independent website dedicated to it; at first there wasn't enough content, but now... would that make the reach better? Of course here wouldn't change, I really like the community so would always keep this thread current. But I see the merit... it wasn't samples here that got me hooked on shell programming, it was Brad Martinez's site and projects. But again on the other hand an effort has been made to make this thread like a mini-site with how the first through third posts are-- master list linking to project pages, intro/install/documentation/common issues. So I dunno.
But back to the actual coding... VBA seems tough. I don't know if it's just me, do you (or anyone else reading this) get crashes when you trigger an intellisense popup while coding? The LongPtr thing inflicts some pain too. All the experience with VBA is just the issues in this thread, as it's not something I really use.
Sorry for the lo9ng delay in reply, but today I did look at some sample code for this, and it's indeed a standard event handle createable with CreateEvent; see e.g. this file. And this thread talks a little about using CreateEvent in VB6
2.30.4230; the version that came with my copy of VS6 Pro.
And yeah definitely let me know, I'm curious about this. Set up a circumstance where you can reliably repeat the error, change nothing except oleexp, then try to raise the error again.
Edit: Also to note, just constants, 6,282, API 577, 489 typedefs enum, 208 typedef struct so that's 7,556 identifiers without interfaces, then 755 interfaces+coclasses so there's potentially 8,311 identifiers in oleexp.
I was planning on adding it at one point, can't recall at the moment why I stopped the effort since it looks like was a year ago but it's just the prelimary copy of the SDK, it won't compile in MKTYPLIB and modification to avoid VB6 incompatible arguments isn't complete (looks like I stopped half way on line 886). Left the source in for possible inclusion in the future or if someone else was interested.
Non-final report: I removed some includes, gave it a new GUID, compiled it, copied it over to SysWOW64, had to re-reference it in VB IDE (probably because of the new GUID), and everything worked just fine. So I did not exclude anything I needed, good. oleexp.tlb is now 989.352 bytes, so roughly 200 KB smaller. Don't know about the inner counts. So far I had no "Out of memory" error, but it's too early to say. Give me some days...
Well, reducing the typelib by commenting out some components seems to have made a difference. The error message has not come up since I did it.
FYI, these are the parts I took out:
#include "tasksch.odl";
#include "exp_explrvw.odl";
#include "exp_audio.odl";
#include "exp_dshow.odl";
#include "exp_netcon.odl";
#include "exp_listview.odl";
#include "exp_spellcheck.odl";
Update: I now think reducing the size of the typelib did not have such a large effect. The error is coming back even with the smaller typelib.
I currently assume it might have to do with the Undo/Redo cache of the VB6 IDE. When I get the error I can simply close and reopen the IDE and work on for some hours.
voxy, maybe it can help.
Thanks, but my error is not "Fixed or static data can't be larger than 64K". It's not a compile error at all. It pops while typing or pasting into the IDE, usually when I declare a new variable.
I know. Maybe it somehow related.
Hi fafalone.
Can you fix the STGOPTIONS structure definition? Also make StgCreateStorageEx to has the optional parameter.
It should contain the two short fields instead long, and the long one instead ULONG.
Thank you in advance!
Sure thing. Will finish a couple other things and update this weekend.
Edit: Sorry I haven't updated yet. Forgot what a massive mess of other partially finished things were in the current dev version, was gone for a week, then got wrapped up in something else. Will definitely get it done over the next few days.
I have found one problem
this will give a error informationCode:Dim pVal As PROPVARIANT
Dim iPropStg as IPropertyStorage
iPropStg.ReadMultiple 1, pSpec, pVal
we can just move the type PROPVARIANT definition from exp_prop.odl to propstg.inc to fix it.
is that right?
It's not defined as PROPVARIANT, it's defined as Variant, which should be used in place of PROPVARIANT, which never works right. Use VB's Variant type then PropVariantToVariant (to another VB Variant); you can use the propvariant API's to change types if needed.
but why Variant to replace with PropVariant?
Well in this particular case, that's how it was defined in the original olelib that this project expanded.
But more generally, VB doesn't support user-defined structures with unions, so you can't define a real PROPVARIANT period, and always having it as a long pointer to a variable has always failed wherever I've tried it. I've even tried specifically defined propvar structs for certain data types, and things still failed every time. After many hours, using a Variant instead is the only way I've ever been able to use functions that require PROPVARIANT, and they've always worked just about perfectly-- because Variant and PROPVARIANT have very similar internal structures.
Originating thread: https://www.vbforums.com/showthread....=1#post5478421
Thanks a ton to your invaluable "extended" guidance (with sample code lines), I was easily able to obtain the multiple styles for fonts which possess the same. Two points of interest in this regard:
- For whatever reason, in the primary 'Fonts' folder screen, Windows (I have Windows 10) does not show the individual file names for fonts with multiple styles. This has been raised as an issue too here (in a Microsoft Windows forum). But, thanks to you, now in my program, additionally, I can show the file names for multiple styles too, in a grid which I have created (to show fonts info, in the same way as shown in the 'Fonts' folder).
Note: Even for fonts without multiple styles, for whatever reason, Windows shows all the file names in uppercase, totally. I am showing the same in my grid now, in the exact case in which the path&file names are existing in the system.- As far as I can see, Windows is showing the 'Size' info cumulatively for fonts with multiple styles. For instance, for Arial, it shows it as 4,240 KB (cumulatively, considering all the nine Arial .ttf fonts). But now, in my program, since I am showing the file name for each of the individual styles, I am able to show the file size too for each of the individual font styles.
I was able to give the above-mentioned additional info in my grid only because you took the time to give extended guidance on how to recurse through fonts which have multiple font styles. I remain ever in thankfulness to you. Thank you so... much.
Note: I have been trying to post this message since 24-May-2020 itself (in the originating thread mentioned at the top of this message) but every time I am meeting with errors only - of more than one kind. I am just unable to post. I tried posting through 3 different browsers. So, I am posting this message in this thread itself now, instead of in the thread specified at the very top of this message. Anyway, as such, this is the right thread for me to post this message since I have availed your library only so far and not your ucShellBrowse control. So, hopefully, no issues.
Prayers and Kind Regards.
Glad everything is working out, you're welcome :afrog:
The control/code here is just pulling data through the same methods that Explorer is; I checked the Fonts folder there and combined sizes and upper case names is how everything is shown in Explorer too, so not too much to be done there besides manually changing it yourself like you're doing.
As always, I'm happy to help and don't hesitate to post if any issues come up :thumb:
hi!
nice work. I am a bit confused, does oleexp.tlb include the interfaces etc. that exist in oleexmpimp.tlb/mimelib.tlb.
also does it include the windows api declarations, structures and constants.
oleexpimp.tlb contains slightly different versions of a small number of interfaces. For example, in oleexp.tlb, IEnumIDList.Next is a function that returns a Long, because knowing the return value is important for that call. But VB does not allow you to implement a class that contains functions, only subs, so if you wanted to implement that interface yourself in a class (Implements IEnumIDList), you'd use the version in oleexpimp.tlb instead, because that version is written without any return values. You don't need to include a reference to oleexpimp.tlb unless you specifically need one of these alternate versions for a class module Implements statement.
Only a few API declarations are included, most of which are related to or frequently used by the interfaces. All of that ones that are included are oleexp.tlb.
mimelib.tlb is interfaces specifically for MIME in messages; interfaces mostly starting with IMime____. It's very unlikely you'll need this one, and don't need to reference it.
Project Updated to Version 4.7
In one of the sample projects, an issue came up where the enum IUN_Flags and NII_Flags had all the same entries, so produced an ambiguous name error. I had not realized such an issue could make it through compiling the TLB, so had not checked. After realizing that was possible, I created a tool that scanned the code for duplicate constants or enum names, and found a number of them. So it was important to get this new version released to avoid bugs like that. But I had also done quite a bit of other work, so there's a bunch of other new stuff in the release too.
Here's the full changelog:
Code:(oleexp 4.7 - Released 23 Dec 2020)
-Added interfaces IFrameworkInputPaneHandler and IFrameworkInputPane, with coclass FrameworkInputPane.
-Added interface IShellTaskScheduler with coclass ShellTaskScheduler.
-Added interface ISharingConfigurationManager with coclass SharingConfigurationManager.
-Added interface IDefaultFolderMenuInitialize with coclass DefFolderMenu.
-Added interfaces IAccessible, IAccessibleHandler, IAccessibleWindowlessSite, IAccIdentity, IAccPropServer, and IAccPropServices (with coclass CAccPropServices) from oleacc.h, and related consts.
-Added undocumented interface ICustomizeInfoTip
-Added coclass PropertyChangeArray
-CHANGE TO MAJOR OLELIB INTERFACES: IFolderView has been updated to use As Any in a ByRef Long to get objects in .Items and .GetFolder. Also associated SVGIO enum for several members. Changed ByRef Long for interface pointers in IShellView and IShellView2 .GetItemObject, ICategoryProvider .CreateCategory
-IPropertyStore.SetValue and .Commit were already functions, made the rest of the methods into one as well.
-Added a number of error/success consts including OLE_E_, REGDB_E_, STG_E_, and RPC_E_ error codes.
-The wmp.dll dependency has been removed from oleexp.tlb, and placed in its own dependent tlb, oleexpwmp.tlb. The source is in \source\wmp\, which just moves the wmp.inc source file from olelib/oleexp and like mimelib.tlb, it's compiled including oleexp.tlb.
-Bug fix: IItemNameLimits is typically used for Implements, but had out-only parameters making that impossible.
-Bug fix: IUN_Flags and NII_Flags contained duplicate enum values. This caused an error using any of them and you had to specify which to use. The former has been removed. Change any instance of 'IUN_Flags' to 'NII_Flags'. The values themselves are unchanged.
-Bug fix: After the above issue popped up, I created a tool to root out any further duplicates. Unfortunately, there were many, as I had never worried about this under the assumption that a compile error would be triggered for such a situation.
The following were fixed: Two SVSI_Flags enums, one with additional values. Two SVGIO_Flags enums, ditto. Full duplicates of SVUIA_STATUS and SV2GV_Flags. ISCM_FLAGS was not used anywhere, and contained only a single value found in MUTZ_FLAGS. The URLACTION enum contained some duplicate values from URLPOLICIES.
-(oleexpimp) oleexpimp.tlb has been recompiled using oleexp 4.7
-(oleexpimp) Bug fix: This used the IShellFolder definition from olelib2, but VB says that's a bad interface for Implements
-(mWIC) Added WebP and Heif container format UUIDs.
Thanks again to your efforts to continue the development of this great library!
I'd like to know how you do the conversion of the headers to ODL? All manually? Like to share how it's done? Some others could then support you.
I ask because I did some modifications and enhancements to the library because some of the declarations seem not to work.
(Have you ever used IServiceProvider of oleexpimp.tlb? It always crashes if I implement it. I had to change the code like this to get it working:
As you can see one has to set a pointer to a specific interface (here IExplorerPaneVisibility) instead of a general long pointer to an interface. I found this to be required also for other implemented ServiceProviders.)Code:interface IServiceProviderExplorerPane : IUnknown {
HRESULT _stdcall QueryService(
[in, out] UUID* guidService,
[in, out] UUID* riid,
[out, retval] oleexp.IExplorerPaneVisibility** ppvObject
);
Back to the question: I tried to automate the conversion of the MSDN headers using a self developed parser. But it's really hard concerning all the conditional statements an includes. I am now at the state to generate a ODL that then further needs some manual adjustments. But that still is hard work.
My actual target is the Media Foundation API (https://docs.microsoft.com/en-us/win...api/mfobjects/). And especially a replacement for DirectShows Sample Grabber (https://docs.microsoft.com/en-us/win...i/mfreadwrite/) as the new methods are much easier to implement; much less code!
It would be an exceptional addition to oleexp if it included the media foundation interfaces and functions!