Modern replacement for the VB DriveListBox control?

[AAraya]

Are there any modern replacements for the VB DriveListBox control?

I've seen Fafalone's ucShellBrowse control and that does indeed provide that capability but the new version of oleexp.tlb which it requires is causing massive headaches for me as it conflicts with data type definitions I've already got in my program. Already spend too many hours today trying to resolve those only to have to roll back all the changes. It's a great control but it's actually overkill for my limited need. A simple OCX or ctl, or code would be great!

[fafalone]

What kind of conflicts do you mean? All the new version does it add more interfaces; I didn't add a bunch of data type aliases or anything.

Anyway, maybe try the OCX version of ucShellBrowse? It doesn't require oleexp for basic features and would work with an old version for using IShellItem etc from it.

There's an older VB6-compiled version here: https://www.vbforums.com/showthread....l-Controls-OCX

Or the latest version seems to be working ok in VB6; it's based on the twinBASIC version and compiled by that: https://github.com/fafalone/ShellControls/releases

[Darkbob]

I thought I'd try the OCX but when I try to add it to a project VB comes up with a message saying "could not be loaded". Any ideas?

[AAraya]

What kind of conflicts do you mean? All the new version does it add more interfaces; I didn't add a bunch of data type aliases or anything.

Anyway, maybe try the OCX version of ucShellBrowse? It doesn't require oleexp for basic features and would work with an old version for using IShellItem etc from it.

There's an older VB6-compiled version here: https://www.vbforums.com/showthread....l-Controls-OCX

Or the latest version seems to be working ok in VB6; it's based on the twinBASIC version and compiled by that: https://github.com/fafalone/ShellControls/releases

I compiled the new version of ucShellBrowse to OCX, registered it, added the component to a new project, placed it on a blank form, set it in the Property Page to display drives only. No other code, no other settings made to the Properties. When I ran the new project, it shuts down during startup.

I'll give the old version a try.

[AAraya]

I tried to load the old ShellControlsVB6.ocx as a Component to a new project but had the same error as Darkbob, "Could not be loaded"...

Here's the process I used:
1. Copied it to a folder where I keep shared OCXs.
2. Registered it with regsvr32
3. Opened a new EXE project
4. Attempted to add the OCX via the Project Components dialog

Received the "Could not be loaded" error...

This is the process I use to install, register, and load all OCXs. Does yours not work this way?

[VanGoghGaming]

as it conflicts with data type definitions I've already got in my program.

That's highly unlikely because local definitions always take precedence over TypeLib definitions. You may have other TypeLibs that expose the same definitions though and in that case the precedence is dictated by the order of TypeLibs in the References menu.

Also there is the "SHBrowseForFolder" API function that pretty much takes care of selecting drives and folders.

[fafalone]

I checked and it looks like I accidentally had the wrong build settings configured when I posted the OCX building version.

To use in VB6 when you compile it, it the project type should be ActiveX Control, and tB must be run as admin, and the 'Register to HKEY_LOCAL_MACHINE' option enabled and changed to Yes, and Register after build Yes. Seems I inadvertently had saved one configured to build for a tB package.


I've updated ShellControlsTB.twinproj in the repo to now have ready-to-go settings to compile for VB6; just make sure tB is running as admin and in 32bit mode. This version won't conflict with the old one; it will be listed with the name 'ucShellBrowse and ucShellTree Controls 12.2/2.9.2' and all GUIDs have been changed to make it be seen as an entirely different control.

Once it's built like that, I can't reproduce any issues in VB6; it's working fine in drives-only mode both in IDE and compiled, with and without Comctl6 manifest.

https://github.com/fafalone/ShellControls

Sorry for the confusion, OCXs are always a giant pain. I still don't see how conflicts are preventing you from using the 11.2 vb6 version though.

[AAraya]

Hi fafalone,

Thanks for looking into this. There seem to be many references in your response related to TwinBasic? For clarity, I'm using this on VB6. I'm not clear on what I need to do differently in VB6 to get this to work? Do I need to download some different files? Do I need to change build settings before I compile to OCX? Sorry if I'm being dense.

Can I trouble you to provide me with a VB6 only solution to this problem?

BTW - I have to thank you once again. I've lost count of the number of times you've helped me out. You're an excellent coder and a great guy.

[AAraya]

I had a copy of TwinBasic that I downloaded last week to play around with so I thought I'd give your tB instructions a go. I was able to compile it to OCX, add the OCX to a new VB6 EXE project, place the ShellBrowse control on a form, change the Property Page setting to Drives only. And then VB6 just shutdown/disappeared/crashed with no errors.

Update #1 - now on second attempt this crash is no longer happening. Both controls seem to be working for me. Let me play around with this some more to see if it works or it's an intermittent problem.

Update #2 - on subsequent tests I get this crash regularly when changing to different ControlType properties. It doesn't seem to be specific values that cause the crash as sometimes a ControlType will work fine and other times it'll crash. Just the act of changing the setting seems to cause it. Once I can set this without a crash I seem to be good after that? (I think? It's pretty random right now so not sure. Just reporting realtime testing results)

Final update:
These control types always work without a crash:
Files Only
Dir and Files Only

The others crash the vast majority of the time. As a matter of fact, I'm unable to get the Drives only ControlType setting to work for me now when I was able to initially.

[fafalone]

Last week is already missing a lot of recent ActiveX control bug fixes from betas 512-515... if you'd like I could first investigate whether that's the issue if you could tell me the version you did use; but I'd really recommend recompiling with Beta 515 from yesterday. In addition to my Windows 10, I just tested on my Windows 11 VM and also don't have any crashes no matter how many times I switch the control type; all I did was open ShellControlsTB.twinproj while running tB Beta 515 as admin and hit build, then opened VB6, added it to components, and placed it.

What you can do to avoid registration issues with a new build is just open project settings, and there's an option "Register after build"... change nothing except checking the box for that and selecting "No" in the combobox (don't change the path either- you're just overwriting the last build; if any VB6 instances are using the control, close them first), then build. It's a very convenient feature of tB to not touch the registration info when not needed; VB6 is always changing something that messes it up.

[AAraya]

I downloaded the latest version of the code from your GitHub (v12.2.2.9) and compiled that to OCX in twinBasic (v Beta 492).

Art

[fafalone]

That's pretty far out of date but I still couldn't replicate any crashing on my test machine; can you tell me your specific version of Windows, and whether you have any major addins like CodeSMART or Rubberduck running? (No known issues with those specifically but they have caused me random crash problems in other contexts).

Sorry for all the trouble here but the VB6 OCX doesn't seem any better in this regard lol

If you don't want to mess with it anymore it might be easier to resolve whatever conflict you're having with oleexp 6.5, or just assign the system imagelist to an imagecombo control. But maybe before you give up entirely try with Beta 515 just doing the overwrite with 'Register project after build' set to 'No'. I couldn't repro an issue with 492 but still there were *huge* improvements in stability over the weeks since that version.

[AAraya]

Update

I just downloaded the latest tB (515) code from GitHub. Launched it as Admin, opened the latest version of ShellControls in tB, changed the Project Settings per your instructions, Built the OCX. Moved the OCX to my Share OCX files folder, registered it. Opened a new VB6 EXE project, added ShellControls OCX to the project, placed ShellBrowse control on a form. Change the DriveType to Drives Only. VB6 shutdown with no error...

I know it's easy to dismiss user errors that you can't recreate but just know that I'm using MANY ctl and OCX files from vbForums and have no problems with any of them.

[AAraya]

In terms of IDE add-ins, I do have MZTools installed.

[fafalone]

Not dismissing it at all; that's why I'm asking for specific Windows version and VB6 install details, so I can set up an environment to reproduce the issue. Just mentioning other options since I know other people often don't like spending a bunch of time running down bugs in other peoples code I'd very much like to try to reproduce it, if you could let me know your Windows version, and just confirm you have VB6 SP6 installed?

[fafalone]

Wait; the instructions I gave you were specifically *not* to register it. The whole idea was to just overwriting the existing version and use its pre-existing registration. Are you sure its loading the new version? Did you overwrite the old files or is there now a registration conflict because you would have registered multiple files under the same GUIDs?

[k_zeon]

Update

I just downloaded the latest tB (515) code from GitHub. Launched it as Admin, opened the latest version of ShellControls in tB, changed the Project Settings per your instructions, Built the OCX. Moved the OCX to my Share OCX files folder, registered it. Opened a new VB6 EXE project, added ShellControls OCX to the project, placed ShellBrowse control on a form. Change the DriveType to Drives Only. VB6 shutdown with no error...

I know it's easy to dismiss user errors that you can't recreate but just know that I'm using MANY ctl and OCX files from vbForums and have no problems with any of them.

i recently let my antivirus turn on DEP. and then all kind if Sxxt went wrong. VB ide had issues and Firefox would not load. 2 off my apps did not even open.
i then turned DEP back off and all issues went away.

Do you have DEP turned on. If yes then try turning it of or adding to the exclude list.

[AAraya]

I unregistered the old version before doing any of this. If you think this is an issue, let me know what you want me to do and I'll try it step by step. Sorry for missing that last time!

[AAraya]

I'm not sure what DEP stands for

[VanGoghGaming]

That is the default setting.

[AAraya]

1. Turned off DEP. Rebooted Windows.
2. Started a new VB Project and added the compiled OCX which was no longer registered as a Component
3. Added it to a form, changed the ControlType, app shut down

fafalone. If I'm the only having this issue, just forget it. Must be some weird thing with my system only. Again, all other vbForum user controls and OCXs work fine but only this one. And only certain ControlType settings.

Thanks all for your help. I think it's time to move on...

[fafalone]

I'd like to investigate at least, so even if you move on, if you could just let me know a specific Windows version and if you have VB SP6 installed. I don't know of anyone else using the tB version as an OCX in VB6; so who knows how widespread the issue may be.

Then moving on; if you could maybe give a little more detail about the problems you're having with oleexp.tlb there's no reason it shouldn't be possible for the .ctl version to run.


==
I do think we need a simple drive combo, so I'm going to put together a simple one in the next day or two.

[AAraya]

Windows 10 Build 19045
VB6 SP6

Do I need to use the tB built version of OCX in VB6? I thought I was following your instructions on this. But it's possible I misunderstood. If there's a VB6 version of this, I'd be willing and interested in trying that.

[fafalone]

I included a link to the last VB6 compiled version of the OCX above (here again), but DarkBob and others have mentioned that has problems on some systems too. I've had problems with it as well; one day it will be working fine then the next crashing.

If you were able to compile a new version from VB6 then you'd be able to just avoid the OCX mess entirely and use the much more stable behaving .ctl directly (for a drive list you won't miss any of the changes between 11.2, the last VB6 version, and 12.2, the current tB version). As mentioned, I can help with whatever oleexp issues you're having that's preventing both of those.

[fafalone]

As a thanks for your patience here's a quick modernized DriveCombo control. I'm going to add a few features and test one extended feature before putting it in the CodeBank, but here's a working beta version. Biggest thing I didn't have time to add today is changing the selection programmatically.

It's supplied as a VB6 .ctl not requiring any typelib, just the included helper .bas. The code is also compatible with twinBASIC and 64bit compilation without modification, and also included in .twinproj form.

Supports filtering by drive type and includes a SelectionChanged event as well as .SelectedDrive properties. DropdownList style is the default, but a standard combo style with dropdown is also available (must be set at design time). Set to display the same friendly name as in ThisPC and you can retrieve that with SelectedDriveName, or the C:\ type path with SelectedDrivePath, or the plain letter with SelectedDriveLetter.



(Attachment removed)

I've now released the 1.0 version in the CodeBank:

[VB6, twinBASIC] ucDriveCombo - A modern DriveList replacement

[AAraya]

Then moving on; if you could maybe give a little more detail about the problems you're having with oleexp.tlb there's no reason it shouldn't be possible for the .ctl version to run.

There's nothing wrong with your TLB, I'm sure it's due to how I designed things in my app. I don't want to hijack this thread talking through the details of that, and I don't consider it a YOU problem at all but since you've asked several times...

From a high level the issue is:
I was having problems with UDTs in my project. I wanted to use them as parameters and return types for procs throughout my code but was getting "only user-defined types defined in public object modules can be coerced" errors. I found that I could put the UDTs in a DLL and this would resolve the problem. So I created a DLL which is just a library for the UDTs I need to pass around in code. Several of these UDTs contain a field of type FILETIME. So I had to include that definition in the UDT DLL library as well. All that works well.

But this created problems with type libs that contained the FILETIME struct. In order to get around this with the old version of oleexp.tlb, I simply had to make sure that my UDT Library DLL appeared higher in the priority list than oleexp.tlb in the VB References dialog. This resolved the problems. However this workaround no longer works with the new version of the TLB for some reason. I tried various changes to my code, to my UDT Library, and to the References order to resolve the problem but nothing worked.

[AAraya]

I included a link to the last VB6 compiled version of the OCX above (here again), but DarkBob and others have mentioned that has problems on some systems too. I've had problems with it as well; one day it will be working fine then the next crashing.

Ahh OK, yeah I tried that one too and had the same issue as DarkBob.

[fafalone]

When you right click and go to 'Definition', it's actually taking you to a *lower* priority definition? Or to the right one but when running still uses a random one?

I have no idea why it wouldn't respect priority, but have you attempted to resolve that issue by explicitly qualifying the conflicting definitions; i.e. myvar As MyDLL.FILETIME and myvar As oleexp.FILETIME?

oleexp could be made so that the UDTs could be passed around in the same way, but that introduces active-x like registration requirements and issues, like you can no longer just overwrite the old version, you have to unregister it first with a typelib-specific registration tool instead of regsvr32. I didn't think it would be worth the trouble.

Anyway I'll continue to look at these issues but I hope the new control works for you, there's no typelib dependency and it can be used as a .ctl or compiled by VB6 to an ocx.

[AAraya]

When you right click and go to 'Definition', it's actually taking you to a *lower* priority definition? Or to the right one but when running still uses a random one?

I have no idea why it wouldn't respect priority, but have you attempted to resolve that issue by explicitly qualifying the conflicting definitions; i.e. myvar As MyDLL.FILETIME and myvar As oleexp.FILETIME?

oleexp could be made so that the UDTs could be passed around in the same way, but that introduces active-x like registration requirements and issues, like you can no longer just overwrite the old version, you have to unregister it first with a typelib-specific registration tool instead of regsvr32. I didn't think it would be worth the trouble.

Anyway I'll continue to look at these issues but I hope the new control works for you, there's no typelib dependency and it can be used as a .ctl or compiled by VB6 to an ocx.

have you attempted to resolve that issue by explicitly qualifying the conflicting definitions; i.e. myvar As MyDLL.FILETIME and myvar As oleexp.FILETIME

Yes, that is one of the things I did which in my mind SHOULD have resolved the issues but did not.

Anyway I'll continue to look at these issues but I hope the new control works for you, there's no typelib dependency and it can be used as a .ctl or compiled by VB6 to an ocx.

No need to look at the issues. I consider them mine and not your TLB.

And the new control is going to work GREAT for me. I can't thank you enough for creating that! I think it's a worthy contribution to the collection of VB6 control modernization efforts which I'm surprised no one ever created before.

I do have a couple of questions about it which I posted in the CodeBank submission thread.