ExplorerTreeView 1.12.0

Post by **TiKu** » 12 Aug 2006, 00:14

Almost six months have passed since the last update of ExplorerTreeView and the first Release Candidate of Windows Vista is knocking on the door. So it's time to bump ExplorerTreeView to the future.
ExplorerTreeView 1.12.0 brings you Vista compatibility and two new Vista-only features. Another two features were added as requested in the forum and by mail, respectively. But that's not all. I've removed BkImage support as it caused headaches over headaches and nobody seems to have used it anyway. While doing so, I rewrote some features that use custom draw making them more performant and less buggier.
Last but not least I fixed two very complex crashes. To fix one of them, I had to slightly adjust the behavior of the RootPath property. The old behavior was, that the new path was applied to the tree immediatly. This could interrupt AutoUpdate which could lead to the situation that either the RootPath property or AutoUpdate deletes an item that the other of both features tried to access afterwards resulting in a crash. So the new behavior is, that the RootPath property posts a private message with the new path to the control window's message queue. This way it can't happen that AutoUpdate and root path changing is done at the same time.
But this also means, that now there's a delay between setting the RootPath property and applying this new path to the tree. It may be possible that you have to change your code because of this.

I won't have any time for coding at least until September, but the last thing I've been working on was the EditControls library. It's a control library containing a TextBox, an UpDownTextBox, a HotKeyBox and an IPAddressBox. It's about 60% complete.

Looks like I'm writing novels again, so I'll shut up now. Enjoy the new release. Oh, I almost forgot to tell you, the samples have been updated, too.

[Download] [Samples] [Changelog]

WoF · Post by **WoF** » 14 Aug 2006, 11:53

Hi TiKu,

has anything changed for me? Do I have to update? It was the 1.12.0 build 800 you made for me preliminary.

Post by **TiKu** » 14 Aug 2006, 12:10

It's exactly the same build that you have.

WoF · Post by **WoF** » 14 Aug 2006, 15:29

Great. Thanks again.

WoF · Post by **WoF** » 16 Aug 2006, 12:19

Again, there is a question:
If for some reason I have to step back to an earlier version of my app which uses ExTvw 1.10.0, what am I to do? Do I have to copy the old .ocx to the system32 folder and regsvr32 it? Do I have to unregister the newer .ocx first?

Reason is, I have an update system which keeps a backup of the files of the previous program version. If an unexpected error in the new version occurs, the user can switch back to the previous version to continue.
Last time when I upgraded ExTvw from an earlier version to 1.10.0 I had problems to go back. I was not able to regsvr32 the older version again. (Luckily it was not necessary).

Post by **TiKu** » 16 Aug 2006, 12:42

I'm not entirely sure, but I think when downgrading you first have to unregister the version you want to replace. At least it would not be amiss.
Another pitfall is, that an application that was compiled with version y of a control won't run with an older version x of that control without recompiling the app - even if version y of the control was compiled as being compatible to version x.
In other words: You can't downgrade an ActiveX control without recompiling the app; only upgrading without recompiling works (if the ocx supports it).

WoF · Post by **WoF** » 16 Aug 2006, 17:42

What I'm doing when downgrading is:
1. replacing my app.exe with the older version (compiled with the older ocx).
2. unregister the new ocx
3. register the old ocx

Problem is, I tried it this afternoon and it worked.
I tried it again and it didnt.

In the moment I try to come back to 1.10.0. It says registration was successful, but I cannot even load it into VBs component selection.
I'm really confused.

Post by **TiKu** » 16 Aug 2006, 17:59

VB6 sometimes messes up the registry entries. I guess you're a victim of this problem. In this situation the only working solution I know of, is removing all registry entries, that have something to do with any version of the control, by hand and re-register the version you want to use.
In the registry, search for ExTvw and ExplorerTreeView and delete the keys it finds.

WoF · Post by **WoF** » 17 Aug 2006, 12:46

No. Sorry. Got it fixed now.
You HAVE to unregister when downgrading to the previous version. Running regsvr32 did the job, so I found the bug in my program which did not complain the failure to unregister.
All right now.