DevExpress Shell Components and Problems with 3rd Party Applications

[Alexander Halser 34]

This is not a question but the description of a solved problem with Developer Express shell components.

 

Hopefully, it will save someone from difficult debugging.

If you are using any DevExpress shell components - a TdxOpenFileDialog, a TdxSaveFileDialog or simply a TdxShellTreeview, please read ahead.

 

Background

With the release of our help authoring tool Help+Manual 10, we changed all open and save dialogs to custom DevExpress dialogs in order to implement custom file previews, more consistent dialog extensions and dark mode skinning. Soon after the release we started to get problem reports regarding the open and save dialogs, which were not reproducible on any of our machines. Two customers who experienced delays and freezes were helpful enough that we could start debugging with the help of DevExpress.

 

Symptoms

When creating a TdxShellTreeview (or a TdxOpenFileDialog or TdxSaveFileDialog, which include the shell treeview), your application freezes and crashes. If it does not freeze, your end users might experience delays of 50 seconds and more. We were able to isolate the issue and reproduce it with different Delphi versions from XE6 to current, and with different versions of the DevExpress VCL components.

 

Problem Source

The TdxShellTreeview tries to mimic the behavior of Windows Explorer. In particular, it not just displays icons for files and folders, but also tries to fetch an overlay icon. Overlay icons are the typical domain of 3rd party applications such as version control systems, who inject custom overlay icons into Windows Explorer. If the icon fetching takes too long, your users might experience delays or an application freeze. We were able to reliably track it down to one 3rd party app in particular: "Surround SCM Explorer", which is used for source code management by one customer. When they switched off the overlay icon option in this app, the mysterious freezes disappeared.

Difference between Windows Explorer and DevExpress Shell Controls

Windows Explorer fetches overlay icons in a separate thread, DevExpress explained. Their shell controls do not. This can cause delays and application freeze if the 3rd party app takes too long to respond with a matching overlay icon for an entry. There is currently no solution to this problem and DevExpress did not indicate that or when they were going to implement a threaded version. We went with a source code patch, that works for us. Downside: we have to apply the patch again with every update.

 

DevExpress Patch

We applied a patch - suggested by DevExpress - in 3 locations of the code and replaced all instances of TdxShellItemHelper.GetOverlayIndexByPidl(AAbsolutePidl) with a -1 constant (no overlay icon). Example:

 

procedure TcxShellItemInfo.CheckUpdate(const AShellFolder: IShellFolder; AFolderPidl: PItemIDList; AFast: Boolean);
var
  AItemInfo: TdxShellItem;
  AAbsolutePidl: PItemIDList;
begin
  if Updated or Updating then
     Exit;
  Updating := True;
  try
    Assert(pidl <> nil,'Item object not initialized');
    if pidl = nil then
      Exit;
    AItemInfo.IconIndex := FIconIndex;
    AItemInfo.OpenIconIndex := FOpenIconIndex;
    AItemInfo.OverlayIndex := FOverlayIndex;
    if not AFast then
    begin
      AAbsolutePidl := CreateAbsolutePidl;
      AItemInfo.IconIndex := TdxShellItemHelper.GetIconIndexByPidl(AAbsolutePidl);
      if FIsFolder then
        AItemInfo.OpenIconIndex := TdxShellItemHelper.GetOpenIconIndexByPidl(AAbsolutePidl);
      AItemInfo.OverlayIndex := -1;//TdxShellItemHelper.GetOverlayIndexByPidl(AAbsolutePidl);
      DisposePidl(AAbsolutePidl);
    end
    else
      if not IsFolder then
        AItemInfo.IconIndex := TdxShellItemHelper.GetQuickIconIndexByName(Name);
    UpdateItem(AItemInfo);
  finally
    Updating := False;
  end;
end;

Using this patch, our dialogs do not display any custom overlay icons but we can live with that restriction.

More importantly, our application does not crash anymore on 3rd party applications.

Let's knock on wood, that DevExpress finds a better solution for this issue in one of their future releases.

[Anders Melander 2203]

IMO the usability of the DevExpress common file dialogs are horrible *. As a user (which I am when I use their components at design-time), I would much prefer the unskinned OS dialogs.

 

*) Try this: In a file open or save dialog, enter something into the search box. The file pane displays the search result. Now try to get back to the regular file list... Nope; You can't.

Bonus suckage: The dialogs doesn't respect the Explorer folder settings. For example, I have Explorer setup to expand the folder pane to the current folder. The common dialogs follow this setting. The DevExpress dialogs don't.

[Alexander Halser 34]

39 minutes ago, Anders Melander said:

IMO the usability of the DevExpress common file dialogs are horrible *. As a user (which I am when I use their components at design-time), I would much prefer the unskinned OS dialogs.

What can I say, you are absolutely right  And the save dialog does not change the file extension when the user changes the file filter. There is plenty of room for improvements and yes, we are aware of these limitations. We reported them to DevExpress and as far as possible, we have implemented our own functionality on top of their dialogs. This made it even more trickier to debug and find the freeze problem because we had to deal with several variables.

 

However, we use several dialogs with custom dialog extensions (an extra panel at the bottom or on the side). When injecting such an extension into a classic TOpenDialog, Windows invariably switches to old style dialogs, not the modern Explorer style. We wanted to get rid of them and offer a unified experience.

 

And the custom ad-hoc file previews are very nice - the alternative would be to add file preview handlers at system level. That's certainly doable, but makes admin installation mandatory, which we'd like to avoid.

Edited Wednesday at 08:01 PM by Alexander Halser

[John R. 20]

We've also experienced similar problems. Another 3rd party software which is problematic on a end user's computer is "Fabasoft Folio Client".

Your patch could be easily converted to an option by DevExpress: we could live without that feature too. Do you have a public open support request with DevExpress so that we could favorite it to add weight to this request ?

[dwrbudr 12]

JAM Shell Controls work better from my experience. We're using tree views and list views with overlay icons without any issue (apart from DPI ones).

[pyscripter 891]

There is also the free pyscripter/MustangpeakVirtualShellTools: Windows Explorer style shell treeview and list view components for Delphi and C++Builder applications.

[Alexander Halser 34]

3 hours ago, John R. said:

Do you have a public open support request with DevExpress so that we could favorite it to add weight to this request ?

No, it's private. I discussed a compiler option or public variable with them, but there was no clear response to this.

That's why I posted the issue here. It can't be just us, it's a matter of time that this problem invariably arises.

And it might take a while for a developer to realize that their trial version crashes on prospective customers at the first attempt to open a file.

Edited Thursday at 01:14 PM by Alexander Halser

[Anders Melander 2203]

1 hour ago, dwrbudr said:

JAM Shell Controls work better from my experience. We're using tree views and list views with overlay icons without any issue (apart from DPI ones).

The version of Shell Controls I have is very old and I've never used it (except for the breadcrumb control, which I wrote), but I can see from the source that they fetch file details such as the overlay image in a background thread - and handle failures.

 

1 hour ago, pyscripter said:

There is also the free pyscripter/MustangpeakVirtualShellTools: Windows Explorer style shell treeview and list view components for Delphi and C++Builder applications.

...and this doesn't.

 

53 minutes ago, Alexander Halser said:

but there was no clear response to this.

Yes, it's unfortunately become very hard to get them to commit to fixing bugs and deficiencies lately. Even if you provide them with a reproducible test case and explain exactly what the problem is and how to fix it.

I'm generally pretty satisfied with DevExpress but the amount of bugs or other flaws I've had to work around (on average one each week) is a bit tiring. Mostly because they likely wouldn't get fixed even if I reported them.

[pyscripter 891]

2 hours ago, Anders Melander said:

...and this doesn't.

It does, optionally in a background thread.

[Anders Melander 2203]

1 hour ago, pyscripter said:

optionally in a background thread

Yes, you are right. I don't know how I missed that.