News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Unusual problem loading a list view control.

Started by hutch--, March 31, 2011, 12:36:58 PM

Previous topic - Next topic

hutch--

I confess to being a bit rusty with a few of these later controls but I have a test piece set up as report view with 3 columns that I load a directory file list into. Do the normal FindFirstFile() FindNextFile() and it gets all the file names fine but I am also getting the file size and file date from the same structure to load the second and third column's of the list view control. Most of the time it works OK but every so often the second and third columns don't display anything and its mainly file names that have an underscore in them.

Now I can change that behaviour by changing the "*.*" file pattern to something like "*_*.*" which will then display the file name, size and date for files that have that pattern but then it does not load files with a different pattern.

As best as I can tell its a problem with the search pattern being fed to FindFirstFile(). has anyone ever seen a problem like this one before ?
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

Tedd

I wouldn't expect FindFile to mess up selectively. It could possibly omit details if you don't have access-rights to those files, but then it shouldn't work with a more specific search-pattern either.
I'd check first whether it's actually getting all of the details - output rows to a text file instead, and see if it's all correct.
If so, then it's something about the way you're inserting them into the listview.
No snowflake in an avalanche feels responsible.

hutch--

This is the algo that loads the list view. It is set as a report view with 3 columns.

I did a test with one text file that was not having its details displayed, "bmlog.txt" which worked fine. "b_mlog.txt" and "bm_log.txt" both failed but as the underscore went further right it started to work again. I confess I have never seen this effect before with FindFirstFile() and FindNextFile(). You can alter the effect by chaning the search pattern to "*_*.* so I have a sneaking suspicion that the search pattern as "*.*" is not being parsed properly internally and blanking the 2 structure members that have the size and date.

The function call is simple enough,

            fn load_list_view,hLview,"c:\","*.*"



; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

load_list_view proc hlview:DWORD,ppath:DWORD,ppatn:DWORD

    LOCAL pbuf1 :DWORD
    LOCAL pday  :DWORD
    LOCAL pmonth:DWORD
    LOCAL pyear :DWORD

    LOCAL buffer1[260]:BYTE     ; general purpose buffer

    LOCAL hSch  :DWORD
    LOCAL wfd   :WIN32_FIND_DATA
    LOCAL lvii  :LV_ITEM
    LOCAL syst  :SYSTEMTIME

    push esi
    push edi
    xor esi, esi                ; ESI is the list view item counter

    fn SendMessage,hlview,LVM_DELETEALLITEMS,0,0
    fn SendMessage,hlview,WM_PAINT,0,0
    fn SendMessage,hlview,WM_SETREDRAW,FALSE,0

    invoke SetCurrentDirectory,ppath

    mov hSch, rv(FindFirstFile,ppatn,ADDR wfd)
    test eax, eax
    jz quit
    jmp process

  findnext:
    invoke FindNextFile,hSch,ADDR wfd
    test eax, eax
    jz quit

  ; -----------------------
  ; exclude all directories
  ; -----------------------
  process:
    switch wfd.dwFileAttributes
      case FILE_ATTRIBUTE_DIRECTORY
        jmp findnext
      case FILE_ATTRIBUTE_DIRECTORY or FILE_ATTRIBUTE_HIDDEN
        jmp findnext
      case FILE_ATTRIBUTE_DIRECTORY or \
           FILE_ATTRIBUTE_HIDDEN or FILE_ATTRIBUTE_SYSTEM
        jmp findnext
      case FILE_ATTRIBUTE_DIRECTORY or FILE_ATTRIBUTE_HIDDEN or \
           FILE_ATTRIBUTE_SYSTEM or FILE_ATTRIBUTE_READONLY
        jmp findnext
    endsw

    invoke FileTimeToSystemTime,ADDR wfd.ftLastWriteTime,ADDR syst
    movzx eax,  syst.wDay
    mov pday,   ustr$(eax)
    movzx eax,  syst.wMonth
    mov pmonth, ustr$(eax)
    movzx eax,  syst.wYear
    mov pyear,  ustr$(eax)

  ; ------------------------------------------------------
  ; write filename, filesize and date to list view control
  ; ------------------------------------------------------
    mov lvii.imask, LVIF_TEXT
    lea edi, wfd.cFileName
    mov lvii.pszText, edi
    mov lvii.iItem, esi
    mov lvii.iSubItem, 0
    fn SendMessage,hlview,LVM_INSERTITEM,0,ADDR lvii    ; ---------- file name

    mov pbuf1, ptr$(buffer1)
    mov lvii.pszText, cat$(pbuf1,ustr$(wfd.nFileSizeLow)," bytes")
    mov lvii.iItem, esi
    mov lvii.iSubItem, 1
    fn SendMessage,hlview,LVM_SETITEM,0,ADDR lvii       ; ---------- byte count

    mov pbuf1, ptr$(buffer1)
    mov lvii.pszText, cat$(pbuf1,pday,":",pmonth,":",pyear)
    mov lvii.iItem, esi
    mov lvii.iSubItem, 2
    fn SendMessage,hlview,LVM_SETITEM,0,ADDR lvii       ; ---------- last write date
  ; ------------------------------------------------------

    add esi, 1
    jmp findnext

  quit:
    invoke FindClose,hSch

    fn SendMessage,hlview,WM_SETREDRAW,TRUE,0

    pop edi
    pop esi

    ret

load_list_view endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

hutch--

#3
The plot thickens, I added the test code to show the output in a text file and all of the data that is missing shows up in the text file so it has to be a problem in the loading of the listview control.

LATER : Novel solution, removing the LVS_SORTASCENDING style removed the problems. It was showing signs of memory overwriting as moving the structures around in memory changed the errors that were occurring.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

lingo

1. Change test eax, eax with cmp eax, -1 after FindFirstFile
2. try with "*" instead "*.*"  :P

Tedd

LVS_SORTASCENDING/DESCENDING is buggy.
Send LVM_SORTITEMS after inserting all of your items - it requires you to provide your own comparison function.
No snowflake in an avalanche feels responsible.