Memory leak?

[Dan Ritchie]

I have written two programs now that use the treeview control. I have sporadically experienced lockups for periods of several seconds to maybe 30 seconds. As this is happening, I can see that the processor usage goes up to 99%, and I can see the memory steadily increasing. I've seen it go up to 100 megs of memory.
Removing the treeview from the progam, leaves the memory usage steady, so I have a reasonable conclusion anyway.
These lockups happen durring, or right after creating new files. These are programs that call an external application that converts images to different formats. I've monitored the external application and have seen no unusual behaviour from it.

[TiKu]

Hi,

this looks like a problem with the AutoUpdate code. Those problems usually are very difficult to fix. I guess the control somehow ends up in a loop of redundant searches for new items to display.
I need some more details:
1) When this happens, how many files did you create and in which time span?
2) What's the path of the folder in which you create the files?
3) Does it happen when the treeview contains many items (many expanded folders)?
4) Could you please open one of the treeview's property pages and safe the control's settings into an exctlsf-file using the button with the floppy icon and attach this file here or send it to me via mail?

And last but not least: Which operating system are you using? AutoUpdate sometimes works very different on different versions of Windows.

TiKu

[Dan_Ritchie@hotmail.com]

I'll have more information a little later.

Right now, I appear to be having the problem in what ever directory I am browsing. It usually happens after I have created a group of files (anywhere from none to hundreds) It doesn't happen when I am not creating files. The files that are being created are being added to a temp directory, which is not being browsed. They are not being added to the directory that I'm browsing.

[Dan_Ritchie@hotmail.com]

I guess a good question would be if it is possible to dissable the autoupdate to see if that solves the problem?

[TiKu]

Windows' shell notifications are a big mess. Usually Windows sends the ExplorerTreeView window a SHCNE_CREATE notification with the created file's path in the message's parameters. However, if you create many files at once, Windows will group those notifications into a single SHCNE_UPDATEITEM with the Desktop's pIDL as parameter. In this case all ExplorerTreeView knows about the changes is "something changed somewhere". Because of that lack of information it refreshes its entire content.
I guess the control receives several SHCNE_UPDATEITEM notifications and therefore refreshes its content several times. A single complete refresh is time-consuming, take let's say 10 of them and you've the lockup you're experiencing.

Yes, there's a way to disable AutoUpdate. It's not public, because the control isn't designed to handle items that don't really exist anymore. So to avoid people deactivating AutoUpdate and complain about resulting bugs, there's no simple property for this. Instead you've to use the following code:

Code: Select all

  Private Const WM_USER = &H400
  Private Const EXTVM_SETAUTOUPDATE = (WM_USER + 20)

  Private Declare Function SendMessageAsLong Lib "user32.dll" Alias "SendMessageA" (ByVal hWnd As Long, ByVal MSG As Long, ByVal wParam As Long, ByVal lParam As Long) As Long

  Dim disableAutoUpdate As Boolean
  Dim previousSetting As Boolean

  ' we want to disable AutoUpdate
  disableAutoUpdate = True

  previousSetting = SendMessageAsLong(ExTvw.hWnd, EXTVM_SETAUTOUPDATE, CLng(Not disableAutoUpdate), 0)

I'll try to implement some code that groups SHCNE_UPDATEITEM notifications to one single content refresh, if they're received within a short time span.

TiKu

[Dan_Ritchie@hotmail.com]

If I dissable the autoupdate, would it be possible to still refresh the control once after I have created all of my files with something like treeview1.refresh ?
Would that cause the entire treeview to refresh? I had been using a simple listview control previously, and that's all I did after my files were created to insure that they showed up.

[TiKu]

There're 2 methods: ReloadItems() and ReloadSubItems(). ReloadItems() deletes all items and loads them from scratch. Advantage: It's fast and you can be sure that there're no zombie items left. Disadvantage: It reselects the currently selected item, but doesn't restore other item states like checkmarks or expansion states. Let's say you've the following content (C:\ is selected):

Code: Select all

Desktop
|-- My Computer
     |-- C:\
          |-- Programs
          |-- Windows
     |-- D:\
          |-- Some folder
     |-- E:\
|-- Network Neighborhood
     |-- Entire Network

After calling ReloadItems(), it will look like this (C:\ is still selected):

Code: Select all

Desktop
|-- My Computer
     |-- C:\
          |-- Programs
          |-- Windows
     |-- D:\
     |-- E:\
|-- Network Neighborhood

You see what I mean? ReloadSubItems() does the same for a specific branch of the tree.
AutoUpdate is less radical. It validates each item, removes non-existent items and inserts new ones.
If you want, I could insert a line of code, that refreshes the control's entire content if AutoUpdate gets reactivated. This way all you'd have to do is reactivate AutoUpdate after all files got created.

You shouldn't disable AutoUpdate the whole time, because the control isn't designed for such cases and may behave strange. At least I've never run larger tests with such conditions.

[Dan_Ritchie@hotmail.com]

Ok, good news and bad news.

I've found a way to reliable cause the problem, by ejecting or inserting my keychain memory stick.

Bad news is I still have the problem after dissabling autoupdates with the code you provided. Is there a way to test if the setting has been set properly?

When I insert or eject the drive, the task assumes 99% processor usage, and memory starts to grow. After a set of inserting and ejecting, memory usage for the task is at around 45 megs up from 12, and it doesn't go back down.

[TiKu]

I've found a way to reliable cause the problem, by ejecting or inserting my keychain memory stick.

WTF? I've absolutely no idea why this should cause such trouble - especially with AutoUpdate disabled. Maybe you're reactivating AutoUpdate too early. The SHCNE_* notifications are a little bit delayed. If you have not done before, try to disable AutoUpdate on application startup and don't reactivate it. If the problem is still there then, it's not related to AutoUpdate.

Bad news is I still have the problem after dissabling autoupdates with the code you provided. Is there a way to test if the setting has been set properly?

Some kind of. The return value of SendMessageAsLong is the previous setting. Note that the EXTVM message is called SETAUTOUPDATE and not DISABLEAUTOUPDATE. That's why you've to pass 0 instead of 1 in wParam to disable AutoUpdate.
Well, back to the return value: If AutoUpdate previously was disabled, SendMessageAsLong will return 0 and 1 if it previously was enabled. So the following code should disable AutoUpdate and print a 1 followed by a 0 into the debug window:

Code: Select all

Debug.Print SendMessageAsLong(ExTvw.hWnd, EXTVM_SETAUTOUPDATE, 0, 0)
Debug.Print SendMessageAsLong(ExTvw.hWnd, EXTVM_SETAUTOUPDATE, 0, 0)

Another way to test whether AutoUpdate is enabled, is to open the properties of a folder that the control is displaying and change the 'Hidden' attribute for this folder (only for the folder, not for its content). If the ShowHiddenDimmed property is set to True, the icon should get blended with the control's background color. If AutoUpdate is disabled, nothing should happen.

I tried to reproduce the problem on my computer with all memory sticks and MP3 players I have - ExplorerTreeView runs just fine here. :dontknow:

[Guest]

Let me give that a try.

BTW, what version are you running, and which one do you recomend?

[TiKu]

Version 1.9.0 RC1 and version 1.9.0 RC1.
I'll go to bed now. CU

[Guest]

I found another clue, I suppose. I am setting the path to the 'my documents' folder when the form is loaded. When I take this out, the problem goes away (as far as I can tell). I don't know what to make of it.

[TiKu]

Although this shouldn't cause such trouble, you may set the Path property to "Eigene Dateien" or "Eigene Dateien (Ordner)" during design time and see if the problem's still there.

[Dan_Ritchie]

I have a simple project demonstrating the problem. I have hard coded the directory on the form startup, so you will have to change it to your own 'my documents' location. If I'm not mistaken, that is the only code I have added to this.

www.squirreldome.com/temp/MemoryLeak.zip

When running the project, I monitor the memory and processor usage with the task manager.
While mounting or unmounting a usb drive, the cpu usage goes up to 99% for around 10-20 seconds, and the memory grows and doesn't get released, even when going back to the design environment.

[TiKu]

I'm still not able to reproduce this behavior. However, see the attachement. It contains your project, build 627 of ExTvw and a Delphi program.
I've modified the VB6 project, so that it disables AutoUpdate to exclude it as the source of the problem.
Build 627 (a.k.a. 1.9.0 RC1a) of ExTvw differs from build 626 (1.9.0 RC1) in one thing only: I've un-implemented a bugfix. The bugfix was introduced, because too many items were handled as "slow items". Slow items are accessed as seldom as possible (e. g. they are not checked for sub-items and always have a "+"), because access to them is very slow. However, my bugfix caused that too few items were handled as "slow items", so the control could slow down extremely and show annoying error messages. Until I find a real fix for the "slow items" thing, my current "bugfix" will remain deactivated.
The Delphi program uses a Delphi component similiar to ExplorerTreeView. I wonder whether this component will show the same behavior as ExplorerTreeView, so please test it. I'll ask the author of this component whether he ever came across such a problem like you're experiencing.