No problem :) I'm not really sure what you are asking with the second part, so I'll try to answer three things you could mean :) 1. You get a problem when you have too many files seleced in the file dialog 2. You get a problem when the file name for one of them files selected is long 3. You get a problem when adding a large number of files, or a file with a long name, to the list box. 1. As for as I know there is no limited on the number of files you can select, I've never seen it anyway. The only problem you might get is because windows adds each file you select to the edit control, so if you select a lot you may overrun the edit control - is that what you mean? If so, see 2. 2. Hmmm... Well, the max length of a file name is MAX_PATH (255 chars) in Windows anyway, the edit control that accepts the file list should be able to take that easily, but with a lot of files it concevable you will overrun it. The only thing I can suggest is to use the "explorer style" file dialog (the one with the places bar down the side) this may be able to handle a large list of files better. Though you are now faced with another problem. Using the explorer dialog via MFC is tricky. You have to set define _WIN32_WINNT >= 0x0500 (which also means this will only work on 2k+) but thats not all there is to it because the setting this define adds some extra members to the OPENFILENAME struct which cause windows to display the explore style dialog rather than the new one. Unfotunatly, the size of OPENFILENAME is set with in MFC and short of recompiling MFC dlls, you are stuck with it. There are ways round it, search for OPENFILENAME on MSDN and look for 2000 Peridocal (called C++ Q AND A) buy Paul DiLascia. It's called "Windows 2000 File Dialog Revisited; Autocompletion and the ACTest Demo App" and it will show you how to use the new open dialog which might fix your problem. Of course if it doesn't, then.. err.. :) The other thing it might be is this: FIX: Common File Dialog Multiple Selection File Limit : Q179372 But this has aparently been fixed in a service pack. WHat version you running? 3. If this is your problem you are hitting a limit with the number of entrys a list box can handle, use a CListCtrl instead.

It doesn't work man:-( In that order only second file is played, but not the first!

You can use DestroyWindow() to delete the underlying MFC windows handle. Obviously, if you use this on a dialog this will delete all the underlying child handles associated with that dialog box. Another method is to use PostMessage(WM_CLOSE, 0, 0), which is the method I prefer. To destroy a chain of dialog associated with each other you could try SendMessageToSiblings(WM_CLOSE). This will filter through a dialog box chain sending the message to each sibling (To be honst I've never used this method so I don't know if it will work). If you wanted to get all object orientated about it you could look at using the composite design pattern. This design pattern is used to forming complex tree structures and works brillantly for distributing messages across its tree structure.

OK, thanks! But I was trying to avoid using GetDlgItem and SetWindowText functions. What I was asking was is it possible to load the default values (caption, size and so on)as they are defined in the *.rc file? Let's say the captions of some button or static controls have been changed (using 'SetWindowText'). Is it possible at runtime to restore the original values as they are defined in the *.rc-file? I mean to load them directly from this file? I can't get Petzold's book and that's why I'm asking here. By the way, is it available somewhere on the net as eBook? Greetings -J.

send it a WM_CLOSE message "there is no spoon" biz stuff   about me

Yes, few solutions awailable: 1) External executable, when given control restarts app. 2) Create batch file that restarts application with flag delete on close, execute it, and exit application. 3) Same executable, or new version of exec or exe making copy of itself, with when started with "reboot" command option, waits for executer to close, places itself into original directory, and re-starts itself. I used to use (1), now I use (3) for self-update.

CRect rc; GetWindowRect(rc); rc.Width(); rc.Height();

I guess thread safed Message will solve ur problem. There is a lot of article related to messagebox in CodeProject :) XMessageBox http://www.codeproject.com/dialog/xmessagebox.asp?msg=526428&mode=all&userid=44348#xx526428xx Goto www.codeproject.com/dialog search for messagebox. U can definetly find solution to yr problem. bye Uma

SetWindowPos (CWnd::wndTopMost, 0, 0, 0, 0, SWP_NOMOVE | SWP_NORESIZE); /ravi Let's put "civil" back in "civilization" Home | Articles | Freeware | Music ravib@ravib.com

For CodeProject articles dealing with programming the Shell and with the Shell API, see to General -> Shell Programming. The desktop is a part of the Shell. Just like the Start Menu, Quick launch, Task Bar and Tray Area are parts of the Shell. Here's a direct link to the Shell area: http://www.codeproject.com/shell/[^] I recommend the article by Michael Dunn 'The Complete Idiot's Guide to Writing Shell Extensions', parts 1 to 8. Happy reading :) -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

Somehow, before you create your app window, you need to find if another instance is running. One way is to use a named mutex that each instance tries to aquire. Another is to use the main window text as shown below (although not the suggested method) : HWND h = ::FindWindowW(AppName, NULL); if( h ) { // Set focus to foremost child window. // The "| 0x01" is used to bring any owned windows to the // foreground and activate them. ::SetForegroundWindow( (HWND)((ulong)h|0x00000001) ); return(true); } The key point in the above is not finding the app window, but how to restore it once found. ...cmk Save the whales - collect the whole set

Hmm if design allows, I would hide all dialogs visible, spawn a new instance of the application and then finish the original instance. For user it will look the same, only problem can be in accessing shared resources (disk file or whatever) but you can take a care about that.

- Create a class derived from CPropertySheet. - Override the virtual function OnInitDialog() BOOL CMyPropertySheet::OnInitDialog() { BOOL bResult = CPropertySheet::OnInitDialog(); CWnd *pWndOk = this->GetDlgItem(IDOK); if (pWndOk != NULL) { pWndOk->SetWindowText("&Save"); } pWndOk = this->GetDlgItem(IDCANCEL); if (pWndOk != NULL) { pWndOk->SetWindowText("&Quit"); } return bResult; }

You can call CreateProcess in your CMyApp::ExitInstance But why do you want this? Arjan.

the easy way: USES_CONVERSION; CString Str(_T("This is my string")); // explicit copy as single byte chars (LCPSTR) char charBuf[255]; strcpy( charbuf, T2CA(Str) ); // explicit copy as wide chars (LPCWSTR) wchar_t wcharBuf[255]; wsccpy( wcharBuf, T2CW(Str) ); // generic TCHAR copy (LPCTSTR) TCHAR tcharBuf[255]; _tcscpy( tcharBuf, Str ); this works in UNICODE and non-UNICODE. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Peter Weyzen Staff Engineer Santa Cruz Networks

Have a look at these two articles: Office 2000 style File Dialogs for Win 95/98/NT/Me[^] Windows 2000 Common File Dialog[^] Anna :rose: Homepage | My life in tears "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work. Trouble with resource IDs? Try the Resource ID Organiser Visual C++ Add-In

See the FAQ 4.10 How do I programmatically select an item in a list view control?[^] --Mike-- Latest blog entry: *drool* (Alyson) [May 10] Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber "You have Erica on the brain" - Jon Sagara to me

If I need to store state data from a modeless dialog box I usually pass a pointer to my CDocument and store it there. Otherwise when a button is pressed I send a command message to my main view window. This way the dialog can delete itself in the PostNcDestroy function without worrying about some function trying to look at data stored in the dialog class after it has been destroyed. John