I have a dialog and I want a 'mini' version of it for a cut-down version of its functionality. I could make another dialog template / class, but I wondered if there was a way to change the size of my dialog and move the client rect 'view' so I can only see some of the controls (that aren't at the top-left of the full size dialog. Then I can just reuse the template and code I already have
So to go from this:
to something like this:
Related
Since there is no way to deep customizing (a gradient background for example) win32 controls (such as buttons, menu items e.t.c) many people advise to create an own custom control.
And if I need a custom button I will use WM_MOUSEMOVE, WM_LBUTTONDOWN and a shadow buffer. I will draw all controls on the shadow buffer and then use BitBlt(hDC, ...) for my window.
But if I want to create a custom menu I must to foresee that menu can be drawn outside of the client area.
At first I need to mouse tracking outside of the client area. SetCapture(hWnd) seems to be a bad solution as it blocks mouse tracking for windows below.
Then I need to draw/erase items outside of my window. Erasing with InvalidateRect(NULL, NULL, TRUE/FALSE) seems to be a bad solution too as it cause of blinking.
What is the best approach to create custom menu with WinAPI?
Runtime menus that can appear anywhere on the screen can be shown with TrackPopupMenu() function. Create the menu with CreateMenu(), AppendMenu() etc, then show it with TrackPopupMenu().
I wanted to develop a widget container (still on python 2.7 and gtk2), which would be placed in a scrolled window, and could be freely moved and resized in the window, such that: click & drag within the widget would move it inside the window; and when widget's corners / edges are visible in the window, it would expose drag handles for resizing - otherwise, if it is bigger than the window area, it would scale up and down (zoom in and out) on middle-click.
Of course, I want to keep the amount of custom coding of this widget to a minimum, so I though looking into what's available in gtk2 first. It turns out, the only element exposing resize drag handles is gtk.Window - and at that, only if it is a main (or root) window; otherwise, if a window is placed inside a widget, its size is apparently set by the widget, and so there are no drag handles (not menus, titlebars etc). I was wandering why this is - and it seems it is due to multiple document interface (MDI) being considered evil by gtk developers, see e.g. Re: [gtk-list] Resizing widgets with a mouse or Does GTK support MDI? - Linux/BSD whirlpool.net.au.
Just to demonstrate the behavior that I want, I used a PyQt4 code from Python PyQt/PySide QMdiArea subwindows scroll not working in TabbedView - Stack Overflow, since as it turns out, Qt does have an MDI area. So here's the gist of it - if a corner is visible, a resize drag handle appears, and resize drag action can be started:
When you thus drag the corner outside of the window - the scrollbars automatically indicate the new size/position of the inner widget (note the window got also moved a bit in this screenshot below, that was manual and unintended):
Again, I don't really need a window (as in titlebars, menus) - just a widget container that would behave in this way, so I could put e.g. a table (e.g. TreeView) or an image in it, as the situation demands - and at least not worry about recalculating the "outer" scrollbars (naturally, I'd expect I'd have to code the rest of my custom behavior myself). Also, I just need a single widget placed in a window like that for now (so no "multiple document"s).
While Qt seems to offer this in a way, I don't have the possibility right now to get into it to the level of doing something like this; and the same goes for WxWindows (see e.g. wxPython-users - How to resize Widgets? - possible, but as there is no code there, I cannot see if geometry calculation coding is required or not).
So I was wondering - is there a widget I may have missed, that would implement the above behavior, and that I could take as a base for customization? If not, what options do I have to implement something like the above on gtk2 (eventually with Python)?
I'm not sure this would work, but I suggest looking into GtkOffscreenWindow; put the inner widget into that, and render it to a GtkDrawingArea inside a GtkScrolledWindow. This would probably make the scrollbars behave properly depending on the size of the drawing area.
What you won't get:
window titlebars, you'll have to render those yourself because GTK doesn't know about them, they're part of the window manager. (Note, the inner window in the Qt example has a different titlebar than the outer window - I suspect this is the same thing.)
drag handles to resize the window, you'll have to code those yourself, as you expected.
You might also want to look at how the Glade GUI designer does this.
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'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.
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.