Is there something like a panel that I can use in a MFC application. This is to overlay the default window in MFC (a dialog application). Then to paint the panel black and paint some random stuff on top of it. Something like a view port.
is there a better option than this to achieve the same effect ?
Sure. It's called a window! Create a class that derives from CWnd and overrides OnPaint().
In your dialog's OnInitInstance(), instantiate a CMyWnd object and call it's Create() member. Of course, make sure the lifetime of your CMyWnd object is the same as the dialog's object lifetime window. iow, make it a member of you CMyDialog class.
Not very complicated but obviously an area where MFC shows why it doesn't fall in the RAD tools category.
Another solution would be to derive from CDialog. This way you can use the resource editor to edit the panel visually and you don't need to paint anything yourselve. Also the Panel class is rather thin and just needs to propagate the Create() and Show() calls to support subpanels and multiple panels within a single form.
Related
Ok, so my intention is to "prettify" a UI I'm working on. I'm familiar with using GDI+ to manually draw my controls but my target today is simply BitBlitting png's on my DC directly.
That works nice and fine with the main frame, a few buttons and perhaps some menus.
My question is - how would you skin something more complicated like a combobox, listview or more "dynamic" controls using such skins?
Thank you. My target platform is Windows and I'm using C++ with the wxWidgets framework.
To 'skin' an existing control you'll have to subclass the window and catch the draw messages.
roughly:
// Subclass the control
WNDPROC lpfnOldCtrlProc;
lpfnOldCtrlProc = (WNDPROC)SetWindowLong(ControlHwnd, GWL_WNDPROC,
(DWORD)WinSubClassFunc );
and in your WinSubClassFunc:
switch( message )
{
case WM_DRAWITEM: // owner-draw the item
However, if you want to fully 'skin' a control e.g. change all elements of a ComboBox (border, entrybox, dropdown button, droplist etc.) then this becomes really messy.
Personally, I find it is easier to create your own control from scratch than try to subclass an existing control which consists of multiple window items.
The above methods works fine for e.g. using a standard combobox with a droplist and subclass it to make it contain a droplist of colour bars.
I have the following problem with Qt (no answer on this site seemed to address exactly this problem so I create my own question).
I have an application with a MainWindow class which inherits from QWidget. At a certain point there is a table inside the main window and I want to catch all mouse pressed events outside that table.
My first solution was to reimplement the method
/* virtual */ void MainWindow::mousePressEvent(QMouseEvent *event)
In this method, I check the position of the event and check that it is not within the QRect of the table. Unfortunately, I realized that mousePressEvent() is not always called. I suspect that if I click on another child widget of MainWindow, that widget consumes the event and does not pass it through to the parent.
So the only alternative idea I had was to reimplement the mousePressEvent() method for all the widgets contained in MainWindow. This is of course not feasible, because:
There a lot of them: it would be very complex, time-consuming, error-prone, and difficult to maintain if one had to change all the widget classes that are instantiated inside MainWindow.
Some of the subwidgets are implemented in some library modules developed in a parallel project, so I cannot change those.
In other cases, the subwidgets use Qt classes directly.
Even if I defined custom subclasses for 2 and 3, I would have to make sure that these subclasses are used everywhere instead of the original classes. This might imply again falling back to case 2.
So this alternative solution seems unfeasible to me.
Summarizing: Do you know if there is a simple method to catch all mouse clicks on the main window from within the MainWindow class?
You could do this by installing an event filter in the main window. Take a look at QObject::installEventFilter() in the Qt docs.
You can set the attribute Qt::WA_TransparentForMouseEvents with QWidget::setAttribute to all the child widgets except the table to get the mouse events in the MainWindow (which will only work if the table is a direct child of MainWindow).
Or do the opposite, and add a transparent widget above your whole MainWindow with a hole at the position of the table. And you set/unset the Qt::WA_TransparentForMouseEvents to that widget when you want it to let the clicks pass or to catch them.
The hole can be created with QWidget::setMask() and QRegion::substracted().
I have one MFC application (exe) that contains two panes in its main UI. This application loads another DLL that also contains one dialog. How can I programatically place a Dialog defined into the DLL, and put it into (within) the pane of the MFC application? The question is not how to programatically retrieve the dialog from the DLL but how to put this dialog 'on the top' (within, inside) of one UI pane that belongs to the application?
My goal is to customize the UI of the application with dialog(s) retrieved from a dll and give the user the feeling that these dialogs all belong to one application UI. Thanks for any hint.
I have some applications with this feature, often with a tab control to alternate between windows.
First I set a frame in the container window, invisible to the user. The frame is just a placeholder to where the dialog window will be.
Then I make an instance of the dialog window as a global variable in the container class, I create the dialog window as a modeless window (using Create(), not DoModal()), move the window to the same RECT of the frame control, and call ShowWindow() to show the window.
Am I understanding you correctly that you don't want the dialogs to appear as dialogs, but rather as content of another window, or as a pane?
In other words, you want to get rid of the dialog's title bar and embed the dialog's content into another window, is that right?
That is possible. You would need to create the dialog without the title bar (change the window style) and make sure that you create the dialog's window as a childwindow of the window where you want the content to go. I can explain this further but I first would like to know if I'm understanding you correctly.
I have created a MDI project with CView's using VS2008Pro.
I want to have some sort of bar at the bottom of every CView where i
can put controls on, like buttons. I dont know how this bar is called
and how to create one for every CView.
I have a picture of it here to explain what i want.
http://www.4shared.com/dir/32975742/b4bac91c/CView_Bar.html
Could someone please tell me what kind of bar this would be and how to
create it for CViews?
Thanks.
I think, what you want is basically a Toolbar (to answer your question how it is called) in an MDIChildWindow (similar like the toolbar in the main frame window of your application which is created usually by the MFC application wizard automatically). The way to add a toolbar in a child frame window is very analogous to what the wizard has added to the main frame window. You can decide in code where the toolbar shall be located (top, bottom, left, ...)
You can find a brief "How to..." here: http://support.microsoft.com/kb/155141
Also try to google by "Toolbar in MDIChildWindow" or similar. You'll find many resources, I believe.
I'm trying to create a custom dropdown for a derivative of CComboBox. The dropdown will be a calendar control plus some 'hotspots', e.g.
So I figure the best way to achieve this is to have a simple CWnd-derived class which acts as the parent to the calendar control, and have it paint the hotspots itself.
The window needs to be a popup window - I think - rather than a child window so that it isn't clipped. But doing this causes the dialog (on which the combobox control is placed) to stop being the topmost (foreground?) window, leading to its frame being drawn differently:
alt text http://img693.imageshack.us/img693/3474/35148785.png
This spoils the illusion that the dropdown is part of the combobox since its acting more like a modal dialog at this point. Any suggestions on how I make the custom dropdown behave like the regular dropdown?
Are there any other pitfalls I need to watch out for, e.g. focus and mouse capture issues?
When you create your popup window, you need to specify its owner. Owned popup windows will activate their owner when you activate them. Not specifying an owner will cause your window to get activated, which causes the change in the owner you're seeing.
Yeah I had this problem once. A quick google makes me suspect I solved this by using CreateWindowEx() and specifying WS_EX_NOACTIVATE. I have some other code that achieves the same effect by making the window with WS_EX_TOOLWINDOW rather than as a popup window, but I'm not sure of why that was done that way, my intuition would say that making it a popup window would be the way to go.
You can find in the following links two sample project that put in the CComboBox dropdown window a CTreeCtrl or a CListCtrl controls ... similar, you can put whatever you need there. Here is the links:
Tree ComboBox Control
and
List ComboBox Control
I hope this help you.