|
The proper way to do it is via the IDOCHOSTUIHANDLER flags.
The RButton messages will be interecpted long before your APP gets a chance
You could use PreTranslateMessage in desperation.
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
I am sick of fighting with Martin, I think I will ignore his posts from here on in, and spend the time working on articles instead.
Christian Graus
|
|
|
|
|
Thanks for the suggestion - It worked.
I went ahead and used the PreTranslateMessage method since I only care about one single event... the right button up.
BOOL CMyHtmlView::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message != WM_RBUTTONUP)
{
return CHtmlView::PreTranslateMessage(pMsg);
}
return TRUE;
}
Alan Schneider
|
|
|
|
|
In a mainframe event, the following
m_wndToolBar.GetToolBarCtrl().HideButton(ID_EDIT_COPY, TRUE);
does fine and hides the button. How do I hide a separator? I would have to specify its position as well, since I didnt see anything like ID_SEPARATOR1 etc...
THanks for your help,
ns
|
|
|
|
|
I have a horrible feeling you might be forced to remove and add all (except the offending separator) buttons again.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Try DeleteButton() . It takes an index, not a command id.
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
how come all the ISAPI thingies like GetServerVariable and ServerSupportFunction and such don't handle unicode (LPSTR not LPTSTR)
also, what is the response header to send if my content ("<html>hello</html") is to be outputted in unicode format?
and will that allow me to output stuff based on a certain language like chinese or russian or something (e.g. right-click somewhere in IE6 and go to the 'Encoding' menu, you see lots of languages and stuff)? i want to be able to make my ISAPI extension flexible in that sense
-roman
|
|
|
|
|
These functions manage data that are stored HTTP headers --and HTTP is hopelessly based on ASCII.
It is only the contents of HTTP responses that can be encoded in codes other than ASCII.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
If you read this message already - skip it. I just place it here one more time hoping someone will help me.
The question is simple, i have the following code for my popup menu:
Menu=new CMenu;
Menu->CreatePopupMenu();
(...)
Menu->AppendMenu(MF_STRING | MF_ENABLED, 0, "Insert");
Menu->AppendMenu(MF_STRING | MF_ENABLED, 0, "Delete");
(...)
Menu->TrackPopupMenu( TPM_LEFTALIGN | TPM_RIGHTBUTTON | TPM_LEFTBUTTON, Point.x, Point.y, ParentWindow);
Menu->DestroyMenu();
It works ok.
But i need to process commands to make it worth anything.
When I use:
Menu->AppendMenu(MF_STRING | MF_ENABLED, ID_INSERT_ATTRIBUTE, "Insert");
Menu->AppendMenu(MF_STRING | MF_ENABLED, ID_DELETE_ATTRIBUTE, "Delete");
These items appear as grayed and unavailable.
I've used CMenu::GetMenuItemID to check if the ID is assigned - it is (returned values were ID_INSERT_ATTRIBUTE and ID_DELETE_ATTRIBUTE).
I also used CMenu::EnableMenuItem to enable these (this function returned MF_ENABLED as a previous state of item )
Did i missed something?
By the way - i have problems with CToolTipCtrl - i almost copied all code from one of MSDN's samples but it doesn't work. If someone has some experiences with ToolTips i would like to ask a few questions.
[ CoY0te ]
( greetings to all assembler coders heh! )
|
|
|
|
|
This little jewel I found some years ago:
void CYourDlg::GfxCmdUIUpdateMenu(CMenu* pMenu, BOOL bDisableIfNoHndler)
{
ASSERT(pMenu == NULL || AfxIsValidAddress(pMenu, sizeof(class CMenu)));
if (pMenu){
CCmdUI cmdUI;
cmdUI.m_pMenu = pMenu;
cmdUI.m_pSubMenu = NULL;
UINT nMax = pMenu->GetMenuItemCount();
if (nMax == (UINT)-1)nMax = 0;
cmdUI.m_nIndexMax = nMax;
for (UINT n = 0; n < nMax; n++){
cmdUI.m_nIndex = n;
cmdUI.m_nID = pMenu->GetMenuItemID(n);
if (cmdUI.m_nID == (UINT)-1){
CMenu* pSubMenu = pMenu->GetSubMenu(n);
GfxCmdUIUpdateMenu(pSubMenu, bDisableIfNoHndler);
}
else cmdUI.DoUpdate(this, bDisableIfNoHndler);
}
}
} Use it just before TrackPopupMenu . Please tell me back if it worked.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Nothing.
The problem is, that items with nIDNewItem=0 (created by AppendMenu) are OK, but when i pass parameter greater then 0 to this function these items are disabled. This is the ONLY difference between these items. And more: I can add some items with nIDNewItem=0 and some with nIDNewItrm>0 in the same menu and only those with nIDNewItem>0 will be disabled (this is a popup menu with no submenus).
By the way - I've tested some negative ID values - -1000,-2000 and -3000 were enabled and -10000,-20000,-30000 were grayed. Funny thing, but it drives me crazy!
Is there any way to check the user's choice without processing the WM_COMMAND message? I didn't notice that CMenu class has any kind of GetSelectedItem method, so I doubt it, but it would be the simpliest way.
Anyway thanks for the answer. It's good that someone answered.
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
Those IDs have to have some command handler associated with them. Are you processing, for instance, ID_INSERT_ATTRIBUTE in any way?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I was supposed to, but I don't do that now since these items are "disabled" - can this really be it?
I thought, that if I don't do the processing itself, these items will be available, but they will affect no action when clicked - just that. Do I have to "create" commands somehow?!?!? Right now i'ts only:
#define ID_INSERT_ATTRIBUTE <value>
And the parent window's OnCommand method is almost empty (processes only ID_INSERT_ATTRIBUTE for testing).
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
Yes you have to create those commands. Define them as WM_USER plus some offset of your choice. To implement a handler, take a look at the documentation for ON_COMMAND .
Also, you can use FALSE as the second parameter of GfxCmdUIUpdateMenu (this won't make the commands be handled, but at least you'll see the menu entries enabled.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Didn't work too.
I had these commands defined with #define directive.
I've changed them to WM_USER+n, and tried it in few different ways - no effect.
Both using that function with bDisableIfNoHndler set to TRUE and FALSE and without that function.
I'm running out of ideas.
I'm gonna get some sleep (it's 23:30 in Poland and I've got back from the pub recently ).
Bye.
I'll be back tomorrow.
Thanks for the effort.
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
Not only do the commands have to be defined, there also must be handlers for them (with ON_COMMAND ).
As for why bDisableIfNoHndler does not work, I don't know. I guess I'll have to get some sleep too.
Good night
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Why not subclass CMenu with CMyCMenu and define the commands and define the handlers in it's message map?
Or in your mainframe class define a handler in the message map like:
ON_COMMAND(ID_APP_DOTHIS, DoFunction)
Would either of those be possible?
|
|
|
|
|
I guess this conversation led us to a dead end.
I'll just start it almost from beginning,cause the problem is unusual for me and from the answers I got, i haven't found out anything yet. Anyway thanks everybody for trying to help me. Here we go:
Take a look at my code, and see what is it all about:
Version 1:
#define ID_EDIT_ATTRIBUTE WM_USER+1
Menu->AppendMenu(MF_STRING | MF_ENABLED, ID_EDIT_ATTRIBUTE, "Edit criterion"); //item is grayed
Version 2:
Menu->AppendMenu(MF_STRING | MF_ENABLED, 0, "Edit criterion"); //item is not grayed but has no command assigned
I've used these two message boxes for testing:
if (Menu->GetMenuItemID(0)==ID_EDIT_ATTRIBUTE)
MessageBox(NULL, "OK", "Item ID", MB_OK);
if (Menu->EnableMenuItem(0, MF_ENABLED | MF_BYPOSITION)==MF_ENABLED)
MessageBox(NULL, "OK", "Enabled?", MB_OK);
Both of them are appearing before TrackPopupMenu, but "Enabled?" does not appear right after TrackPopupMenu.
Conclusion: TrackPopupMenu disables these items, but why does it not accept these command ID's?
By the way - I'm using that PopupMenu in a class not derieved from anything (so it's not a CWnd class), but i pass the parent window pointer:
Menu->TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON | TPM_LEFTBUTTON, Point.x, Point.y, ParentWindow);
Right now I'm processing only the ID_EDIT_ATTRIBUTE command in my OnCommand method (just for testing).
The question again: Why does it NOT accept my command ID?
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
Because, by default, MFC disables menu items that don't have command handlers implemented somewhere in the message map of the parent windows of the menu.
You need to add a proper command handler (preferably not in OnCommand, although you can do, you just have to make sure you handle all the parameters properly, including the extra pointer value, and return the correct value) in the window that you specify as a parent in TrackPopupMenu.
If you need to change the enabled state of the menu item based on program conditions, you should be using an UPDATE_COMMAND_UI handler as well.
For a very detailed explanation of the command routing architecture and command UI update handlers, see Meandering Through the Maze of MFC Message and Command Routing by Paul DiLascia, an excellent article that I've recommended here before.
"We are the knights who say Ni" (The Knights Who Say Ni)
|
|
|
|
|
I think I've solved the problem.
Thanks everybody for your effort. I appreciate it.
My solution:
1. throw out that dynamic creation of menu items
2. create all my popup menus as one resource
3. Use the following:
CMenu MenuGroup;
MenuGroup.LoadMenu(IDR_POPUP_MENUS);
Menu=MenuGroup.GetSubMenu(<number of="" popup="" menu="" to="" use="">);
Menu->TrackPopupMenu(...);
Now I can use the class wizard to handle my menu commands.
I still feel strange about these grayed items. I think disabling them should not be the default action when there is no message handler - it would be better (as for me) to leave them enabled and take no action when user clicks them.
Well, I guess I'll never understand Mircosoft's way of coding.
Thank you very much again.
Greetings to all assembler dudes and especially for C64 demoscene!
|
|
|
|
|
It´s better to gray them out, so that even the managers know that it won´t work.
|
|
|
|
|
How the he@@ can I get the video adapter's name as shown in
'Display properties' dialog ( e.g.: 'Rege Fury/Xpert128/Xpert 2000' )???
Respect...
--BlackSmith--
"With the help of all mighty", 2001, Me.
|
|
|
|
|
With <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcons_2303.asp">EnumDisplayDevices</a> (not supported in Windows 95 and NT).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
In certain situations I want to go right to a dialog after loading a dialog, and I'm wondering how to do this such that the parent dialog is drawn on screen first. For instance, I have dialog A with a button which, when clicked, loads another dialog B. In certain situations I want to pop up this child dialog B right away, as though the user clicked the button. If I set to true a member variable in dialog A, m_bPopupBRightAway, before calling DialogA::DoModal() and check this value at the end of DialogA::OnInitDialog(), dialog A isn't yet drawn on the screen when DialogB comes up. What's the best way to go about doing this so that I get the desired result?
Thanks!
- Jason
(SonorkID 100.611)
In the beginning, teachers taught the 5 W's: who, what, where, when, why. Now it's just a big damn G
|
|
|
|
|
void CMyDlg::OnPaint()
{
if (IsIconic())
{
...
}
else
{
CDialog::OnPaint();
if(m_bFirstTime){
m_bFirstTime=FALSE;
...
}
}
} Where m_bFirstTime is a member variable of the dialog initialized to TRUE .
Another method, suggested by Shog9, is to self-post a user-defined message from OnInitDialog in response to which the second dialog is launched.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
Another method, suggested by Shog9, is to self-post a user-defined message from OnInitDialog in response to which the second dialog is launched.
Ooh, I like it. Thanks a lot!
- Jason
(SonorkID 100.611)
In the beginning, teachers taught the 5 W's: who, what, where, when, why. Now it's just a big damn G
|
|
|
|
|