I am building and maintaining a Win32 app using Visual Studio.
I have recently edited the .rc file adding WS_THICKFRAME to my dialog STYLE line for all dialog windows to allow them to be resizable.
My current problem is, when I resize a window, its content remains fixed to the left. How can I make the window's content remain centered when resizing using the border?
Pointing to any relevant documentation on this would also be helpful, as I have not had lucky finding that.
If you only want to reposition (rather than resize) the individual controls, an easy way would be to create a non-modal container dialog to hold the controls, make that dialog a child of the resizable dialog, and then when you handle WM_SIZE for the outer dialog, you only have to reposition that one non-modal dialog.
Your new position is ((newWidth- controlDlgWidth) / 2, (newHeight-controlDlgHeight)/2), where controlDlgWidth, controlDlgHeight are the width and height of the child dialog.
I say to use a non-modal dialog for this, so that you can continue using a resource script, rather than needing to add a whole bunch of explicit CreateWindow() calls.
Related
Is there a way, after selection of a color, to programmatically hide the color picker of the TComboColorBox? I've searched on the web and Embarcadero community but couldn't find a way to do this.
The answer is no, there is no designed way to hide (collapse) the popup programmatically. And you did not explain why you think it would be necessary to have.
Keep in mind that there are 4 subcontrols, that the user may want to use:
a THueTrackBar,
an alpha channel trackbar,
a color quad, and
a hex color value edit box.
An automatic collapse of the popup would be just annoying.
The user can at any time decide to close the popup simply by clicking on the constantly visible bar.
With reference to your comment:
After your answer, I realized that I must implement a color picker component that shows a rect containing a TComboColorBox and a TButton as childs. Clicking the child button, in turn, hides the container rect itself.
I have told you twice that the user can close the popup part of the TComboColorBox simply by clicking on the component (the base part of it).
In fact, the user can click anywhere outside of the popup window in order to close the popup window. The popup is closed immediately when the focus moves away from it.
In my opinion there's no need for a special "Close" button.
I'm currently working on a project that utilizes an MDI Form. What I would like to achieve is that when the user hovers over one of the menu options in the MDI menu, a ToolTipText appears describing what can be found in said menu. I'm aware of the fact that in some options for VisualBasic 6, ToolTip is supported. However, I can't seem to add this to the MDI Form, or add a label control for that matter. Has anyone ever run into this problem, and if so, is there a workaround or a solution?
Please let me know if you have any additional questions or comments. Thank you in advance.
I'm not aware that any true menus on a VB6 for (even non-MDI) have a tool-tip property; hence, neither does the MDIForm when one its child forms has its menu displayed.
However, there are a few controls that can be put on the MDI parent form. The most useful of these is probably the PictureBox, into which you can then place any type of control, such as CommandButtons. It must be "docked" to either the top or bottom of the MDIForm, using the PictureBox.Align property. Controls within the PictureBox can be located any way you wish, and can have their normal ToolTip properties set.
Another MIDForm-usable control that I've had good luck with is the ToolBar control, which comes in as part of the CommonControls component. Like the PictureBox, it has a .Align property to set it to the top or bottom of the MDIForm. You can put any reasonable number of "buttons" on it, and have reasonable control over their appearance (graphics, etc.); apropos the OP's query, you can assign a ToolTip to each button. It wouldn't be difficult to have the buttons change depending upon the currently-active form, just as the MDI menus normally do.
One other alternative that can be considered (but may be quite tedious to implement) could be reading the Mouse.X and Mouse.Y properties for each MDI menu and setting the captions of a Label control (or TextBox) using the Mouse Hover event.
You'd need to find the top left and bottom right points for each MDI menu and if it is within the box, you can show your label control with the intended caption. But note that you can't just put any controls on an MDI Form except maybe PictureBoxes, Toolbars and Coolbars, etc.
So the Label or TextBox control would have to be first placed on top of a PictureBox control which can be top aligned.
I am trying to create an interface for my application using Qt Designer. I want it to have a tabbed, ribbon-style set of controls at the top, and a MDI-style area with docked windows which I plan to show and hide depending on which tab of the ribbon is currently selected. I am just beginning with Qt Designer as well as Qt4 itself for that matter so I'm not quite sure how to setup the window, which widgets and layouts should I use etc.
It's quite obvious there should be a QTabWidget at the top, but I'm not sure about the bottom. Should I use a QFrame? A QMdiArea? A dock widget? What layouts can I use to make sure the tab widget has a fixed height, occupies the whole width of the window at all times and the bottom area scales as the window is resized?
I've read in the manual that splitter layouts allow for manual adjustment of the size of the widgets they contain, but I can't drag the box size of a widget after I place them inside a splitter. Thus I'm unable to setup the area below the ribbon. Anyone, help?
You should look into the QMainWindow and check the multiple utilities it can provide you (Toolbar, StatusBar, DockWidgets, CentralWidget, etc...).
The way I understood your case is that you will always have the MDI Area visible, and that the tab bar will only be used to change the dockWidgets. Here's how I would do it.
The centralWidget of the mainWindow would be a QWidget with a QVBoxLayout containing a QTabBar widget first (up) and a QMdiArea under it. The sizes should be handled automatically.
This will allow the user (or you) to dock widgets on the left, bottom, top or right areas of the mainWindow's central widget. Keep pointers to the dockWidgets to be able to move and show/hide them at will.
Hope this helps.
VTK Designer, which is built on Qt, has a Ribbon-ish interface. You might take a look at the source code for reference.
Is it possible to make an NSColorPanel 'Pop Up', almost like a popup menu, from the NSColorWell?
I don't like how it's implemented as a palette, as it's sometimes not obvious which NSColorWell it's associated with.
Thanks!
MT
No, you'd need to create your own color inspector and color well. To get it to pop up above your existing control, you'd need to create a child window and attach it to your existing window. The color palette controls would go in the child window.
However, I'd recommend you avoid doing this. The existing color palette mechanism is time-tested and works across multiple applications.
Looking at a Windows tooltips class hint window, i see that it draws its drop-shadow outside the hint window's actual rectangle.
Using SpyXX - i can get the tooltip's window rect, and class styles:
Rectangle: (440, 229)-(544, 249), 104x20
Restored Rect: (440, 229)-(544, 249), 104x20
Client Rect: (0, 0)-(104, 20), 104x20
You'll notice that the drop shadow you see is physically outside the window that's being drawn. How can i draw a shadow outside around my window, while being outside my window?
Note: The shadow is not drawn using the standard CS_DROPSHADOW class style. i've confirmed this experimentally, and can also see the class style's for the window in SpyXX; it does not use CS_DROPSHADOW:
Windows Styles: 94000001
WS_POPUP 80000000
WS_VISIBLE 10000000
WS_CLIPSIBLINGS 4000000
TTS_ALWAYSTIP 1
Extended Styles: 00080088
WS_EX_LAYERED 80000
WS_EX_TOOLWIN 80
WS_EX_TOPMOST 8
So how can i draw outside my window?
Note: Trying to draw on the desktop DC is out. From Greg Schechter's Redirecting GDI, DirectX, and WPF applications:
Drawing To and Reading From the Screen
-- Baaaad!
Lastly, since we're on the redirection
topic, one particularly dangerous
practice is writing to the screen,
either through the use of GetDC(NULL)
and writing to that, or attempting to
do XOR rubber-band lines, etc. There
are two big reasons that writing to
the screen is bad:
It's expensive... writing to the
screen itself isn't expensive, but it
is almost always accompanied by
reading from the screen because one
typically does read-modify-write
operations like XOR when writing to
the screen. Reading from the video
memory surface is very expensive,
requires synchronization with the DWM,
and stalls the entire GPU pipe, as
well as the DWM application pipe.
It's unpredictable... if you somehow
manage to get to the actual primary
and write to it, there can be no
predictability as to how long what you
wrote to the primary will remain on
screen. Since the UCE doesn't know
about it, it may get cleared in the
next frame refresh, or it may persist
for a very long time, depending on
what else needs to be updated on the
screen. (We really don't allow direct
writing to the primary anyhow, for
that very reason... if you try to
access the DirectDraw primary, for
instance, the DWM will turn off until
the accessing application exits)
You can't draw outside your window in the manner you describe.
If you right click your desktop then go to properties/appearance/effects and uncheck 'Show shadows under menus' ... you will no longer have the shadow.
Bottom line is that this is a product of the window manager not your program.
Q: How do you draw outside of one window? A: Draw inside another window!
First thing to note is that the tooltip class actually does use the CS_DROPSHADOW style - but note that this is a class style, not a window style, so you have to look at the Class tab in the Spy++ properties dialog to find it. You'll see that the tooltips_class32 windows does indeed have this - and a few others.
But that just leads to the next question - how does that work? Well, it seems that Windows implements this by creating a helper HWND to draw the shadow - presumably it's creating another popup window the same size and shape as the one it's shadowing, filling it with gray, placing it directly underneath the main window, and setting it as a WS_EX_LAYERED window so that the shadow can be transparent and fade out around the edges using alpha-blending. And there's nothing to stop you from using the same or similar techniques yourself if you want to add a different type of shadow effect to one of your own windows.
So, long story short: if you want to draw outside of your own window, create a helper transparent window in the general area that you want to draw on, and draw on that helper window instead.
--
Now, if you try to find one of these helper shadow windows in Spy++, you won't find much. Unlike the tooltip_class32 windows, which are long-lived and just hide/show themselves as needed, these shadow windows are a more elusive creature: they are only created for as long as needed, so you'd have to refresh Spy++ while there's a tooltip or popup menu or other window using the shadow present - and that's tricky, since most tooltips and menus will disappear as soon as you move the mouse to switch to Spy++. But it turns out that the tooltips on Spy++'s own toolbar will stick around: so start Spy++, hover over an item in the toolbar, and hit F5 to refresh the HWND tree while the tooltip and shadow are present. Now scroll down, and you should see the third and fourth visible HWNDs in the tree are the tooltip itself, and right after that, a SysShadow window. Unfortunately, since the tooltip and shadow have by now disappeared, if you attempt to get the properties dialog for that HWND, you'll get a get a blank property dialog with an 'Invalid Window' message. If you really want to poke around and see how that SysShadow works, what styles it itself uses and so on, you could create a target app with a long-lived popup that uses CS_DROPSHADOW that you can then explore in Spy++ at leisure.
(Finally, note that these shadows are a completely different thing than the shadows that you see when one app window is on top of another above another since Vista: this type of shadow is part of Aero Glass mode, and handled by the same Desktop Composition Manager that adds the glass titlebar effect, and it doesn't use or need helper windows to implement the shadows.)
I wouldn't be surprised if that shadow is intimately tied to the window manager itself; it is after all the window manager who decides what window gets to paint which parts of itself and when it can do it. I don't see it as rocket science to paint that shadow if control over all that is gained, which the window manager has.