Adventures in programming: Treeviews, directory scanning, recursion

[zedd151]

Now that is interesting, and certainly related to what's happening to my program. Will look at it shortly.

[NoCforMe]

OK, tracked down the crash

Code Select Expand

    INVOKE    strcpy, ADDR [EDX].FILEINFO.pathName, ADDR [EBX].FILEINFO.pathName
    INVOKE    _strcat, OFFSET BackslashStr, ADDR [EBX].FILEINFO.pathName
    INVOKE    _strcat, OFFSET FD.cFileName, ADDR [EBX].FILEINFO.pathName
;*** added ***
lea eax,[EBX].FILEINFO.pathName
call strlen
cmp eax,MAX_PATH
jbe @f
 int 3
@@:
;*************
Run in the debugger, stops at the breakpoint with EAX=0115 (277, well over MAX_PATH)
This overwrites some pretty important data in your structure 

Aha, so it's basically an overlength pathname somewhere in your directory structure, that apparently I don't have on any of my drives.

You don't happen to know the actual pathname that's causing this, do you?

I suppose that your fix is all that can be done at this time to avoid this. Otherwise I'd have to increase the size of all my pathname buffers, further increasing my already large memory requirements. (Which raises the question: how long should the longest expected pathname on a Windows file system be? Apparently MAX_PATH isn't sufficient always.)

[zedd151]

from codeguru

Re: PBM_SETMARQUEE (Marquee Animation) not working for Progressbar?!?
Actually i figured it out...Turns out since i had the progress bar as a resource instead of using the CreateWindowEx(..) i had to use SetWindowLongPtr(..) to set the PBS_MARQUEE style for this control...now it works  Yipeee to me!

worth a try??? But actually, it doesnt make sense. It worked in my example without any acrobatics... so nevermind.
Not a lot of information out there regarding this kind of issue.

[zedd151]

oops. quoted above post, instead of modify post..   

[NoCforMe]

from codeguru

Re: PBM_SETMARQUEE (Marquee Animation) not working for Progressbar?!?
Actually i figured it out...Turns out since i had the progress bar as a resource instead of using the CreateWindowEx(..) i had to use SetWindowLongPtr(..) to set the PBS_MARQUEE style for this control...now it works  Yipeee to me!

worth a try???

No. Somewhere up there I mentioned that I explicitly checked to see that this style was set in the progress bar control, and indeed it was. Got nothing to do with being a resource or not. (It's true that the dialog manager does screw with some control styles, like removing borders that are explicitly set with WS_BORDER, but this isn't one of them.)

[sinsi]

You don't happen to know the actual pathname that's causing this, do you?

The path to the parent folder is 257 characters and a folder in the parent is 20.
I imagine that if you tried FindFirstFile on the full parent\folder\spec you would get an error.

Reparse points can be tricky too, if you follow the rabbit.


There used to be a nasty trick where Windows would let you create a path that was a real PITA to remove, a batch file with

Code Select Expand

:again
md x
cd x
goto again
or something similar.

[NoCforMe]

Reparse points can be tricky too, if you follow the rabbit.

So how do I identify one of those critters so I can avoid it?

When I was developing an earlier app (a file finder) that used a similar recursive technique, I ran across some files (or folders?) that either started with ":" or consisted only of that character (which of course is an illegal character outside of drive letter identifiers). Any idea what those were?

(That's why I filter out those things, whatever they are.)

[zedd151]

NoCforMe:

In the modified version of PicView that I attached above, in post #163 - if the program is in a folder that has images or that folder has a subfolder that has images in it, click on an image icon in the tree view. The animation starts up!!

I noticed this by pure accident.

I still haven't found what is causing this though.
Something in your program is interfering with the painting of the progress bar. I am tempted to remove all the other controls one by one, to see if any of them are causing this naughty misbehaviour.

[NoCforMe]

OK, I'm curious: what did you do to my program to make it do this odd thing?

Of course, it doesn't animate at the right time, but it does do the marquee thing for sure ...

[zedd151]

OK, I'm curious: what did you do to my program to make it do this odd thing?

Of course, it doesn't animate at the right time, but it does do the marquee thing for sure ...

Your program does the odd thing, by misbehaving in the first place.
See the code in #163. That is all I did, beside changing SW_SHOW to SW_HIDE for the other controls, to get them out of the way.

The modified source attached - 8 changes in the source, all marked ";;;;;;;;;;;;;;;;;; changed"
      This was done in an attempt to make the progress bar marquee animate.
     
attachment no longer needed - removed

[zedd151]

I think I found something...
In your (resource) include file:


Never mind. I tried it again (the inc file changes), but failed. No joy.    I'm done with this for now...
If I had the time and patience ( I have time, but little patience), I would comment everything out of the program except for the dialog box code and the progress bar code. Progress bar should be marqueeing then. Then little by little, introduce the other controls, and associated functions. Until the marquee stops working. I cant think of any other way to find the culprit.
I'll chew on some other ideas for a while... it is obvious that something in the code isn't playing nice with the progress bar.
I'll take another look at it tomorrow. You have a bigger issue with paths it seems.

[sinsi]

Reparse points can be tricky too, if you follow the rabbit.

So how do I identify one of those critters so I can avoid it?

When I was developing an earlier app (a file finder) that used a similar recursive technique, I ran across some files (or folders?) that either started with ":" or consisted only of that character (which of course is an illegal character outside of drive letter identifiers). Any idea what those were?

(That's why I filter out those things, whatever they are.)

There is a file attribute to show directory junctions and file links, FILE_ATTRIBUTE_REPARSE_POINT.
The colon character is used with NTFS streams.

[NoCforMe]

Thank you. They're now filtered out:

Code Select Expand

; Eliminate reparse point entries:
filter: TEST FD.dwFileAttributes, FILE_ATTRIBUTE_REPARSE_POINT
JNZ nxtfil


[zedd151]

I found something. Using a pristine (freshly extracted from your .zip file in post #146) "PicView package" folder, open the executable. Images must be in the folder where the program is located

1. click on any icon displayed in the file tree.  <--- it just works this way
2. Then choose a large folder or directory. (large so it takes some time, too small & bar won't display - takes very little time to process the list)
3. Then click 'Select'

voila! it works that way. Very similar to what I had found earlier, but no changes to the source code this time.
Its not the solution, but may give you a clue that you need to trigger the progress bar display elsewhere (or some other change).

I couldnt sleep, this was nagging me...

[NoCforMe]

Goldang, you're 150% right! For some really weird reason, that works!
Hmmm, scratching my head here ...

Thanks!

Somehow, selecting a picture to display at the get-go (that's what does it) somehow initializes things so the progress bar works. And it works every time after that.

Ackshooly, anytime you click on a pic, thereafter the progress bar works. Hmmmm ... something in the pic display proc, methinks ... perhaps something related to GDI+ ...