I am using MFC to create a dialog project and trying to impart color to the buttons.
I came to know that the only way you can do is to make the button owner draw. OnCtlColor() does not work for buttons.
I am able to color the button overriding OnDrawItem , but the problem is that , in the process the 3D cool look (with slightly rounded corner that you get in Win7) is lost.
Is there any way to retain the native look and color the button on top of that?
This is not a trivial task. As long as you are using themed controls (what you want), you cannot do more than the theme allows.
You would have to re-implement drawing of the button on your own, making use of the theme API as much as possible to retain themed look, yet sneak-in your color.
Though note that you can hardly achieve anything better than, what .NET WinForms do, when you set the Button.BackColor:
See also question how to set Button BackColor?
Disassembling the WinForms ButtonStandardAdapter.PaintWorker will give you some idea and API you need to use. Beware, you need to do lots of coding!
For C++/MFC code check out Vista themed Owner-Drawn and Full-Custom Push/Menu/Image Buttons on CodeProject. Which probably actually does, what you want already (the SetBackgroundColor method), so you might reuse it.
Related
I'm building an application to generate an array of colors based on a color chosen by the user.
The default on Mac OS X for color selection is to open a NSColorPanel containing multiple NSColorPickers. But, as the color selection process is the main interaction the user will have with the app, it'd be better to avoid the extra clicks and panel-popping in favor of a more straightforward way.
So, is there any way to add a NSColorPicker object to a window?
I know this is an older question, but check out NSColorWell. From the docs:
NSColorWell is an NSControl for selecting and displaying a single color value.
Interresting Question.
I strongly doubt it (but would love to be proven wrong). NSColorPickers are not NSControls (nor NSCells) so there's no clean wrapper to insert into a window.
Even if you were to instanciate an NSColorPanel and get a reference to its contentView and copy it (with all that defines the color picking controls) to your own window... there's no obvious way of obtaining the color value. NSColorPickers are plug-ins so you can't forsee the controls of a colorPicker.
The only other way I can see (and that's a stretch) would be to manually load the NSColorPickers plug-ins directly. I don't know how successfull this would be.
File a bug report and request the feature?
I want to put help buttons on all my windows, like this:
But when I put the help button in, the minimize/maximize buttons disappear. Does Windows forbid having the min/max buttons together with the help buttons? That would be disappointing because that would mean I could put the help button only on dialogs and not on frames.
If Windows does forbid this, it would be nice to see an official Microsoft document which talks about this policy.
It is not possible through setting windows styles. If you really wanted to you could set some hooks that would probably let you do what you want, but I would not recommend doing that. You can mimic the functionality of the help button by sending the WM_HELP message.
According to MSDN, the styles WS_MAXIMIZEBOX and WS_MINIMIZEBOX can not be combined with WS_EX_CONTEXTHELP.
Although it is true what daalbert says, with some effort it is indeed possible to draw just about anything properly on the window frame. Of course this is in no way "official" and the limitation that daalbert mentions still stands.
You can listen for WM_NCPAINT and draw the button yourself with the help of DrawFrameControl with DFC_BUTTON (which makes sure it will look like the real thing). Use WM_NCHITTEST and friends (WM_NC*BUTTON*) to find out whether the button you draw gets clicked.
So yes, it's technically possible to achieve what you want but usually not worth the extra effort.
Just wanted to have this on record for completeness.
I would like to know what should I do with GUI layout under WinAPI/MFC.
In the ideal world I should just create the form/dialog via resource editor, and everything should just work. In the real world the dialog editor is ancient behemoth from the ice-age and doesn't support most of the comctl32 controls.
This is where the problem creeps up. Dialog editor uses DLU units, and when I create new controls at runtime, I have to express them in pixel offsets.
I stumbled upon one article about calculating DLUs based on font http://support.microsoft.com/kb/145994/en-us, but also saw a warning somewhere that dialogs can have non system fonts in some circumstances, so this approach is not very safe. Plus the article seems to look only at English characters, without regard to all other characters in unicode space which might be wider?.
Has anyone done a research in this direction and found a better way?
P.S.: No Winforms/WPF/Delphi, requirements.
the dialog editor is ancient behemoth from the ice-age and doesn't support most of the comctl32 controls
It doesn't need to support the controls directly, you can still use it just for positioning by inserting it as a custom control and filling in the window class in the property page. For example, that's how I insert link controls in VS2005: as a custom control with class "SysLink".
MapDialogRect (mentioned in the article) is the function that Windows uses to translate the dialog units in the dialog resource to pixel units. MapDialogRect works (where GetDlgBaseUnits fails) because its given an actual handle to the dialog box, and can send it a WM_GETFONT message to retrieve the actual font the dialog will be rendered with.
This may not be the kind of question one should ask on StackOverflow, but here's a frustration that I've been trying to find a work-around for.
When using the form designer, suppose the entire form does not fit in the space allotted to the form designer, and I have a control say, down near the bottom of the form.
If I try to re-size that control, or move it using the mouse, the work area will auto-scroll to the top of the work area. This essentially pulls my control to the top of the screen. It isn't possible to scroll with the scroll wheel while "holding" a control, and even ScrollLock does nothing for me.
Is there any way to just turn the auto-scrolling off? That way I can at least work on my form without guessing numbers to type into the properties window.
Can't you just turn off autoscroll for the form?
I think it's off by default.
Form.AutoScroll = False
How would I go about implementing something along the lines of "scrubby sliders", like in Photoshop and quite a few other image-processing applications?
They are slightly hard to describe.. basically you have a regular numeric input-box, but you can click-and-hold the mouse button, and it functions like a slider (until you release). If you click in the box, you can select text, edit/paste/etc as usual.
The Photoshop docs describe it, and I put together a quick example video (an example of the sliders in Shake)
Another similar implementation would be the jog-wheel in Final Cut Pro, which functions similarly, without the numeric readout being underneath.
I can't seem to find any mention of implementing these, although there is probably alternative names for this. It is for a OS X 10.5 Cocoa application.
It is for a colour-grading application, where a user might need to make tiny adjustments (0.001, for example), to huge adjustments (say, -100 +100) on the same control. A regular slider isn't accurate enough over that range of value.
Copy-and-pasting values into the box would be a secondary concern to scrubbing the values, and the Photoshop/Shake setup really well. The unobviousness of the control is also of a low concern, as it's not a "regular desktop application"
I've encountered those. They suck, because they prevent the user from dragging to select the text of the number.
A better idea would be a miniature slider beneath the field that expands to a full-size slider when the user holds down the mouse button on it and collapses back to its miniature size when the user releases the mouse button. This way, the selection behavior is still available, but you also provide the slider—and in a more obvious way.
There's no built-in class in Cocoa for either one. You'll have to implement your own.
I doubt that this exists in Cocoa framework. As far as I remember it is not mentioned in the Apple Human Interface Guidelines.
You can develop one yourself by using a custom view and tracking mouse events (-mouseDown:, mouseUp:, -mouseDragged:).