|
You wan't the message box to be shown after the dialog box is displayed?
Well, in this case, use OnCreate(), and try this:
ShowWindow(SW_SHOW);
UpdateWindow();
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I've tried it with OnCreate(), but it didn't work. The messagebox doesn't appear at all.
Does anybody have any other suggestions???
|
|
|
|
|
harmendejong wrote:
I've tried it with OnCreate(), but it didn't work. The messagebox doesn't appear at all.
 It did when I tried it. Post your OnCreate() function.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
int CTestDialog::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CDialog::OnCreate(lpCreateStruct) == -1)
return -1;
ShowWindow(SW_SHOW);
UpdateWindow();
AfxMessageBox(_T("test"));
return 0;
}
I'm using Windows CE, so therefore I use the _T macro.
|
|
|
|
|
That's exactly what I did, and it worked.
harmendejong wrote:
I'm using Windows CE
That may be the reason it doesn't work. I've never programmed for Windows CE, so there may be little differences in the way things work that I don't know about.
I can't really offer any other suggestions, other than disabling the dialog in OnCreate() (use EnableWindow(FALSE)), set a timer for 10ms or so, and display your message box in the timer message handler. When the message box is closed, enable the window again.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Set a timer in OnInitDialog() - for example, SetTimer(1, 100, NULL).
In OnTimer(), perform your operations. Don't forget to kill the timer first.
HPS HwndSpy - GUI developer's aid to visually
locate and inspect windows. For the month of August
only, use coupon code CP-81239 for 30% off.
|
|
|
|
|
The dialog box will not be rendered until AFTER OnInitDialog() has completed. Therefore, you must call PostMessage() near the end of it, and in the handler for the posted message call AfxMessageBox().
|
|
|
|
|
I did following:
[code]
CMenu* pMenu = this->GetMenu();
CMenu* pFilterMenu =pMenu->GetSubMenu(1);// Filters
CCmdUI state;
state.m_pMenu = pFilterMenu;
state.m_nIndex = 0;/* 1 to nItems */
state.m_nID = pMenu->GetMenuItemID(state.m_nIndex); // now route to message maps
state.Enable(FALSE);
state.DoUpdate(this,false);
//not works
//------------------------
// 2) method
pFilterMenu->EnableMenuItem(ID_BT_AL_RISED, MF_BYCOMMAND | MF_DISABLED | MF_GRAYED);
//not works
[/code]
but not not works both methods,
why?
Or
How to do it correctly?
|
|
|
|
|
Hi,
Use code similar this to enable/dissable menu item:
pPopup->EnableMenuItem(ID_..., MF_GRAYED);
and similar this to delete menu item (by command):
pPopup->DeleteMenu( ID_..., MF_BYCOMMAND );
Hope it help
Vitali
|
|
|
|
|
I assume you're using the MFC MDI or SDI models. Insert an ON_UPDATE_COMMAND_UI() handler for your menu item, and call
pCmdUI->Enable(FALSE) to disable the menu item. Passing TRUE will enable the menu item.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I especially ask for manual disabling-
i.e. not responding to ON_UPDATE_COMMAND_UI() handler.
I dod analogous thing:
<br />
CMenu* pMenu = this->GetMenu();<br />
<br />
CMenu* pFilterMenu =pMenu->GetSubMenu(1);
<br />
CCmdUI state;<br />
state.m_pMenu = pFilterMenu;<br />
state.m_nIndex = 1;<br />
state.m_nIndexMax = 3;<br />
state.m_bEnableChanged = true;<br />
<br />
state.m_nID = pFilterMenu->GetMenuItemID(state.m_nIndex);
<br />
state.m_pSubMenu = pFilterMenu->GetSubMenu(state.m_nIndex );<br />
<br />
state.Enable(FALSE);<br />
<br />
state.SetCheck(1);
but state.Enable(FALSE); - not works
even state.SetCheck(1); - works fine
|
|
|
|
|
You can't manually disable a menu item because MFC overrides your updating. The only way to do it is with an ON_UPDATE_COMMAND_UI() handler. SetCheck() works because MFC either enables/disables the menu item. It doesn't change its check state unless you've got a toolbar button with the same ID which is a checkbox. Enable() will not work unless you use an ON_UPDATE_COMMAND_UI() handler.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Really may be,
but can I prohibit routing check for some menu Item?
CCmdUI::m_bContinueRouting - what does ?
It is also low probably that microsoft not proposed some or two methods
of hanling any user item...
_________
int CAlarmWnd::OnCreate(LPCREATESTRUCT lpCreateStruct)
is good place for modifing it's menu ?
|
|
|
|
|
vgrigor wrote:
but can I prohibit routing check for some menu Item?
No. A handler is always called for each control identifier.
vgrigor wrote:
CCmdUI::m_bContinueRouting - what does ?
Allows multiple ON_UPDATE_COMMAND_UI() handlers to be called for a single control identifier. It is not used for preventing handlers being called.
vgrigor wrote:
It is also low probably that microsoft not proposed some or two methods of hanling any user item...
It might be a low probabilty, but they have 
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Allows multiple ON_UPDATE_COMMAND_UI() handlers to be called for a single control identifier. It is not used for preventing handlers being called
- probably.
But I can not understand your sure that
method and keywords:
pFilterMenu->EnableMenuItem(ID_BT_AL_RISED, MF_BYCOMMAND | MF_DISABLED | MF_GRAYED);
is created to not work ??
|
|
|
|
|
vgrigor wrote:
pFilterMenu->EnableMenuItem(ID_BT_AL_RISED, MF_BYCOMMAND | MF_DISABLED | MF_GRAYED);
is created to not work ??
It works for popup menus, but not for the menus attached to windows. It would work for menus attached to windows if you overrode WM_INITMENU and WM_INITMENUPOPUP and prevented the default processing and overrode OnIdle() in your application class and prevented the default processing. I wouldn't recommend doing this though, because it may break other parts of the program.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I tried at:
void CAlarmWnd::OnUpdateFrameMenu(HMENU hMenuAlt)
I will try as
void CAlarmWnd::OnInitMenu(CMenu* pMenu)
{
CFrameWnd::OnInitMenu(pMenu);
GetMenu()->GetSubMenu(1)
->EnableMenuItem(ID_BT_AL_RISED, MF_BYCOMMAND | MF_DISABLED | MF_GRAYED);
// TODO: Add your message handler code here
}
_____________________
and -not works.
Surely - such a method must be presented - for any kind of menu
(or any pixel) - so is design of MFC.
|
|
|
|
|
works if to change to BY_POSITION action
GetMenu()->GetSubMenu(1)
->EnableMenuItem(postion, POSITION | MF_DISABLED | MF_GRAYED);
|
|
|
|
|
what is a message identifier?
ranjani
|
|
|
|
|
Hi,
MSDN say
==
message identifier
A unique value that identifies a message. System-defined messages use named constants, such as WM_PAINT, as message identifiers. Windows CE reserves message-identifier values in the range 0x0400 through 0x7FFF for application-defined messages.
==
Vitali
|
|
|
|
|
hello ranjani
In modular programming like C++ and VC++ the control o fprogram passes from one area to another based on certain conditions . usually u do it with goto function in C but here in OOPS the control transfers from one line to another by message ids . ie when the user clicks on a menu a message like WM_COMMAND(menuitem , handler) -- here the first param in the WM_COMMAND is the menu item which the user clicked and the second item is the function name which will be fired once the message is fired . So U write whatever u want to do in the menu item here inside the handler that way the control of program gets transferred to the handler function . also other type of messages are also there like
system messages like WM_CLOSE , ON_FILE_OPEN like that but the handlers r already written for them . another type is POST_THREAD_MESSAGE ( MESSAGE) here the message can be posted by any object of a Class CWinThread and the handler function can be written for this mesasge also as mentioned above . hope u will find more info from msdn ( clumsy huh??) dharanibabus@hotmail.com
|
|
|
|
|
Hi there,
I need to select multiple files in an openfiledialog in MFC, but I use this:
CFileDialog *cfd=new CFileDialog, true, ...., NULL, OFN_FILEMUSTEXIST | OFN_ALLOWMULTISELECT, .... , NULL)<br />
<br />
CString x;<br />
cfd->DoModal();<br />
x=cfd->GetPathName();<br />
How can I convert this code to get more then one file???
|
|
|
|
|
Hi student 
To allow the user to select multiple files, set the OFN_ALLOWMULTISELECT flag before calling DoModal. You need to supply your own filename buffer to accommodate the returned list of multiple filenames. Do this by replacing m_ofn.lpstrFile with a pointer to a buffer you have allocated, after constructing the CFileDialog, but before calling DoModal. Additionally, you must set m_ofn.nMaxFile with the number of characters in the buffer pointed to by m_ofn.lpstrFile.
Vitali
|
|
|
|
|
Talik wrote:
Do this by replacing m_ofn.lpstrFile with a pointer to a buffer you have allocated, after constructing the CFileDialog, but before calling DoModal. Additionally, you must set m_ofn.nMaxFile with the number of characters in the buffer pointed to by m_ofn.lpstrFile.
I don't understand this part (I've read it to in the MSDN); that's why I put it on CP. Can you give me some code, jsut for initializing the buffer, and filling it with those files?
|
|
|
|
|
Dear BoudewijnEctor,
Look at the following link with full src code and sample:
http://www.codeproject.com/dialog/PJA_MultiSelect.asp
Vitali
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
