Fails to descend/recurse into subdirectories (VS 2013)

[avogelba]

Originally reported by: Samuel Bronson (Bitbucket: samb, GitHub: samb)

---

When I build windirstat with VS 2013, it fails to descend into subdirectories; furthermore, the "ASSERT(child->TmiGetSize() > 0);" in treemap.cpp triggers. I tried to bisect to find when it broke, but I ended up at the fix for issue #77 :-(.

I'm using the Community edition, but it seems unlikely that this is related to the problem, as I don't appear to get any more extra warnings or anything (just the ones about GetVersionExW being deprecated and about defaultlib 'LIBCMT' conflicting with use of other libs).

I haven't tried building with other versions of VS, partly because I don't have any others that come with MFC, but the release binaries work fine.

---

• Bitbucket: https://bitbucket.org/windirstat/windirstat/issue/133

[avogelba]

Original comment by Oliver (Bitbucket: assarbad, GitHub: assarbad):

---

@fpeijnenburg sounds great.

Didn't see the other comment before, @d-p. The current idea is actually to require a populated SQLite3 database. Of course the idea about ls -lR (zipped or not) also has its merit.

[avogelba]

Original comment by Falco Peijnenburg (Bitbucket: fpeijnenburg, GitHub: Unknown):

---

Little update on the optimisation: we managed to get (about) a 4x increase in rendering the CTreeView already. More work will be done.

[avogelba]

Original comment by d-p (Bitbucket: d-p, GitHub: d-p):

---

First of all thanks for all the hard work on winDirStat—it’s an awesome utility. I keep installing it on every PC I meet. One feature I’d like is an ability to load a zip file of “ls –lR” output. We could use this to examine dumps created from remote {unix/mac/win/ios/android} machines, or look at historical data on local machine.
If there’s interest the location below has a proposed implementation of the file-loading gui:

https://bitbucket.org/d-p/windirstat-fork

[avogelba]

Original comment by Oliver (Bitbucket: assarbad, GitHub: assarbad):

---

@tincann yep, that would be at the respective tag (VS 2003 solution and projects, though) ... https://bitbucket.org/windirstat/windirstat/commits/tag/Release_1_1_2

Keep in mind that several changes are required to get it even to build on VS 2005 or newer, because of MFC changes (some prototypes etc).

[avogelba]

Original comment by Morten Asscheman (Bitbucket: tincann, GitHub: tincann):

---

@assarbad Do you happen to know which commit contained the working program, as it can be downloaded from the website (WinDirStat 1.1.2)?

[avogelba]

Original comment by Oliver (Bitbucket: assarbad, GitHub: assarbad):

---

@fpeijnenburg Right now I'd say just about any improvements are welcome.

I know that Alexander (from altWinDirStat which can be found on GitHub) had found out that the MFC/ATL strings were a problem performance-wise, so I was also going to swap them for std::string and friends. I also intend to bind to Python in order to provide some of the features people had asked for (like customizable reports etc, was thinking of MHT/MAFF there) as well as hooks - potentially. Otherwise hooks are planned to use the LuaJIT that can already be found in the source tree. Configuration is supposed to be handled by Lua code (for both the registry and an INI file). Translations need an overhaul (easier to translate for those wishing to localize, but it requires certain changes to the dialogs in order to make them customizable without having to change each resource individually). The email feature is already removed and will not come back. I intend to improve how it can be used from the command line etc. If anyone wants to take up any of these things, please lets coordinate, but otherwise knock yourself out. It'd be awesome to see contributions from others! :)

btw: if you want me to build and code-sign a version (even prototypes) for which a revision exists in the official repository I will happily do so. I just can't sign what I don't build myself :)

[avogelba]

Original comment by Falco Peijnenburg (Bitbucket: fpeijnenburg, GitHub: Unknown):

---

@assarbad Oh no, it's definitely not the amount of time you put into the project. That's your decision and/or situation and I respect that. My only point of criticism is that this state presents a hurdle for anyone wanting to contribute. That aside I'm glad the program is at least in a workable state. We can work with this.

Since we're going to optimise it, we'd like to know if there are going to be any structural changes that we should consider when optimising the code. It would be a shame if our optimisations get denied a merge because they totally doesn't fit your plans with the program.

[avogelba]

Original comment by Oliver (Bitbucket: assarbad, GitHub: assarbad):

---

@fpeijnenburg Yes, there are plans to release a future version and you correctly observe that the program is in a "very odd state" when built from default.

Pull requests are certainly welcome, but I'm not sure what you are questioning here. That I'm not spending enough spare time on the project?

[avogelba]

Original comment by Falco Peijnenburg (Bitbucket: fpeijnenburg, GitHub: Unknown):

---

Well the fix works, but the program is still in a very odd state: http://i.imgur.com/7cuKVAz.jpg

@assarbad A buddy and I would like to use this program for an optimisation course, I'd also love to turn the changes we make into a pull request. However, the state of the master branch and your comments about it only being compiled by those "with the technical knowledge" make me question what the future goals of the project are. Are there any plans to release future versions?

[avogelba]

Original comment by Oliver (Bitbucket: assarbad, GitHub: assarbad):

---

The default branch is not really ready for use. Since it's not been released in any way and Windows software tends to not be compiled except by a few folks with the technical knowledge, I didn't see an issue with that.

@d-p sent a pull request, which I merged. The first ever pull request I received on this project. Thanks for that!

[avogelba]

Original comment by d-p (Bitbucket: d-p, GitHub: d-p):

---

made a temporary fork that kind of works:

https://bitbucket.org/d-p/windirstat-fork

somthing in item.cpp is pressing the SetDone() button too soon, so loop exists on first pass through directory without descending any subdir. treemap problem was just suppressed with WEAK_ASSERT

[avogelba]

Original comment by Falco Peijnenburg (Bitbucket: fpeijnenburg, GitHub: Unknown):

---

I've tried bisecting myself, and every build that doesn't have missing file errors does seem to have the same issue.

[avogelba]

Original comment by Falco Peijnenburg (Bitbucket: fpeijnenburg, GitHub: Unknown):

---

Confirmed with VS 2015 Enterprise and the VS2013 solution.

Edit: Also, with VS 2012 and the VS2012 solution. This problem doesn't seem solution specific. It looks like the head revision is simply broken.