Adventures in programming: Treeviews, directory scanning, recursion

[zedd151]

Since no one else supplied a easy 32 bit masm32 example... with only the needed code
Easy peasy

A simple dialog box with a marquee type of progress bar.

The progress bar placement, etc.,  courtesy TimoVJL's... c example. I simply plugged in two lines of his code into my template.

NoCforMe is correct, no INITCOMMONCONTROLSEX needed, nor InitCommonControls it appears.

Tested only on Windows 7, need feedback on Windows 10/11, or even xp...

Code Select Expand

    include \masm32\include\masm32rt.inc
        DlgProc    proto :dword, :dword, :dword, :dword

    .data
        hWnd        dd 0
        hInstance  dd 0
        DisplayName db "Dialog Box", 0

    .code
    start:
        invoke GetModuleHandle, 0
        mov hInstance, eax
        invoke DialogBoxParamA, hInstance, 1000, 0, addr DlgProc, 0
        invoke ExitProcess, eax

    DlgProc proc hWin:dword, uMsg:dword, wParam:dword, lParam:dword
    local rct:RECT, hProcessBar:dword
      .if uMsg == WM_INITDIALOG
        mov hProcessBar, rv(GetDlgItem,hWin, 4001)
        invoke SendMessageA, hProcessBar, PBM_SETMARQUEE, TRUE, 30
      .elseif uMsg == WM_COMMAND
      .elseif uMsg == WM_CLOSE
        invoke EndDialog, hWin, 0
        xor eax, eax
        ret
      .endif
        xor eax, eax
        ret
    DlgProc endp

    end start
Slight update. mov eax, 1 and ret not needed in WM_INITDIALOG  removed from code.
I said I would get back to this yesterday, but real life interfered.

Example replaced in This thread a more polished example. Attachment removed

[TimoVJL]

Things seems to changed in NT era.
Progressbar don't even need commctrl32.dll, so manifest is useless in that case too.

[zedd151]

Things seems to changed in NT era.
Progressbar don't even need commctrl32.dll, so manifest is useless in that case too.

Thanks for the tip. 

Nevermind. Read following posts...

[TimoVJL]

Things seems to changed in NT era.
Progressbar don't even need commctrl32.dll, so manifest is useless in that case too.

Thanks for the tip. 

Forgot to test, as i didn't renamed local manifest file, so that was still needed with Windows 7.

[zedd151]

You're right TimoVJL, I just tested without manifest... didn't work.

[zedd151]

a little more testing...

invoke SendMessageA, hProcessBar, PBM_SETMARQUEE, TRUE, 30

lParam sets the speed of the animation. higher = slower. zero = fastest.

[NoCforMe]

invoke SendMessageA, hProcessBar, PBM_SETMARQUEE, TRUE, 30

lParam sets the speed of the animation. higher = slower. zero = fastest.

Zero = default:

If this parameter is zero, the marquee animation is updated every 30 milliseconds.

You could make it faster by setting it to 30 > value > 0.

Anyhow. Your demo proves that we absolutely do not need to mess around with timers to make PBM_SETMARQUEE work, so let's just drop that, OK?

There's still some confusion over the XML manifest and calling InitCommonControlsEx(). I have that manifest included in my resource file, as it gives me the Vista-like "visual styles" (otherwise you get the boxy square controls). But what I still insist is not needed is the call to InitCommonControlsEx(). I've been writing programs for the past several years without using that, and they all work fine (at least as control rendering and processing goes).

[NoCforMe]

The second, a bit more serious

Code Select Expand

(37f4.461c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=6e020f93 ebx=6e020f93 ecx=0003ba50 edx=00000000 esi=00a21145 edi=001404a2
eip=00a235bb esp=006fedd0 ebp=006fedd8 iopl=0        nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b            efl=00210206
PicView!PruneFileList+0x5b:
00a235bb f7831401000010000000 test dword ptr [ebx+114h],10h ds:002b:6e0210a7=????????

; Prune back the chain until we find a folder w/pictures:
    MOV    EAX, [EBX].FILEINFO.parent
    TEST    EAX, EAX            ;Hit the root?
    JZ    next                ;  Yep, go to next prev. entry.
    ADD    EAX, FileHeap
    MOV    EBX, EAX
    TEST    [EBX].FILEINFO.flag, $keep ;<<<<<< crash <<<<<<


Dang.
I wish I could replicate this on my system, I really do. Since fixing that CloseFindHandle() problem I've had zero crashes or faults, so it's very difficult for me to say how this is happening.
I'll keep looking into it, though.

Ditto for that weird problem you're having with the select-folder dialog; I've never seen that happen. What OS are you running?

[TimoVJL]

There's still some confusion over the XML manifest and calling InitCommonControlsEx(). I have that manifest included in my resource file, as it gives me the Vista-like "visual styles" (otherwise you get the boxy square controls). But what I still insist is not needed is the call to InitCommonControlsEx(). I've been writing programs for the past several years without using that, and they all work fine (at least as control rendering and processing goes).

That InitCommonControlsEx() isn't needed, as that control doesn't even need comctl32.dll in Windows 7
Some controls have moved silently to other dlls.
Perhaps some OllyDbg users check that dll thing.
Some controls needs a reference to comctrl32.dll in some cases, but Progressbar don't.

[zedd151]

So, NoCforMe...

Did you get it working in your program??

[NoCforMe]

So, NoCforMe...
Did you get it working in your program??

No! What would give you that idea?

[zedd151]

So, NoCforMe...
Did you get it working in your program??

No! What would give you that idea?

Just asking, jeez.

Have you tried calling SendMessage in a different manner than in your program? Or from a different location.
Is the handle somehow getting overwritten?

Just want to help you debug this thing. Gotta be something simple...methinks.

[sinsi]

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 

The select folder happens for any program that uses the old-style dialog, not just yours.

Edition    Windows 11 Pro
Version    23H2
OS build 22631.3447

[zedd151]

Something weird is happening...

I changed the code to always show the progress bar (from just getting the handle from eax), and hide the others next to it.
The bar displays but does not animate, and it should.

Code Select Expand

    INVOKE    GetDlgItem, hWin, $progbar
    MOV    ProgressBarHandle, EAX
    INVOKE    SendMessage, ProgressBarHandle, PBM_SETMARQUEE, TRUE, 0
    INVOKE    ShowWindow, ProgressBarHandle, SW_SHOW
Now scroll the window closed from the bottom then open it.
A frozen animation should now appear... it did for me. I repeated this several times to be sure.

Somehow it is not getting painted properly
attachment no longer needed - removed

[NoCforMe]

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