[VB6] ucShellBrowse: A modern replacement for Drive/FileList w/ extensive features

Quote:

---

Originally Posted by dmrvb

Hello Fafalone
It can be good to have a break from software. I have not done much with these controls while you have been away, it will take a couple of days to get back into them.
To make a start,
The screen flicker is because the uclist (shellbrowse) control does a double update, first with the files first, then with the folders first, hence the flicker. This only occurs (or is only visible) on folders containing a lot of files and subfolders.
I select a folder in ucTree, this execute "ucList.BrowserOpenItem ucTree.SelectedShellItem" and this gives the double update. This is confirmed by putting a debug.print in "ucList_DirectoryChanged".
I think this is intrinsic behaviour rather than a "race condition" between ucTree and ucShellBrowse.
Interesting observation problem does not occur if I set uctree.MonitorDirChanges = false
.....more in a day or so

---

Can you tell me more about what settings you're using? I can't seem to replicate this... I get a single ucShellBrowse_DirectoryChanged message regardless of whether I navigated through the tree or the browser. Perhaps set dbg_PrintToFile to True and attach the debug log it creates? Even better if on the host form you can take the ucShellTree_DebugMessage event and use ucShellBrowse.DebugLogInsertMessage "[ST]" & sMsg, so it gets the sequence.

Does this happen in an unmodified version of DemoEx and/or DemoOpenDlg?

(Just to confirm, you are on the latest version right? I know a very long time ago it was duplicating directory loads when combined with the tree)

This is strange.
I am using Shellbrowse 10.0.R4 and I now know its ShellBrowse rather than ShellTree that is the problem.
I have just made a new VB6 project with a single form containing a single ShellBrowse (using the code directly, not a compiled ActiveX). I have not changed any properties so they are all the default values.
I have put a single command button on the form that executes ucShellBrowse1.NavOpenParent and used the ShellBrowse and this button to navigate my file structure. I see the double update flicker on bigger folders, and debug.prints in directorychanged event confirm the double update on every folder navigation.
I am running windows 10 on an HP laptop.
I will compile to an EXE and use a textbox in place of the debug.prints and try it on a different computer. Will report back later with results, and also some info regarding Focus issues.

Good news Double update only occurs in VB6 IDE, compiled EXE is fine, so I propose that this is a "feature" rather than a bug, sorry if you have spent much time on this. I will now start looking at the focus limitations.

Focus Issues

I share your observation than VB6 focus can be a frustrating thing, I have had to use API calls in some of my projects to sort things out.

I have Shellbrowse and a ShellTree working together on a Form (my own test/evaluation project). The ShellBrowse is set to display just the ListView and no other components.
I would like to be able to click on either control to get it focused and then use keyboard up/down arrows to navigate.

1 If I click on shellBrowse (SB) then click on ShellTree (ST) ST highlight bars get highlighed so looks to have focus but does not respond to keyboard. ucTreee.EnterFocus does not fire.
2 If I call SetFocusAPI (ucTree.hWndTreeView) (from a command button) then this does correctly focus the ST, it gets the keyboard commands, but still does not fire then EnterFocus event.
3 ShellBrowse works well and does fire its EnterFocus and ExitFocus events. It responds to the keyboard but does NOT respond to the up and down arrow keys.
4 Clicking on SB then ST does not fire the ShellBrowse.ExitFocus because ST does not really get the focus.

I was working on focus issues tonight.... the IPAO calls weren't set up right in ucTreeView.

It seems to be working completely since I resolved that and another bug... but the real test will come when I test it with tabs and on Win7 later. But at least the switching back and forth between controls is resolved; I've got that working pretty good.


I'm going to take a look at the double loads later... it's odd it only happening in the IDE; What's the location like? If it's within a special folder or network location, there could possibly be an issue where it's representing the path name different so not blocking the duplicate load. But I'll attempt to replicate in a fresh project; it might be something about NavOpenParent, I hadn't checked to see if that in particular might cause a duplicate; it's not in the demo I already have set up, but will try a brand new one.

(PS- You don't have to worry about setting up a textbox for the EXE, all you have to do is toggle dbg_PrintToFile to True and the control automatically writes all debug output to a text file.)

Project Updated to Version 11.0

I've added all the requested features and fixed most of the bugs identified by others as well as a few more I found. There's still a bit of work to go but they're for minor issues, and some of the bugs that were outstanding I didn't want to wait anymore. So I'm by no means done, but this is a much improved version in the mean time.

The companion control ucShellTree has also been updated to v2.7, you'll need that to correct the keyboard focus issue between the two controls.

The new Explorer-style selection is where you can drag from within column whitespace to create a selection rectangle:
https://www.vbforums.com/attachment....hmentid=183576
Previously this would start a drag drop, and you had to go past the last column or below the last item to start the marquee. It works in all columns. Dragging from the actual filename/file icon still initiates a drag/drop (if enabled).
For a demo applying this to any ListView, see [VB6, Win7+] Undocumented ListView Feature: Multiselect in columns like Explorer

Code:

---

'New in v11.0 (Released 25 Jan 2022)
'
'
'-Added option ExplorerStyleSelection. Makes the ListView work like Explorer; if
' in Details View with Multiselect enabled, you can start a marquee to select
' multiple files by dragging in the whitespace of the Name column, rather than
' need to go off to the side. Enabled by default.
' Note: Does not work in Windows Vista.
' Note: This is an undocumented ListView feature. As such, it may be dropped from
'      future versions of Windows. However, it's confirmed to be working in
'      Windows 10, and it will simply stay with the old selection style if the
'      call fails, it will not break the control.
'
'-Added ClearSelection method to deselect all items.
'
'-Added new public SelectedFileSet sub with more options; allows select/deselect,
' separate option for focus, option to deselect all others, and ensure visible.
' SelectedFile (Let) wasn't changed since optional arguments aren't allowed and
' adding non-optional ones would break people's existing code.
'
'-SelectedFile (Let) is no longer case sensitive, since filenames are not.
'
'-New SetSelectedItemsEx function that provides a far more robust way of selecting
' files. Supports wildcards for selecting many, limiting to files or folders,
' setting a match limit, and more.
'
'
'-(Bug fix) High performance mode was broken on Windows 10.
'
'-(Bug fix) On some special editions of Windows 10, including LTSC, special folders
'          are not included, causing the Bookmarks menu to not show due to a bug
'          in handling errors generating that submenu.
'
'-(Bug fix) Some FILETIME and RECT types weren't explicitly defined, leading to
'          naming conflict errors in certain scenarios.
'
'-(Bug fix) On some versions of Windows 10, Special folders in This PC were grouped
'          with the drives.
'
'-(Bug fix) On Windows 10, some Security Zone icons failed to load.
'
'-(Bug fix) Keyboard focus never went to ucTreeView when on a form w/ ucShellBrowse.
'
'-(Bug fix) The arrow keys wouldn't work on the first click of the ListView.

---

Note: For a brief time when this was initially uploaded, there was a stray Debug.Print statement in FindFirstFileNt that should have been commented out or DebugAppend instead. 10 people grabbed it before I changed it, if that's you, it can safely be commented out. DemoFileProc also had an extra control that shouldn't have been there.

Thankyou
I have downloaded the new versions and had a very quick look, I will look in more detail over the next couple of days.
Initial tests indicate that the double update is fixed.

That's weird, since that was one of the minor things I hadn't tracked down yet :eek:

Btw, to automatically select the first file I didn't include a dedicated function, but the new SetSelectedItemsEx method can be used to do that... to select the first file (and only file, not folders):

ucShellBrowse1.SetSelectedItemsEx "*", True, 1&, SBIM_FilesOnly, True

*=match anything, true=deselect others, 1& = stop after 1 match, FilesOnly excludes folders, and the last True is Ensure Visible.

In the stealth update I made before I added an additional parameter to there concerning .zip files.... if it's set to browse them (BrowseZip = True), they're treated as folders by default, otherwise, as files. bZipIsFile can be set to 1 for always consider folder, 2 for always consider file. Not setting it follows the default.

Here's the full arguments for that function:

Code:

---

'bDeselectPrev - Clears any existing selection.
'nMaxMatches - If sName contains wildcards, specifies maximum matches. 0 = unlimited. Does not override Multiselect; so if Multiselect is False, any value larger than 1 is invalid.
'iSelectType - Match sName against Files only, Folders only, or both.
'bEnsureVisible - Scrolls the selected item into view. If multiple selections made, applied to the first match.
'bCaseSensitive - Applies both with and without wildcards.
'bZipIsFile - 0: Follow BrowseZip setting, 1: Always folder, 2: Always file
'Returns files selected.
'Note: First match receives focus.

---

There's also SelectedFileSet that's just for one file, no wildcards:
Public Sub SelectedFileSet(sName As String, bSelected As Boolean, Optional bDeselectOthers As Boolean = False, Optional bFocused As Boolean = True, Optional bEnsureVisible As Boolean = True)

Its all looking good, but am still finding a few little issues that I will investigate further.
Main problem is an intermittent total crash. I get this in the IDE but sometimes in the compiled EXE. It usually occurs after a lot of browsing and other activity but does not appear related to any specific action. I will try really hard to get more specific info.

There is something odd about fonts in the IDE. If I change any font detail and then make an EXE the fonts jump back to their previous settings.
Also in the IDE when changing ViewMode I get an error box "invalid window handle" from ucShellBrowse.ssc_SubClass
I have also seen this messagebox in a compiled EXE, I think (not sure) this was an EXE compiled without the manifest whilst investigating another oddity.

I can now get a total crash of ShellBrowse in a moderately consistent way.
I have done this in a compiled version of my own test software, but have also replicated it in a compiled version of your "ShellBrowseDemo" (ShellBrowse v11 RC1 std01.exe).

Navigate up to MyComputer then make many selections of different ViewModes. Making between 10 and 30 random selections should get a crash. There might be a specific sequence but I have not found that yet.

Another interesting behaviour..
In my test software if I navigate up through ShellBrowse using NavOpenParent then it goes up to Desktop and then stops/no longer responds to NavOpenParent. This is good.
If I link the ShellBrowse to a ShellTree then NavOpenParent continues to respond and loops between DeskTop and MyComputer and this feels wrong.
This is part of the mechanism...
NavOpenParent fires ShellBrowse.DirectoryChanged and this call ShellTree.OpentoItem
OpentoItem does NOT fire ItemSelect
However when ShellTree gets to DeskTop it Does fire ItemSelect and this calls ShellBrowse.OpenToItem. This gives a visible double update but also somehow sets ShellBrowse to a DeskTop that now does respond to NavOpenParent.
I hope this makes sense????

Quote:

---

Originally Posted by dmrvb

Its all looking good, but am still finding a few little issues that I will investigate further.
Main problem is an intermittent total crash. I get this in the IDE but sometimes in the compiled EXE. It usually occurs after a lot of browsing and other activity but does not appear related to any specific action. I will try really hard to get more specific info.

There is something odd about fonts in the IDE. If I change any font detail and then make an EXE the fonts jump back to their previous settings.
Also in the IDE when changing ViewMode I get an error box "invalid window handle" from ucShellBrowse.ssc_SubClass
I have also seen this messagebox in a compiled EXE, I think (not sure) this was an EXE compiled without the manifest whilst investigating another oddity.

---

This issue has happened before; it relates to switching views during runtime being unsupported without ComCtl6, so the entire ListView has to be destroyed and recreated. I'm really not sure it makes sense to continue attempting to support the control without ComCtl6, that's likely the source of a lot of the bugs and instability.

Quote:

---

I can now get a total crash of ShellBrowse in a moderately consistent way.
I have done this in a compiled version of my own test software, but have also replicated it in a compiled version of your "ShellBrowseDemo" (ShellBrowse v11 RC1 std01.exe).

---

Weird. Happens for me too, so will look into it.

Quote:

---

Another interesting behaviour..
In my test software if I navigate up through ShellBrowse using NavOpenParent then it goes up to Desktop and then stops/no longer responds to NavOpenParent. This is good.
If I link the ShellBrowse to a ShellTree then NavOpenParent continues to respond and loops between DeskTop and MyComputer and this feels wrong.
This is part of the mechanism...
NavOpenParent fires ShellBrowse.DirectoryChanged and this call ShellTree.OpentoItem
OpentoItem does NOT fire ItemSelect
However when ShellTree gets to DeskTop it Does fire ItemSelect and this calls ShellBrowse.OpenToItem. This gives a visible double update but also somehow sets ShellBrowse to a DeskTop that now does respond to NavOpenParent.
I hope this makes sense????

---

Sounds easy enough to fix... I had been relying on the UI element being enabled but if I add a variable to keep track of whether it's been disabled or not I can flag whether to let a call to OpenParent go through.

I am using the CC6 manifest.
I have found a few issues with the display of This PC.
The names of the disk drives are missing, and my iPhone is identified as UDB#vid_05...rather than as "Iphone".
I have tracked this down to my setting of FileExtensions = SBEP_AlwaysShow,
If I select FileExtensions = SBEP_UseExplorer then the display is correct, even though Explorer is set to display File Extensions.

Yesterday I reported that I could get a hard crash by changing DisplayMode whilst displaying This PC. I can also get the crash without changing DisplayMode but am starting to suspect that the crash only occurs when This PC is displayed. It certainly mostly occurs when This PC is displayed. I will test a bit more.

SelectedFileSet selects the file Before the specified file rather than the specified file
SelectedFile = has the same problem.

When we Browse to a new folder should the first displayed item be automatically selected?????
and if not done automatically is there a way to do this in code?

The name issue... is complicated. I need to do a complete overhaul of how it figures out what name to display. The problem is it's incredibly complex like you wouldn't believe... the display name may or may not have the file extension depending on the setting... but then, even if showing extensions are on, .lnk and .url are hidden anyway, and the control needs to know if they're links or shortcuts. Then the parsing name is different depending on where you get it from, there's multiple friendly names, and dozen other complications that have resulted in a spaghetti mess I really need to rework from scratch. So I'm going to take a few days before updating to do that and look into the crashing issue (I'm going to check if it's other special locations too, if it's really just This PC it could be an issue with the ICategorizer system, which only that folder seems to implement).


The selection issue in SelectedFile can be fixed by changing If LCase$(LVEntries(i).sName) = LCase$(sName) Then to If LCase$(LVEntries(lp).sName) = LCase$(sName) Then

For SelectedFileSet, just replace it with this version

Code:

---

Public Sub SelectedFileSet(sName As String, bSelected As Boolean, Optional bDeselectOthers As Boolean = False, Optional bFocused As Boolean = True, Optional bEnsureVisible As Boolean = True)
Dim i As Long
Dim nItm As Long
nItm = -1
Dim lp As Long
Dim lCnt As Long

lCnt = SendMessage(hLVS, LVM_GETITEMCOUNT, 0&, ByVal 0&)
ListView_SetItemState hLVS, -1, 0&, LVIS_FOCUSED Or LVIS_SELECTED

For i = 0 To (lCnt - 1)
    lp = GetLVItemlParam(hLVS, i)
    If LCase$(LVEntries(lp).sName) = LCase$(sName) Then
        nItm = i
        Exit For
    End If
Next i
If nItm = -1 Then Exit Sub

If bDeselectOthers Then ListView_SelectNone hLVS

Dim lvi As Long
If bSelected Then
    lvi = LVIS_SELECTED
    If bFocused Then
        lvi = lvi Or LVIS_FOCUSED
    End If
    ListView_SetItemState hLVS, nItm, lvi, lvi
Else
    ListView_SetItemState hLVS, nItm, 0&, LVIS_SELECTED
End If

If bEnsureVisible Then
    SendMessage hLVS, LVM_ENSUREVISIBLE, nItm, ByVal 1&
End If

End Sub

---

Selecting the first item... I didn't intend for it to be done as Explorer and most programs don't do that, but I can add an option to do it automatically, or you can do it programmatically already by putting the method in post #208 in the DirectoryChanged event. That method doesn't have the i vs lp issue the others have so no need to update anything.

Thank you again for all the effort you are putting in, but these are really good and useful (essential?) controls.

Ive been clicking away at my test program for a while now and I have not managed a hard crash at all except when displaying "This PC" so I am increasingly confident that something in "This PC" is the source of the crash.
My PC has gone really slow and needed a reboot so the crash is probably hurting windows too?.

Project Updated to 11.1


Most of the bugs mentioned above have been fixed. I did a temporary fix with the names; I wanted to get an update out with that and fixing the file select bugs before refactoring the whole file name tracking system, which desperately needs to be done but will take a while. Also planning on trying a new IPAO system for keyboard focus... the current one is a hacked together mess.

Code:

---

'New in v11.1 (Release 02 Feb 2022)
'
'-Provided some advanced item data access. zz_ExportSelectedItemFullData and
' zz_ExportItemFullDataByPos export the full internal item data structure.
' How to use these:
'  Step 1: Copy type definitions for UCSBFile, UCSBF_ColLink, and ColumnCache
'          to the calling form/module.
'  Step 2: Declare a UCSBFile variable, and 3 Long's to be passed as arguments
'          for the function: One to receive the memory pointer, and array
'          bounds for the LinkCols and ExtColData arrays in UCSBFile.
'  Step 3: Redim UCSBFile.LinkCols(nLinkCol) and UCSBFile.ExtColData(nExtColData)
'  Step 4: CopyMemory to UCSBFile from ByVal pData (only if function returns >0!)
'
'-Also added InvokeKeyPress to invoke a key press on the ListView by code. Has
' options for Shift/Control/Alt and whether to raise the ListKeyDown event.
'
'-CustomColor event now includes dwState argument that passes the CDIS_* values
' in NMLVCUSTOMDRAW.iStateId.
' ***EVENT PROTOTYPES ON YOUR FORMS MUST BE UPDATED!***
'
'-Set the ListView LabelEdit edit box length limit to MAX_PATH, to avoid an error
' when attempting rename.
'
'-(Bug fix) In high performance mode, showing hidden would also show superhidden
'          as the FILE_ATTRIBUTE_SYSTEM attribute wasn't checked.
'
'-(Bug fix) SelectedFile(Let) and SetSelectedFile selected the wrong file.
'
'-(Bug fix) If FileExtensions was set to AlwaysShow, drive names in This PC would
'          not be displayed at all, and some virtual items displayed GUIDs.
'
'-(Bug fix) When switching into some view modes without ComCtl6, an "Invalid
'          Window Handle" error would be displayed.
'
'

---

For reference, the new ucShellBrowse_CustomColor prototype is:

Code:

---

Private Sub ucShellBrowse1_CustomColor(ByVal itemIndex As Long, ByVal ItemName As String, ByVal SubItemIndex As Long, ByVal SubItemProp As String, ByVal dwStateCD As Long, ByVal dwStateLV As Long, rgbFore As Long, rgbBack As Long)

---

I did update the Demo that uses it, but if you get a 'description doesn't match' error, the above is what to replace it with (or delete it and paste the code back into a new one).

I might have also fixed the crashing in This PC. I got up to 35 before giving up, and a few bugs emerged... switching into List from Details (possibly others) after the 10th-15th time results in the names disappearing, but they come back when refreshed or put into another view. And the dumb drive used % bar for '3D Objects' somehow reappears deep into the repetitive switching; no idea how it evades the manual check, but wasn't going to delay release for that or the other thing.
Possible cause: This PC uses a unique ICategorizer object to create categories that aren't traditional groups... having the same grouping as Explorer depends on this complicated, poorly documented, buggy interface, and it's parent, ICategoryProvider. Requesting ICategorizer from the provider with a *void causes a crash, so I had to use a Long to get the pointer, then the undocumented vbaObjSetAddref. I theorized that setting the object that way resulted in it not being automatically released when it goes out of scope when LVLoadFolder exits. So I manually set them both to Nothing before the end of the sub, and can't currently get it to crash anymore. But I also recently rebooted so who knows, it could related to that and still coming.

PS- One new known issue not fixed yet; GetFileVersionInformation/VerQueryValue isn't working right for me... if others have this issue too, it's making the control think it's running under Windows 8 when it's on Windows 10. It only effects the Windows version displayed in the About box; the only feature checks look for Win8+ or Win7.

Bad news, I have only done a very quick test but,
With extensions always shown and in This PC...
USB device (Iphone) is still wrong.
Disk drives now show the drive letter but do not show the name
The crash is still present. I can usually get it after about 6 changes of displaymode, but sometimes a few more.

What's the exact name it's showing for your iPhone? I added a filter for ::{GUID} names, uuid: names, and \?\usb# names... wasn't aware of any other path formats.

The drive names aren't showing now by design, it's until I more thoroughly fix up the names.

With the crashing, is this changing view modes with comctl6 not available? Also, IDE or compiled... looks like I can still get my compiled exes to crash with enough clicks, but it's not happening in the IDE anymore even at 50+. VB has a ton of weird memory issues. Something must still be leaking when compiled but not in the IDE, unless you're getting that too (my IDE has Comctl6 enabled).

Edit: Actually, can you confirm whether or not you get the crash if you exclude Tile View from the modes you switch in and out of? That appears to be the reason why the reload routine is getting called just for a view switch. I can't get my compiled exe to crash either if I don't use Tile View.

The iphone shows as:
usb#vid_05ac&pid_12a8&mi_00#6&1115849b&0&0000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}

but again this only happens when .FileExtensions = SBEP_AlwaysShow, otherwise its fine.
I am doing all serious testing in the compiled EXE of my little test app as this is really what matters. My IDE is running in XP compatible mode (I can't remember why) so is not good for serious testing.
However have just tested now and can Not get a crash in the IDE
I am using your manifest in my test app so am using CommonControls6 (I have not changed the EXE name in the manifest but I don't think this matters?) Your help-about screen confirms commoncontrols6.
I am using Radio (option) buttons to select from 6 display modes which makes clicking a bit less tedious.
I have done quite a bit of GDI stuff so know just how difficult memory leaks can be.
I wish I could help, have had a good look at your code and don't currently have enough low level knowledge of Windows to really contribute.

Ok, can add a filter for that on in LVLoadFolder for now too,
If (Left$(sNameFull, 3) <> "::{") And (Left$(sNameFull, 5) <> "uuid:") And ((InStr(sNameFull, "\?\usb#")) = 0) And (Left$(sNameFull, 7) <> "usb#vid") Then


Let me know if the crashing is happening without Tile Mode included, that would help narrow it down if that's the reason.

I have currently included 6 display modes in my option buttons, this does Not include Tile Mode.
They are details/list/smallicon/mediumicon/thumbnail/contents.
The crash is when displaying ThisPC with extensions selected.
List sometimes looses its text
SmallIcons gives a double update when displaying ThisPC
The crash occurs most often (but not always) on thumbnails and contents, but maybe this is only because these are bottom of my list and I work down the buttons in sequence????

'Contents' mode is a variety of Tile mode; they both set the view to LV_VIEW_TILE; Contents just applies the LVTVIF_EXTENDED flag.

This seems promising. I've got some special handling code for This PC switching in and out of Tile View, but hadn't applied that to Contents view. So first I'd be curious if it happens without that in the loop too.

Thumbnails has always been a stability problem though.

If any display modes are really difficult or likely to be unstable then let me know and I will just not make them available in my software. There are too many view modes anyway, and some of them (list and small icons for example) are of limited usefulness. I would rather limit the choices available than have software likely to crash.
This project looks really difficult so maybe its best to concentrate of the core functionality and avoid spending time on some of the less important and badly behaved options?????
"This PC" looks to be a real source of trouble.
I have just investigated setting "ComputerasRoot= true" in both the tree and shellbrowse and this gives problems, so maybe this is one of those options best not supported?
Setting it at runtime causes the shellbrowse display to totally fail.
Setting it at design time mostly works but the tree and shellbrowse do not always synchronise.
I will provide more detail if you think this is worth investigating.

Yeah contents mode is particularly problematic, I honestly thought I had it disabled in the default 'RestrictViewModes' string. Explorer has a 'Contents' option but it's apparently entirely different than the one they provide for the ListView. The UserOption I have from prior to that property noted it...
Private Const bHideContentViewMenuItem As Boolean = False 'Default: False. On the View Menu, 'Contents' doesn't work all that great. You may want to hide it.

If 'This PC' is giving more trouble than Desktop as a root... I definitely need to look at that because I've had *a lot* more problems with Desktop as root because there's numerous ways to represent it, it's also a folder in C:\Users\[name]\Desktop, and different interfaces and APIs treat those different, some think they're the same, some don't, and a lot of other things. Sometimes you ask for the Desktop's parent you get nothing or the Desktop again, sometimes you get the UserFolder.

Do the synchronization issues persist when it's root in both of them? I'll admit I've never thoroughly tested using that option with both controls combined.

Changing the root at runtime was not a feature I had ever really tested, since it seemed like a really low priority (not sure why one would do that), so I threw in a basic 'set the variable and refresh'... if it's not working I can take a look; can it change to non-special roots ok?


Stability problems are unfortunately a fact of life trying to combine the Windows shell and nearly quarter century old VB6 (truly ancient in computer terms)... even Microsoft's option isn't any better, their IExplorerBrowser and INamespaceTreeControl objects are also highly crash prone and have features not working right or at all when used in VB6. So at least I'm in good company not getting it all right lol

But also a lot of these issues are solvable too... these are incredibly complex projects with a 50k LOC codebase between the two and I'm just one guy working on it in his spare time. I do want to get everything working, but I just don't have the time for extensive testing across multiple platforms, or really more than a few hours a week for development right now. And while there's a few people here who know VB6 and programming a lot better than me (in some cases by a lot, have you seen some of The_trick's stuff? Damn), I do seem to be alone in Windows shell developers still interested.

The point of these examples is largely two things; to do things purely in VB6, and to go into all the advanced things you don't find in available shell controls but do in Explorer. If you're looking for stable, basic file browsing, I'd be remiss if I didn't suggest ones written by more professional developers in other languages. There's a lot more than the two you mentioned in the other thread. Timo has a good one that's free and open source, controls written in C++ but meant for VB6 with samples provided (one of the benefits there is he's got subitem controls working, a feat I've been trying to accomplish on and off for years in VB6... This PC would probably be a lot more stable without needing to hand-draw the bars, to say nothing of Programs & Features and the hyperlink columns (fair warning there, change the bDisableHyperlinkItems to True right now if you're worried about stability but want to display certain non-default columns in that location, that's horrifically unstable).

The ComputerasRoot is really not a significant issue, I was just exploring the options. The change at runtime is because I usually set most properties from code rather that in the design time properties window as this makes the code more self-documenting.

The most important thing is please don't feel pressurised by me to fix the bugs, none of this is urgent or vital, but if you are happy to work on this then I am very happy to spend time testing, though I only have Win10 machines here now as all my software users are win10 (I have given up on the one still using XP).

Software is only part time for me but I have quite a bit of VB6 code that I will need to support and enhance for a few more years. I am using the LogicNP browser/tree which is no longer supported and I feel vulnerable to a Win10 update maybe breaking it, an update has already broken one of its features. I was looking at other potential ShellBrowsers as a contingency but yours is much more interesting and I would like to use it. Its written in VB6, source code available, and can be compiled directly into my code which are big advantages. A longer term goal would be to understand your code sufficiently to fix or enhance it myself, but I do try to use VB as a high level language so am not skilled at the low level Windows interface things. I believe that VB6 is a powerful language and with enough effort can do most things which is another reason that I like this project . I am also keeping a very close eye on twinBasic which could be a new VB without most of the VB limitations/oddities, but its GUI is still at an early stage.
I hope that it can make some things, like subclassing, a whole lot easier.

Except for the crash in ThisPC I am finding your code reliable.

Oh I definitely still want to work on it, so by all means keep the bug reports coming. But some of the issues might wind up falling under unfixable or 'Fix on this Windows version breaks that Windows version' or some of these weird memory issues might take forever to run down, since I have limited time for messing around with VB6 and have other projects to work on too (example: I'm taking this idea one step further and building an Explorer replacement by having an app that uses these controls and then behaves as a shell window, my new obsession ever since working to figure out how to take over when apps like web browsers have a 'Show in Explorer' option).

If you're looking to understand the codebase better, one thing that would certainly help is to go through all the individual shell project demos-- one of the original goals of this project was showing what you could do with everything I've written over the years. It's a lot easier when you have projects isolating a single feature... like how the previews are done with IPreviewHandler, enumerating file properties, or searching with ICondition and ISearchFolderItemFactory. You can use this link to see all my Code Bank submissions, you'll find a lot of ucShellBrowse is based on or directly copied/pasted from many of those. Sorry the code is so hard to read... between wanting everything to be in one module and my... lack of patience for best practices around formatting, naming conventions, and the like, it's definitely not the easiest to follow.

If you're looking for even more basic understanding, 'Visual Basic Shell Programming' by JP Hamilton and 'Advanced Visual Basic 6' by Matthew Curland are great books to read for understanding working with COM interfaces, vtables, and memory pointers, and some shell programming basics (PM me if you need copies).

Thinking VB6 can do almost anything for the type of app it's designed for is my philosophy too, I thoroughly enjoy getting all these modern shell things working in a language MS has tried it's hardest to kill after replacing it with a language inferior for many reasons for the core purpose of VB.

Thanks,
A bit of a philosophical ramble.....
Advanced VB6 is available on Amazon, though just a little expensive.
I would like to know more about how VB works but this is out of curiosity and "because I should". I really want to use VB as a high level language rather than doing lots of low level stuff. In the past I have done assembler on micros and even machine code on a mini computer, plus some hardware design and interfacing, and this taught me that programming should be done at a high level except when low level is essential.
VB6 is a still a good and productive high level language, and with a bit of modernisation could be really good. I am keeping a very close eye on twinBasic.
In an ideal community we should all mostly do high level stuff except for a few experts like yourself who do the difficult bits and wrap them in an easy to use high level interface. Its not productive for us all to acquire these skills, though I did really enjoy getting the CoreAudio Device Topology API thing to work.
When I look at the code that you and Krool etc are producing my heart sinks, "why should anybody have to spend so much time and effort writing such difficult stuff". Windows really needs a complete re-write (by engineers rather than computer scientists???) but I suppose this is exactly what they did but they made .NET rather than re-doing COM.

When I look at your code I do keep thinking would it be easier to abandon the Microsoft stuff and write completely new TreeView and ListView controls including self drawn graphics? GDI can be very fast and flexible. If TwinBasic succeeds and becomes the cross platform future of VB then self drawn self contained controls would be an easier route to cross platform, and without limitations.

Quote:

---

When I look at your code I do keep thinking would it be easier to abandon the Microsoft stuff and write completely new TreeView and ListView controls including self drawn graphics?

---

Replicating all the same features would a massive project all on it's own. Especially to have good graphics instead of basic flat stuff, although with Windows 10 there's not much more now. If you were going to do something like that, you wouldn't do it for a single small project, you'd want something that can be dropped into other projects... so now you're talking about essentially replicating it. Just think about all there is to worry about... scroll bars, footer bars, resizing, redoing a header where you do header drag/drop, supporting all the different item properties like bolded, grayed, etc... managing arbitrary icon sizes and scaling/spacing everything properly... besides, the it's not the ListView and TreeView themselves that are really the source of instability; just inconsistency with some features. You're probably going to wind up using graphics APIs that change too, so will you reimplement them? Then you're talking about hardware issues. The real problems come with interfacing with Windows itself.

But, somebody's got to write the hard stuff no matter what language you're talking about. None of the other shell browsing components that worked in VB6 have a lot of these features (and the property viewing/editing system appears unrivaled even in full on Explorer replacements being sold for real money), and none were *written* in VB6... unfortunately it's just the latter part has some real stability issues at the intersection of doing low(er) level stuff in a high level language not updated since last millennium. For the features I wanted, low level *was* essential... ListViews/TreeViews created with CreateWindowEx for instance can do a lot of stuff that's impossible or even more horrifically unstable with the VB common controls ocx. So, me and Krool didn't go that way just for fun :)

There is a bit of random behaviour when inserting and removing a USB disk drives whilst displaying ThisPC.
Again I am using linked ShellBrowse and shellTree controls.
First insertion and removal usually works, but on subsequent insertions the new drive is displayed but does not remove when the drive is removed. It is this possible to get several instances of the same drive displayed.
Refreshing ShellBrowse fixes ShellBrowse but this is not ideal.
Can also get the ThisPC crash.
Returning to an earlier post, "ComputerasRoot" is of limited use because it gives no access to Network drives.

Sounds like another Windows 10 issue; I had gotten removal to work ok in 7.

The problem is when a drive is inserted/removed, Windows spams you with various notifications.

Here's what an insert looks like:

Code:

---

ST][2022-02-15 13:51:17] Got PortableDevice(0)=\\?\swd#wpdbusenum#{0c2e5e43-66ce-11ec-83d1-806e6f6e6963}#0000000000100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_DRIVEADD,itm1=Q:\,itm2=
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_DRIVEADD,itm1=Q:\,itm2=
[ST][2022-02-15 13:51:17] Got PortableDevice(1)=\\?\swd#wpdbusenum#{fec98b6a-665d-11ec-83d7-d8bbc1516695}#0000000000100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
[ST][2022-02-15 13:51:17] Got PortableDevice(2)=\\?\swd#wpdbusenum#{b74926b2-665b-11ec-83d6-d8bbc1516695}#0000000000100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
[ST][2022-02-15 13:51:17] Got PortableDevice(3)=\\?\swd#wpdbusenum#{b74926ce-665b-11ec-83d6-d8bbc1516695}#0000000008100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_CREATE,itm1=::{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\Provider\Microsoft.Networking.SSDP//uuid:cbba0323-d2bb-3569-b2d2-2df8571c54c1,itm2=
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_CREATE,itm1=::{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\Provider\Microsoft.Networking.SSDP//uuid:cbba0323-d2bb-3569-b2d2-2df8571c54c1,itm2=
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_CREATE,itm1=::{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\Provider\Microsoft.Networking.SSDP//uuid:2f1d60b4-1dd2-11b2-8296-2f954411ea58,itm2=
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_CREATE,itm1=::{F02C1A0D-BE21-4350-88B0-7367FC96EF3C}\Provider\Microsoft.Networking.SSDP//uuid:2f1d60b4-1dd2-11b2-8296-2f954411ea58,itm2=
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_MKDIR,itm1=::{289AF617-1CC3-42A6-926C-E6A863F0E3BA}\uuid:2f1d60b4-1dd2-11b2-8296-2f954411ea58,itm2=
[ST][2022-02-15 13:51:17] HandleShellNotify::code=SHCNE_MKDIR,itm1=::{289AF617-1CC3-42A6-926C-E6A863F0E3BA}\uuid:2f1d60b4-1dd2-11b2-8296-2f954411ea58,itm2=

---

Then removal:

Code:

---

[ST][2022-02-15 13:52:12] HandleShellNotify::code=SHCNE_DRIVEREMOVED,itm1=Q:\,itm2=
[ST][2022-02-15 13:52:12] HandleShellNotify::code=SHCNE_DRIVEREMOVED,itm1=Q:\,itm2=
[ST][2022-02-15 13:52:12] HandleShellNotify::code=SHCNE_UPDATEDIR,itm1=C:\Users\Jon\Desktop,itm2=
[ST][2022-02-15 13:52:12] Got PortableDevice(0)=\\?\swd#wpdbusenum#{fec98b6a-665d-11ec-83d7-d8bbc1516695}#0000000000100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
[ST][2022-02-15 13:52:12] Got PortableDevice(1)=\\?\swd#wpdbusenum#{b74926b2-665b-11ec-83d6-d8bbc1516695}#0000000000100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
[ST][2022-02-15 13:52:12] Got PortableDevice(2)=\\?\swd#wpdbusenum#{b74926ce-665b-11ec-83d6-d8bbc1516695}#0000000008100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33}
[ST][2022-02-15 13:52:12] HandleShellNotify::code=SHCNE_DRIVEREMOVED,itm1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\\\?\swd#wpdbusenum#{0c2e5e43-66ce-11ec-83d1-806e6f6e6963}#0000000000100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33},itm2=
[ST][2022-02-15 13:52:12] HandleShellNotify::code=SHCNE_DRIVEREMOVED,itm1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\\\?\swd#wpdbusenum#{0c2e5e43-66ce-11ec-83d1-806e6f6e6963}#0000000000100000#{6ac27878-a6fa-4155-ba85-f98f491d4f33},itm2=
[ST][2022-02-15 13:52:12] HandleShellNotify::code=SHCNE_MKDIR,itm1=::{289AF617-1CC3-42A6-926C-E6A863F0E3BA}\uuid:2f1d60b4-1dd2-11b2-8296-2f954411ea58,itm2=
[ST][2022-02-15 13:52:12] HandleShellNotify::code=SHCNE_MKDIR,itm1=::{289AF617-1CC3-42A6-926C-E6A863F0E3BA}\uuid:2f1d60b4-1dd2-11b2-8296-2f954411ea58,itm2=

---

And the sequence changes from version to version or sometimes even just randomly. If it sends more adds than removes, you might wind up with duplicates.

Needless to say, getting spammed with random numbers of duplicates of the same notification is difficult to handle consistently. Especially when it mixes in referring to the drive as letter and a GUID.

I *think* the problem here might be Windows 10 is trying to deliberately throw things off... look how it sent two MKDIR (Directory Created) messages saying a GUID referring to the device had been created, after the removal routine. I don't know where that behavior started but you don't expect to get a message to recreate a removed drive.

Can think of a couple fixes... adding a timed lockout would be the easiest... but might get messed up if the system is lagging or you remove multiple drives at the same time. So I think I'll try ignoring MKDIR messages for devices, since the DRIVEADD or UPDATEDIR messages will take care of creating them; or perhaps an aggressive dupe check in LVAddEntry.

Project Update: 11.2
-I haven't had a ton of time to work on this between work and so many other projects, but I did want to release the few small feature updates and bug fixes that have been pending.

Code:

---

'New in v11.2 (Released 18 Jun 2022)
'
'-Added SearchAutoGroup to automatically group search results. The default is to
' group them by folder, but you can change that via the szAutoGroupSearchCat
' User Option.
'
'-In addition to below specific bug identified, added a more robust system of
' ensuring duplicates are not added by receiving duplicate ShellNotify messages.
'
'-SelectedFiles (Let) and FileSetCheck are no longer case sensitive.
'
'-Now use Unicode-aware width calculations in Details Pane.
'
'-(Bug fix) In Computer/This PC, for some Windows versions removing a USB device
'          then plugging it back in could result in duplicate entries.
'          Also improved entry remover to better handle these.
'
'-(Bug fix) SelectedFileSet ignored bDeselectOthers flag.
'
'-(Bug fix) The control improperly reported the Windows version due to Microsoft
'          breaking most version functions to require a manifest specifying 10
'          compatibility or else it deliberately reports Windows 8. This didn't
'          impact functionality as the only version-restricted features were
'          Vista+ to run at all, and Windows 8+ for some Bookmarks folders.
'
'-(Bug fix) Since version 9.4, pressing enter in the Search Box accidentally
'          had the code to use the legacy search enabled. That would be conducted
'          first, then the new search would be conducted. This doubled (at least)
'          the search time and created a duplicate folder.
'
'-(Demo)    The Demo manifest, with the preferred settings, has been updated to
'          include compatibility flags, trust info, and newer dpi awareness.

---

64bit Compatible twinBASIC Version Now Available!


twinBASIC UserControl support has come a long way in recent weeks, and there's now a beta release of this control for tB, compatible with both 32bit and 64bit apps. Makes use of my tbShellLib project to replace oleexp.tlb.

GitHub - ShellControls

Hi fafalone
ucShellBrowse v11.2 control on VB6
immediate crash on Load project (Windows 10 22H2) !
I can't do nothing ... ?

Loading the demo projects? Or loading a project you've used it in? Do you have SP6 installed for VB6?

Would need a bit more info to help here, as I don't think it's impacting anyone else.

Yes fafalone i have used Demo Project with oleexp 6.4 - Released 10 August 2023 in reference.
I have also tried to create a simple test with nothing else than the control and the olexp 6.4 in ref. -> Crash
I use VB6 SP6.
I specify that ucShellTree 2.7 works perfectly

Hi !
Everything works for me except when I use Shell instruction to launch a program using ucShellBrowse.

For example, when I compile Demo\ShellBrowseDemo.vbp or Demo2\Project1.vbp, I can use the result .exe with no problem by double-clicking them in explorer, but if I try to shell this .exe from another vb program, it crashes.

Any idea ?
(Windows 11)


Edit :

If the program executing the shell command is compiled, it works whereas in IDE it crashes.

Does the same thing happen if you use ShellExecute?

Code:

---

Public Declare Function ShellExecute Lib "shell32" Alias "ShellExecuteA" (ByVal hwnd As LongPtr, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As LongPtr

---

I can't replicate the issue on Win10 but I'll check Win11 later today.

Update: Can't replicate on Win11 22H2; tried both exes compiled on Win10 and compiled on the same Win11 VM, with both no 2nd argument, and with normal focus and normal no focus.

But I have heard of issues with the ancient VB Shell statement before; try ShellExecute.... ShellExecute(0, "open", "C:\path\to.exe", vbNullString, vbNullString, 0)

With this code :

Code:

---

Option Explicit

Private Sub Form_Load()
    Shell "D:\Tests\ucShellBrowse\Demo2\Project4.exe", vbNormalFocus
End Sub

---

Nothing happens when run in IDE, but if I compile, Project4.exe is launched as expected. The same with ShellExecute.

Well that's not a big deal as it works when compiled. Just had to figure out :-)

That's very weird; I can't understand how the API would be failing, nothing happening is better than crashing at least.... can you tell me the return value it gives? Like Debug.Print ShellExecute(0, "open", "C:\path\to.exe", vbNullString, vbNullString, 0)

Have you tried launching other apps from the same program?

Tried it again in Form_Load and still had no trouble here on Win10 or 11... have you restarted since this began (full restart, not a hot restart, by actually choosing restart and not shutdown)? Sometimes strange ghost bugs like this pop up but go away on reboot.