Per some discussion one ActiveState's perl-win32-users list that you
might have seen, I was inspired to make GetOpenFileName work a bit better.
The problem at hand is that the results buffer is fixed size, so when
selecting lots of files, it would overflow the buffer. Surprisingly,
Windows actually detects this instance of buffer overflow, and has a
special return value for that case. Win32::GUI's GetOpenFileName
wrapper doesn't really handle the special return value, and even if it
did, it is not the greatest idea to have the user select his files
twice, once causing overflow, and the second time with a bigger buffer.
It would be much better to have a bigger buffer to start with.
Rather than make a new parameter, it seemed reasonable to me to enhance
the -multisel => 0|1 to instead be -multisel => 0|bufsize . So if
-multisel is true, the appropriate flags are set as they are today, but
also the buffersize is set to the minimum of 256 bytes (today's size)
and the bufsize specified in -multisel. This results in 100%
compatibility (but a slight slowdown to do a safemalloc/safefree
sequence) for people using the 0 or 1 values. But for people that start
passing in numbers larger than 256, it provides a larger buffer for
multiple selection results.
Is there any objections to my applying this patch?
In addition to the gui.xs file that I changed, I guess I need to update
CHANGELOG. Anything else?
Can I change the version to 0.0.681 ? Can we start the convention of
bumping the version by 0.0.002 each time we change something (keeping it
odd for development versions)? And then by at least one more when we do
a build, making it even? Or maybe each build bumps the second 0. So
the next "official" release would be 0.1.0. And the next development
release after that would be 0.1.001, 0.1.002, etc. Official releases
would always be N.M.0 ?
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
