I'm using a wxToolBar which makes use of a drop-down menu with following code (simplified):
g_toolBar1->AddTool(TOOLBAR_CMD_CONTROL_DROPDOWN,_("Control elements"),MainWin::getBitmap(gearsXPM,"gears"),wxNullBitmap,wxITEM_DROPDOWN);
custParent->Connect(TOOLBAR_CMD_CONTROL_DROPDOWN,wxEVT_COMMAND_TOOL_CLICKED,wxCommandEventHandler(DrawCanvasSwitcher::OnToolbar),NULL,g_drawCanvas);
wxMenu *controlMenu=new wxMenu;
// following is repeated several times to have more than onw drop-down item
// (*it) is an iterator to an container holding the required data
wxMenuItem *item=new wxMenuItem(controlMenu,wxID_ANY,(*it)->m_entityParams.m_name,(*it)->m_entityParams.m_shorthelp);
controlMenu->Append(item);
item->SetBitmap(*(*it)->m_entityParams.m_bmToolbar);
item->SetId((*it)->m_wxID);
custParent->Connect(item->GetId(),wxEVT_COMMAND_TOOL_DROPDOWN_CLICKED,wxCommandEventHandler(DrawCanvasSwitcher::OnMenu),NULL,g_drawCanvas);
g_toolBar1->SetDropdownMenu(TOOLBAR_CMD_CONTROL_DROPDOWN,controlMenu);
g_toolBar1->Realize();
So the first Connect() is successful and when clicking the top toolbar item, I end up in DrawCanvasSwitcher::OnToolbar(). The second Connect() - which is simply copied from a different position in same file and where it works fine for normal menu items - does not work, I never get an event in DrawCanvasSwitcher::OnMenu() when selecting a toolbar drop-down item. The event type is the same as used in the toolbar-sample that comes with wxWidgets 3.1. g_drawCancas and custParent all are valid (and work for plain menu items).
So what could be the reason why I do not reveice events on clicked drop-down items?
Edit: using wxEVT_COMMAND_MENU_SELECTED instead of wxEVT_COMMAND_TOOL_DROPDOWN_CLICKED does not make any difference, still no event...
I don't see anything obviously wrong in the code, so, as always, the best thing to do would be to try to simplify it as much as possible and/or try doing the same thing in the toolbar sample to see if you can reproduce the problem there.
One thing I'd try would be to specify (*it)->m_wxID immediately when creating the menu item, instead of setting it later. It should work as written, of course, but it's rather uncommon to do it like this, so perhaps there is a bug somewhere there.
If you do manage to reproduce the problem in the toolbar sample (e.g. just remove the event table entry for MyFrame::OnToolDropdown() there and use Connect() instead), please do report it as a bug, mentioning your platform.
And, finally, although it's completely unrelated to your problem, there is really no reason whatsoever to use Connect() instead of Bind() with wxWidgets 3.x, you should really switch to the latter for better compile-time safety and flexibility.
Related
I've searched this extensively, and the answer I came up with about 20 times is to use CWnd::EnableWindow(FALSE). Currently, I have:
GetDlgItem(myComboBox)->EnableWindow(FALSE);
Instead of disabling the ComboBox, now the entire Dialog doesn't show up, and since it's a modal dialog (or at least I'm guessing that's the reason), the entire program gets locked up because I can't close the dialog if it's not there.
Is there a way to disable editing to this box without making it disappear entirely; similar to what SetReadOnly() does for a CEdit?
Edit:
Suddenly, the syntax above started working the next morning. I'm still not entirely sure why it didn't work in the first place.
EnableWindow(FALSE) is the correct function to call but your syntax looks like it may be incorrect (but it's hard to say with such a minimal example).
Is myComboBox an instance of CComboBox? If so, I'd expect to see:
myComboBox.EnableWindow(FALSE);
or, using the associated resource ID:
((CComboBox*)GetDlgItem(IDC_MY_COMBO_BOX))->EnableWindow(FALSE);
Threading issues or duplicate resource ID's can also cause weird issues.
It seems you are trying to call EnableWindow() from a different thread than the dialog's
You could try this, and see if it works for you:
GetDlgItem(myComboBox)->PostMessage(WM_ENABLE, (WPARAM)FALSE);
I was playing around with the Qt demo browser example mentioned here and noticed an anomaly when I tried making a minor change to the bookmark handling code.
My intention was to make the bookmarks in the toolbar open up in a new tab instead of the existing tab. It works perfectly for the bookmarks that are located directly on the bookmarks tab. But the bookmarks inside a folder are the ones which are behaving weirdly.
I modified the BookmarksToolBar::activated SLOT in the bookmarks.cpp to open the url in a new tab instead of existing tab. That's when I noticed that the SLOT is being called multiple times, the count being equal to the number of times the menu is rendered. i.e, the first time a menu item is activated, the SLOT is called once, the next time an item is activated, the SLOT gets called twice and so on.
I thought there must have been multiple signal-slot connections and thus I checked on the BookmarksToolBar::build() method where the signal-slot connection is done and found that the control flow enters the method only once. I am finding it hard to figure out how the SLOT is being called multiple times.
The project is question is an example project 'Tab browser' which comes with Qt and can be accessed by clicking on 'Examples' on the Qt-Creator welcome screen. Thus I did not post any source code here.
Any guidance or help in understanding the cause for this anomaly and possible solutions to fix it would be appreciated.
Found the cause of the problem and solution myself. The root of the problem is in modelmenu.cpp.
Apparently the ModelMenu::createMenu method connects the QMenu::triggered and QMenu::hovered signals to SLOT each time the method is called. The SLOT triggered emits the signal ModelMenu::activated.
Using Qt::UniqueConnection should solve the issue.
Replacing this:
connect(menu, SIGNAL(triggered(QAction*)), this, SLOT(triggered(QAction*)));
connect(menu, SIGNAL(hovered(QAction*)), this, SLOT(hovered(QAction*)));
With this:
connect(menu, SIGNAL(triggered(QAction*)), this, SLOT(triggered(QAction*)),Qt::UniqueConnection);
connect(menu, SIGNAL(hovered(QAction*)), this, SLOT(hovered(QAction*)),Qt::UniqueConnection);
Fixed the problem. Just leaving this here hoping this would help someone in future.
I need to make multiple enable/disable changes to a main menu in a C++ Builder VCL application.
When the application changes state, I loop through disabling and enabling visibility of multiple menus.
This issue I have is that when looping occasionally during the loop there are more menus visible than what will fit on the screen, causing a wrap, which then causes everything on the main form to resize, and resize back resulting in slowness and a huge flicker.
I have tried the Disable and Enable align on the main form, doesn't have any impact.
I have done the WM_SETREDRAW trick on the main form, however while it stops it drawing, calling invalidate afterwards, doesn't get some of the children controls to redraw correctly. An example of what won't redraw is the tabs on a TPageControl.
An other point that may be of relevance, is that code is called from a TTabSheet::OnShow callback.
Ideally I would like to find a BeginUpdateMainMenu and EndUpdateMainMenu method, however I can't find on in the VCL documentation or the Win32 documentation.
Any help is much appreciated. Thanks.
This is not a technical answer but I'm thinking from an end user "useablilty" point of view : how easy would it be for him/her to use "more menus visible than what will fit on the screen"
Do you have the possibility to group the menu items in some way so that they could be dysplayed in sub-menus ?
As the context menu for the desktop and explorer windows is disabled, I wanted to make a little something to bring back some functionality. My idea was to just list out things in a context menu (copy, paste, new, open with, etc) whenever a user right-clicks one of these windows, and then just simulate the appropriate event in the actual menu (file->new, edit->copy, etc). It wouldn't look perfectly pretty, but it would hopefully allow for the use of right-clicking.
The problem is that I cannot seem to get the actual menu. I opened My Documents and tried going down the child list towards SysListView32, calling GetMenuItemCount each time. Most returned -1, and the only other return value than that was 0.
How am I supposed to get a handle to the (file, edit, view...) menu?
If this isn't possible, is there a way I could simulate the user clicking something on the normal context menu, even if it's disabled?
Also, is there a way of making this work for the desktop? You can get the same type of thing if you view it in the explorer window, so I figured there might be a way.
I'm running Windows XP and any help is appreciated.
As per David Heffernan's comment,
As for your question, you are on the wrong track.
GetMenuItemCount needs an HMENU but you've been feeding it HWND.
That won't work. It also won't work from a different process.
You could possibly write a program that use the shell COM APIs
to show a context menu for a shell item. But your basic problem
is the bone-headed group policy. You really need to get that fixed.
Tell the IT guy that takes the decision that I said he was a fool
and was stopping you doing any useful work. ;-)
This led me onto the path of using the correct alternative method to achieve my goal.
I always been interested on how we can accomplish this (hide/show the main menu using the alt key), and now some applications do this very often. One that really please me is the visual studio 2010 with this plugin:
http://visualstudiogallery.msdn.microsoft.com/bdbcffca-32a6-4034-8e89-c31b86ad4813?SRC=VSIDE
(firefox also do this, but i think that is in a different way)
Can anyone explain me how this can be achieved or if you known of any sample project that demonstrate this please tell me.
(what i can see in some replies here in stack is that we have to destroy the menu when is to hide and create it when is to show?! but this seems a bit bad solution...)
Thanks
The SetMenu function lets you add/remove the menu from the window. It does not destroy the menu.
Note that most applications which have the dynamic menu hide/show behavior are not really showing a menu. They're showing a custom control that looks like a menu.
You might also take a look at MFC support for auto hiding menus. I used this technique and it worked really well.
in CMainFrame::OnCreate I did
m_wndMenuBar.ShowWindow(SW_HIDE);
which actually works fine in our project
I stumbled across a related pit fall that will show a hidden main frame without your consent:
Whenever the focus for a child window in an MDI application changes (e.g. due to right clicking in it), the function CMDIChildWnd::OnMDIActivate will be called, which in turn shows the main menu (even if it was removed or destroyed previously) of the MDI application.
This works basically by adding the saved main manu from the underlying's CMDIChildWnd m_hMenuShared variable.
A quick&dirty hack to prevent this, is setting m_hMenuShared to NULL (it's protected in CMDIChildWnd so this needs a custom derived child class of CMDIChildWnd) for all child frames.