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]
ExplorerTreeView 1.12.0
ExplorerTreeView 1.12.0
Crunching for Fab36_Folding-Division at Folding@Home. Join Fab36/Fab30! - Folding@Home and BOINC
Boycott DRM! Boycott HDCP!
Boycott DRM! Boycott HDCP!
It's exactly the same build that you have.
Crunching for Fab36_Folding-Division at Folding@Home. Join Fab36/Fab30! - Folding@Home and BOINC
Boycott DRM! Boycott HDCP!
Boycott DRM! Boycott HDCP!
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).
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).
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).
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).
Crunching for Fab36_Folding-Division at Folding@Home. Join Fab36/Fab30! - Folding@Home and BOINC
Boycott DRM! Boycott HDCP!
Boycott DRM! Boycott HDCP!
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.
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.
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.
In the registry, search for ExTvw and ExplorerTreeView and delete the keys it finds.
Crunching for Fab36_Folding-Division at Folding@Home. Join Fab36/Fab30! - Folding@Home and BOINC
Boycott DRM! Boycott HDCP!
Boycott DRM! Boycott HDCP!