Hello to all of you guys.

I want to know is there anyway that you can make the return buffer grow of the SaveAs/Open Dialog boxes when multiselect is on? I have noidea of the ammount of files/chars that the user will select and i don't like to return an error and ask the user to redo the selection when the buffer was to small.

PS - Using Explorerlike DialogBoxes.

Thank you,
Black iCE
Posted on 2004-08-04 14:06:30 by Black iCE
Go crazy and allocate a MB :)
Posted on 2004-08-04 14:21:28 by JimmyClif
JimmyClif, i guess that will solve most instances:grin:

But i thought that there should be a "cleaner" way of doing it - i kindof hate chance/fate and lady luck just likes to slap me:eek:

I like being percise but if there is no other way then well i'll go crazy :D, hopefully not overboard.

Black iCE

spelling.....
Posted on 2004-08-04 14:29:18 by Black iCE
You could probably do it in the hook proc but I normally just allocate 32KB.
Posted on 2004-08-04 14:30:18 by donkey
Donkey - Nice to see you again :D... i'll take a closer look at the hook procedure. Remember that the aim is a compressor app and ppl (like me sometimes) go a little bit mad with number of files in one directory and long long names hehe... asm in general dump directory.
Posted on 2004-08-04 14:32:52 by Black iCE
I won't be leaving till around the 14th. 32KB is the maximum size for NT4/2K and XP, that is why I use that particular value. The hook proc is probably the way to go then, should be easy enough to set the size to 0 then watch for a FILEOK notification. At that point you can read the listbox items yourself expanding as necessary. You then return the buffer address in lCustData.

Note, when selecting multiple files, the total character limit for the file names depends on the operating system and the version of the function:

Windows 95/98/Me: (only ANSI is supported) no restriction
Microsoft Windows NT?4 and earlier: 32k limit
Windows 2000/XP: (ANSI) 32k limit, (Unicode) no restriction
Posted on 2004-08-04 14:42:05 by donkey
So i just then read the contents of the list view before the control closes....
but what about CDM_GETFOLDERIDLIST, pIDL's are similar to linked-lists and i suppose i can also do the same as you mentioned, but you pointed out the nice outline to do so :alright:
Anyway pIDL's should be easier to use for UNC path names and getting that Extra data that can help me enumerate the selection into a TOC for the archive header. Recrusively going through the Directory structure should also be easier with them then using text passed from the listview.

Thank you Donkey

Black iCE
Posted on 2004-08-04 14:51:39 by Black iCE
Contradicting Documentation:

CDM_GETFOLDERIDLIST
The CDM_GETFOLDERIDLIST message retrieves the address of the item identifier list corresponding to the folder that an Explorer-style Open or Save As dialog box currently has open. The dialog box must have been created with the OFN_EXPLORER flag; otherwise, the message fails.

later on the same page....

Return Values
If the message succeeds, the return value is the size, in bytes, of the list of item identifiers. This is either the number of bytes copied to the buffer, or the required buffer size if the buffer is too small.

If an error occurs, the return value is less than zero

?????:confused:

So witch is it? Size or PTR?

Black iCE
Posted on 2004-08-04 14:57:41 by Black iCE
No contradiction...
[b][i]CDM_GETFOLDERIDLIST[/i][/b]

[b]wParam[/b] Specifies the size, in bytes, of the lParam buffer.
[b]lParam[/b] Pointer to the buffer that receives the list of item identifiers

The buffer pointed to by lParam recieves the PIDL, the return value in EAX is the number of bytes copied. But I don't think that this is going to help you much, it is only the PIDL for the currently open folder not the selected files.
Posted on 2004-08-04 17:03:24 by donkey