CFileDialog problem with OFN_ALLOWMULTISELECT

Lars Heucke -- larsmaic@cs.tu-berlin.de
Sunday, March 09, 1997

Environment:  VC++ 4.0, Win95, NT 3.5, NT 4.0

Hi all,

I use the following code for a multi-selection of some files:

CStringList FileNameList;
static char BASED_CODE szFilter[] =3D "DIB Files (*.bmp)|*.bmp| ";
   =20
CFileDialog fileDlg (TRUE,"BMP",NULL,=20
		      OFN_ALLOWMULTISELECT |
    		      OFN_HIDEREADONLY|
    		      OFN_OVERWRITEPROMPT,
		      szFilter,NULL);
char FileNameBuffer[1000000];
sprintf(FileNameBuffer,"");
fileDlg.m_ofn.lpstrFile =3D FileNameBuffer;=20
fileDlg.m_ofn.nMaxFile	=3D 1000000;	=20

if (fileDlg.DoModal() =3D=3D IDOK)
{
POSITION FileListPos =3D fileDlg.GetStartPosition();
	while (FileListPos !=3D NULL)
	FileNameList.AddTail(fileDlg.GetNextPathName(FileListPos));
}


The problem is order of the selection. If I select the files in a =
specific order, the receive buffer of GetNextPathName have another order =
than the order of the selection had.=20

For example:=20
I select with the FileDialog in this order:=20
FILE-03.BMP, FILE-01.BMP, FILE-05.BMP, FILE-07.BMP, FILE-06.BMP
At the end of the code I get in the FileNameList the following order:
FILE-06.BMP, FILE-03.BMP, FILE-05.BMP, FILE-01.BMP, FILE-07.BMP=20
???=20

The problem with the new order is only under Win95 or NT 4.0. If the =
FileDialog runs under NT 3.5 (the old FileDialog style) everything works =
fine.=20

Is there a way to change this behaviour ?

Lars

---

Mike Blaszczak -- mikeblas@nwlink.com
Tuesday, March 11, 1997

[Mini-digest: 2 responses]

At 19:16 3/9/97 +-100, Lars Heucke wrote:
>Environment:  VC++ 4.0, Win95, NT 3.5, NT 4.0

>I use the following code for a multi-selection of some files:

>The problem is order of the selection. If I select the files
>in a specific order, the receive buffer of GetNextPathName have
>another order than the order of the selection had. 

> [...]

>Is there a way to change this behaviour ?

No.  The API doesn't specify that the order of the selected files
as reported by the API is deterministic.  If you need it to be so,
you need to develop your own user interface from scratch or subclass
the dialog and record the order of selection yourself.

If the order is important to you, it must be important to your users.
And, if that's true, it seems like you'd better provide a clean way
for your users to change the order of the files they've selected; it's
easy to get confused or make mistakes while you're shift-clicking
in a long list.


.B ekiM
  Crotch Rocket   / Full-Body Rocket / http://www.nwlink.com/~mikeblas/
95 Honda VFR-750F /   94 Mazda RX-7  / Trip Report Central!
                 Less work, more hockey!
  These words are my own - I do not speak on behalf of Microsoft.
-----From: ktm@ormec.com

On mfc-l, Lars (larsmaic@cs.tu-berlin.de) wrote:
> Environment:  VC++ 4.0, Win95, NT 3.5, NT 4.0
> I use the following code for a multi-selection of some files:
> [CFileDialog code snipped]
> 
> The problem is order of the selection. If I select the files in a 
> specific order, the receive buffer of GetNextPathName have another 
> order than the order of the selection had.
> [example snipped]
> 
> The problem with the new order is only under Win95 or NT 4.0. 
> If the FileDialog runs under NT 3.5 (the old FileDialog style) 
> everything works fine.
> 
> Is there a way to change this behaviour ?

I'm surprised it ever worked. Nothing in the documentation guarantees
any particular order of files in the recieve buffer. I expect that 
for the Explorer-style dialog, you need to write a hook procedure
and watch for the CDN_SELCHANGE notification. (Or override 
CFileDialog::OnFileNameChange).

For old-style dialogs, if you care about the file order, you should
probably watch for LBSELCHSTRING.

Note also that you should install service pack 2 (and hotfixes) for 
NT 4.0 systems where you're using multiple-select explorer-style 
dialog boxes.

  Katy
-- 
Katy Mulvey                    <mailto:ktm@ormec.com>
Software Development Engineer
ORMEC Systems

---

Become an MFC-L member | Вернуться в корень Архива |