1. RE: getOpenFileName Bug???
Hi Andreas,
Not really a bug... the problem is that the buffer for holding the
returned file names is only 256 characters (the minumum suggested
value). I'll see what I can do to make this a bit more dynamic and
submit the fix to the list.
-- Brian
Andreas wrote:
> Hello,
> on my first euphoria-project, I stumbled into a problem, which I could
> not
> solve. Perhaps someone on the list could help me?
> I use Win32Lib v. 057.9 and copied following code from the manual into
> my
> project
>
> ZIP_Dateien = getOpenFileName( Window1, "", { "Dialog Flags",
> {OFN_ALLOWMULTISELECT},"ZIP-Dateien", "*.ZIP", "All Files", "*.*" } )
>
> to get multiple Files from the open-dialog. It works perfect for a small
>
> amount of files, eg. 15 or so. If I mark more (eg. 30), then the routine
>
> returns nothing (win 2000) or some strange signs (win 98). Is this a
> bug?
>
> Andreas Perband
>
>
2. RE: getOpenFileName Bug???
It really has nothing to do with the number of files. It's the number
of characters contained in all of those file names that's the problem.
I'm working on a dynamic solution based on this info from the SDK:
"The buffer pointed to by the lpstrFile member of the OPENFILENAME
structure is too small for the file name specified by the user. The
first two bytes of the lpstrFile buffer contain an integer value
specifying the size, in TCHARs, required to receive the full name."
However, this only seems to be true to a certain extent on my XP system
so I need to to more testing at home. One *possible* reason for this is
that the OPENFILENAME structure has 3 extra members in XP:
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
It would be easy to modify the lib (this structure in particular) using
GetVersionEx to take advantage of new/extra features. The question is,
if I can make this work, will Derek add it or will I be wasting my time?
-- Brian
10963508 wrote:
> Best solutin would be to display how many files maximum can user select
> (text somewhere on top of dialog), and if user did select too many files
> warn him that he has selected too many files and has to select again -
> don't
> close dialog yet.
>
> Or that each app would be able to define maximum number of files??
>
>
> ----- Original Message -----
> From: "Kat" <gertie at PELL.NET>
> To: "EUforum" <EUforum at topica.com>
> Sent: Tuesday, August 27, 2002 11:47 PM
> Subject: Re: getOpenFileName Bug???
>
>
> > On 28 Aug 2002, at 7:00, Derek Parnell wrote:
> >
> > >
> > > Brian is correct. The original routine only catered for a single
> path/file
> > > name to be returned. When it was updated to support multiple files
> names,
> > > the buffer size was not changed. I'll increase it 8000 bytes. This
> should do for
> > > nearly all cases.
> >
> >
> > I have a folder with 12,379 files in it. Any chance you can accomodate
> that?
> >
> > Kat
> >
> >
3. Re: RE: getOpenFileName Bug???
I'll always consider (favourably) somebody else's efforts to improve the
library.
As you know, Brian, there is already a lot of your code in there.
28/08/2002 9:46:51 AM, Brian Broker <bkb at cnw.com> wrote:
>
>It really has nothing to do with the number of files. It's the number
>of characters contained in all of those file names that's the problem.
>
>I'm working on a dynamic solution based on this info from the SDK:
>"The buffer pointed to by the lpstrFile member of the OPENFILENAME
>structure is too small for the file name specified by the user. The
>first two bytes of the lpstrFile buffer contain an integer value
>specifying the size, in TCHARs, required to receive the full name."
>
>However, this only seems to be true to a certain extent on my XP system
>so I need to to more testing at home. One *possible* reason for this is
>that the OPENFILENAME structure has 3 extra members in XP:
>
>#if (_WIN32_WINNT >= 0x0500)
> void * pvReserved;
> DWORD dwReserved;
> DWORD FlagsEx;
>#endif // (_WIN32_WINNT >= 0x0500)
>
>It would be easy to modify the lib (this structure in particular) using
>GetVersionEx to take advantage of new/extra features. The question is,
>if I can make this work, will Derek add it or will I be wasting my time?
>
>-- Brian
>
>
>10963508 wrote:
>> Best solutin would be to display how many files maximum can user select
>> (text somewhere on top of dialog), and if user did select too many files
>> warn him that he has selected too many files and has to select again -
>> don't
>> close dialog yet.
>>
>> Or that each app would be able to define maximum number of files??
>>
>>
>> ----- Original Message -----
>> From: "Kat" <gertie at PELL.NET>
>> To: "EUforum" <EUforum at topica.com>
>> Sent: Tuesday, August 27, 2002 11:47 PM
>> Subject: Re: getOpenFileName Bug???
>>
>>
>> > On 28 Aug 2002, at 7:00, Derek Parnell wrote:
>> >
>> > >
>> > > Brian is correct. The original routine only catered for a single
>> path/file
>> > > name to be returned. When it was updated to support multiple files
>> names,
>> > > the buffer size was not changed. I'll increase it 8000 bytes. This
>> should do for
>> > > nearly all cases.
>> >
>> >
>> > I have a folder with 12,379 files in it. Any chance you can accomodate
>> that?
>> >
>> > Kat
>> >
>> >
>
>
>
---------
Cheers,
Derek Parnell
ICQ# 7647806
