I'm fairly new at c++ programming, and yet I searched around and couldn't find an answer to how to do it, so I'm sorry if this is kind of a stupid question.
Anyway, I'm working on designing a custom window (in Microsoft Visual C++), and I just can't figure out how to remove the menu bar from the window. This is what I'm referring to:
I used an image editing software to put a box around what i want to remove in the program in case i'm not referring to it correctly. Anyway, please tell me what code to remove and/or edit to remove it. (Also, a brief explanation of why would be good because i'm still new to this)
Thanks!
You can use the SetMenu() function to show or hide the menubar. Use it like this:
SetMenu(hwnd, NULL);
where hwnd is the handle to the window, which menubar you want to hide.
You can also try using the DestroyMenu() function to destroy the menu, like this:
DestroyMenu(hMenu);
where hMenu is the handle to the menu you want to destroy.
Related
Hi i Want to Add Window(Gui) to my ConsoleApplication in C++
How to do this?? I need something called Hwnd? I tried to use it and it does not work for me
Basically what I want to do is a MessageBox that will be every time somewhere else on the screen .. but I realized that you have to do it with HWND.
I need Tutorial How to create windows with hwnd
I try:
HWND GetWindow(HWND hWnd, UINT uCmd);
Check if the following code meet your requirement:
#include <windows.h>
int main()
{
MessageBox(nullptr, TEXT("Hello World!"), TEXT("Message"), MB_TOPMOST);
}
It will like this:
You've used multiple tags, I have a winapi solution, not a winforms one.
You can use a std. MessageBox by calling the function, but they can't be „evolved“ into your custom windows for any reasonable „price“ so they can only notify user and ask simple yes/no questions. For „real“ windows, let's forget MessageBox.
The simplest custom window is a std. windows Dialog. It uses the pre-defined window class #32770, so you don't have to register your window class, create a message loop etc. The simplest way to open it is DialogBoxParam function. You must make a .rc dialog script (there are lots of visual editors), compile it with a resource compiler, link into your .exe and pass it's name as the parameter for DialogBoxParam.
Here's an example of a window inside a console application (C++ part only), using this DialogBoxParam call
DialogBoxParam(GetModuleHandle(NULL),"EXAMPLE",NULL,ExampleWindowFunction,NULL);
It's here: https://pastebin.com/Crkdy5FB
It also contains image drawing (you probably don't need it yet, it's left from another winapi example). Use it as a sandbox, you'll probably quickly understand how it works and what role the hWnd plays here.
I understand your problems. GUI got so overcomplicated so it's hard to understand what exactly you don't understand. It prevents from asking a good question.
I'm trying to use TestStack.White to Automated an MFC Application (for UI testing purposes)
When using TestStack.White with an MFC Application written with CMFCMenuBar (the later Docking framework MFC) I noticed that code like the following fails due to window.MenuBar being null
var menu = window.MenuBar.MenuItem("Window");
menu.Click();
I know I can overcome this issue with the following
TestStack.White.UIItems.MenuItems.Menu windowMenu = win.Get<TestStack.White.UIItems.MenuItems.Menu(SearchCriteria.ByText("Window"));
windowMenu.Click();
But what I really want to do is get the ChildMenus so that I can check the list of windows open in the window menu, but the windowMenu.ChildMenus is empty
I am pretty sure this is because the menu is really a toolbar/toolstrip (dockable)
Does anyone know how to get the menu items (Tile,Cascale,Window1....) from the Window Menu
Has anyone else seen this issue or found a work around?
Thanks in advance
Paul
Yes, the MFC feature pack menu is really a toolbar with buttons. And it is fulfilled using a different process compared to the old style menu.
In your CFrameWndEx derived class, for getting the menu bar you can do:
CMFCMenuBar *pMenuBar= m_Impl.GetMenuBar();
Then it depends on what to do with it. For example, if you want to get the CMenu object that constitutes the menu bar you can do:
CMenu* pMenu= pMenuBar->GetMenu();
If you want to remove some of the menus, you can do (Notice the reverse order):
pMenuBar->RemoveButton(4);
pMenuBar->RemoveButton(3);
You can not get the menu the typical way by YourCFrameWndExDerivedClass::GetMenu() because these new MFC Feature Pack classes intentionally do SetMenu(NULL) when initializing the main frame, as you can see in the call stack:
I am not absolutely sure, but I think you won't also be able to do the override YourCFrameWndExDerivedClass::OnInitMenu() as you could in the old style menus. But you can still use the YourCFrameWndExDerivedClass::OnInitMenuPopup() overrride.
Well I'm programming a little game on visual studio with c++ and windows forms. I know that you can't have new pages within a window or atleast there is no feature for it. So my question is, is there any workaround to do so?.. or I'm totally wrong with that.
If it's not really clear what I mean then let me try to explain it a little bit. Most of you know those installation executives where you press the NEXT button and another pages pops up within the same window. That's exactly what I want.
I hope you can help me,thanks in advance.
Use a TabControl object and in the constructor of your form add
tabControl1.ItemSize = new System.Drawing.Size(0, 1);
tabControl1.Multiline = true;
tabControl1.SizeMode = TabSizeMode.Fixed;
Lines above make TabPages without the possibility to be selecetd by user.
Then you can create TabPages and switch them using SelectedIndex property of TabControl
Change the apparearance of tiles to Button.
The code is c#, is simple to be translated to c++.
I'm just getting started using MFC to make Windows applications and was hoping someone could help me get the ball rolling on some code with a button I'm trying to write.
What I'm trying to do is build an application that will have a button, that when pressed, will open a modal dialog with some functionality that's not relevant to my question. I'm having trouble getting started because I can't seem to catch when the button is pressed and attach code to that event.
The event added to my message map:
ON_BN_CLICKED(1, OnBnClicked)
This is OnBnClicked:
void CMainFrame::OnBnClicked()
{
CPaintDC dc(this);
dc.TextOutW(0, 100, _T("SUp dawg"));
MessageBox(_T("Hey Dawg"));
}
Heres the button creation:
BOOL bCreated = myButton.Create(_T("Hey Dawg"), WS_CHILD | WS_VISIBLE,
CRect(40, 40, 190, 90), this, 1);
I just can't seem to figure out why it won't do anything when I click on it. I appreciate all help with this, it's not particularly well documented online :
Warning: I'm not going to try to answer your question directly, simply because it's almost unanswerable without seeing (quite a bit) more of what you've done, such as where you put the code that creates the button. Even when/if I did answer the question directly, I doubt the result would be particularly useful. Therefore, I'm going to describe how I'd handle the same basic situation instead.
The basic point I'd make goes back to the single responsibility principle. A window should typically be represented by a class, and that class should have a single responsibility. If that window acts as a control container, then the sole responsibility of that class should be to act as a control container.
Most of the time, the class/window that contains the button shouldn't do (much of) anything other than hold buttons (or other controls). In other words, buttons mostly belong in thing like dialogs and toolbars. If you need a display that hosts buttons, you usually want that view to be a CFormView. In this case, the form is built from a dialog template. You can put a button on that dialog template with the dialog editor, just like you would with any other dialog. You attach functionality to it the same way you would to any button in any dialog (shift-click or right-click and select "Add Event Handler...").
Yes, it's possible to do things other ways--neither Visual Studio nor MFC even tries to do much to limit what you can do. That doesn't mean you should ignore basic design though--the single responsibility principle still applies, and it's still important. It's just up to you to enforce it as you design your code--and one of its implications is that you don't just create buttons at random places in the code.
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.