[Tcl-bugs] [ tktoolkit-Patches-2898255 ] Patch for bug #2896501 (Filenames limit with tk_getOpenFile)

[SourceForge.net <no...@so...>]

Patches item #2898255, was opened at 2009-11-16 01:58
Message generated for change (Settings changed) made by ferrieux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312997&aid=2898255&group_id=12997

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 37. [tk_get*File]
Group: None
>Status: Closed
Resolution: Accepted
Priority: 9
Private: No
Submitted By: Pawel Pawlak (mickey_knox)
Assigned to: Pat Thoyts (patthoyts)
Summary: Patch for bug #2896501 (Filenames limit with tk_getOpenFile)

Initial Comment:
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.

----------------------------------------------------------------------

Comment By: Jan Nijtmans (nijtmans)
Date: 2010-05-20 13:07

Message:
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)

----------------------------------------------------------------------

Comment By: Pawel Pawlak (mickey_knox)
Date: 2010-04-19 15:15

Message:
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.

----------------------------------------------------------------------

Comment By: Pawel Pawlak (mickey_knox)
Date: 2010-04-12 15:26

Message:
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?

----------------------------------------------------------------------

Comment By: Koen Danckaert (danckaert)
Date: 2010-04-12 12:32

Message:
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.

----------------------------------------------------------------------

Comment By: Pawel Pawlak (mickey_knox)
Date: 2010-03-15 23:01

Message:
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)


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2010-03-12 21:27

Message:
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.

----------------------------------------------------------------------

Comment By: Pat Thoyts (patthoyts)
Date: 2010-01-05 23:42

Message:
Backported to 8.5 branch

----------------------------------------------------------------------

Comment By: Pat Thoyts (patthoyts)
Date: 2010-01-05 22:55

Message:
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)

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2010-01-05 17:43

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

Boosted priority so that it will get looked at.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2010-01-05 17:41

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312997&aid=2898255&group_id=12997