Menu

#293 Patch for bug #2896501 (Filenames limit with tk_getOpenFile)

closed-accepted
9
2010-05-20
2009-11-16
No

This is a proposed patch for bug Windows: Filenames limit with tk_getFileName -multiple 1 (https://sourceforge.net/tracker/?func=detail&aid=2896501&group_id=12997&atid=112997)

The patch allows to select virtually any number of files in tk_getOpenFile, because it dynamically allocates a buffer of required size to accomodate all selected files. The dialog itself will still return FNERR_BUFFERTOOSMALL, but the selected files are returned in custom buffer and can be retrieved.

Tested with Windows SDK "include" directory containing 1700+ files - all selected files were returned.

Discussion

  • Pawel Pawlak

    Pawel Pawlak - 2009-11-16

    proposed patch (HEAD)

     
  • Donal K. Fellows

    Looks reasonable to me, but I don't build on Windows much so I can't test.

     
  • Donal K. Fellows

    • priority: 5 --> 9
    • status: open --> open-accepted
     
  • Donal K. Fellows

    Updated patch

     
  • Donal K. Fellows

    Here's an updated patch which is yours, but addresses some minor style issues.

    Boosted priority so that it will get looked at.

     
  • Pat Thoyts

    Pat Thoyts - 2010-01-05

    Applied to 8.6 HEAD. There were a couple of crashes running the test suite bit those are fixed now (null pointer deref and freeing uninitialized pointer)

     
  • Pat Thoyts

    Pat Thoyts - 2010-01-05
    • status: open-accepted --> closed-accepted
     
  • Pat Thoyts

    Pat Thoyts - 2010-01-05

    Backported to 8.5 branch

     
  • Donal K. Fellows

    • assigned_to: hobbs --> patthoyts
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2010-03-12
    • status: closed-accepted --> open-accepted
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2010-03-12

    This patch used OFN_ENABLEHOOK to correct that functionality, which has the effect on the dialog of using an older XP style. We need to consider a revision to allow modern L&F, which I believe trumps this -multiple limitation.

    We can also increase the size of TK_MULTI_MAX_PATH, which was statically at 40*MAX_PATH, or about 10K. As this is static memory used in the tk_getOpenFile call, would it matter if we made it 400*MAX_PATH == 100K? It will be returned. That won't solve selecting all files in a 1K file dir, but should push the boundary of people who hit this.

     
  • Pawel Pawlak

    Pawel Pawlak - 2010-03-15

    Are you referring to ActiveState build of Tcl/Tk 8.5.8? Or your own builds that result in the "old style" dialog?
    I just go the latest 8.5-branch sources from cvs, built them and I have a "modern style" dialog in Windows XP (i.e. with the "places" bar on the left). The ActiveState build, however, displays the "old style" dialog.

    It's the value that gets assigned to ofn.lStructSize the cause of that (at least partially). The MSDN docs say:
    "For compatibility reasons, the Places Bar is hidden if Flags is set to OFN_ENABLEHOOK and lStructSize is OPENFILENAME_SIZE_VERSION_400"
    And I believe this somehow happened - I just ran wish85.exe (from the ActiveState build) in a debugger and the struct size was set to 0x4C (equivalent of OPENFILENAME_SIZE_VERSION_400) instead of the real structure size (0x58 - which is the case in my build). This happens when the _WIN32_WINNT define is < 0x0500.

    My build environment is MS Visual C++ 2008 Express on Windows XP SP3. And it produces "modern style" dialogs on WinXP in my build of Tcl/Tk out-of-the-box (i.e. no tweaking in Tcl/Tk sources)

     
  • Koen Danckaert

    Koen Danckaert - 2010-04-12

    This patch causes problems when the user types a filename in the file selection box (instead of selecting files with the mouse). The return value is always "{}" (a list with an empty string) in that case. This seems to be a more serious problem than the one which is solved by the patch. It only occurs with -multiple 1.

    Furthermore, I also have an old-style dialog when using this patch. This is with my own build environment, using MSVC 7.1 on XP SP3. It is independent of using -multiple 0/1.

     
  • Pawel Pawlak

    Pawel Pawlak - 2010-04-12

    Replacing

    if (notifyPtr->hdr.code == CDN_SELCHANGE)

    with

    if (notifyPtr->hdr.code == CDN_FILEOK)

    seems to fix this problem (file tkWinDialog.c, procedures OFNHookProc and OFNHookProcW). Anyone?

     
  • Pawel Pawlak

    Pawel Pawlak - 2010-04-19

    patch to ensure the "modern style" dialogs are used

     
  • Pawel Pawlak

    Pawel Pawlak - 2010-04-19

    Uploaded a patch, that ensures that "modern style" dialogs are used where available.

    For the modern style dialogs (when the hook procedure is specified) it is necessary to set _WIN32_WINNT define to at least 0x0500. I noticed, that it is set in tkWinMenu.c anyway (which is compiled after tkWinDialogs.c is), so I moved it to tkWinDialogs.c.

     
  • Donal K. Fellows

    • summary: Patch for bug #2896501 (Filenames limit with tk_getFileName) --> Patch for bug #2896501 (Filenames limit with tk_getOpenFile)
     
  • Jan Nijtmans

    Jan Nijtmans - 2010-05-20

    This is already in HEAD and backported to the 8.5 branch, as part of [Bug #3002230], so this issue can be closed. (I'm not an adminstrator here, and not the submitter, so I cannot do that)

     
  • Alexandre Ferrieux

    • status: open-accepted --> closed-accepted