Say, I have an Image control (which seems to be a window-less control) and I want to make sure that it is on top of a TextBox. No matter what I do, the Image control will not appear on top of the Text box.
Is there a way?
P.S. I know I can use a PictureBox, but it does not support transparency, thus I must have the Image control.
There is no way to place an image control over a normal textbox as they are drawn onto the form itself so will always be below any other windowed components.
If you have VB6 installation media there are drawn (windowless) versions of controls including a TextBox you can use that will (probably) do what you want; http://support.microsoft.com/kb/184687
A custom usercontrol of some kind if probably better .. what is it exactly you want to overlay the textbox with?
The Image Control is considered a graphical control, like shapes, so it is always inferior to text controls. If you really want a transparent image, you can use a Microsoft 2.0 Form instead(only if you have it). Images there can be on top of textboxes, and you can make it transparent by setting the Backstyle to Transparent(0).
Completely different approach to my other answer (hence the seperate Answer), but you can set AutRedraw and ClipControls on your Form to false and it will allow the Image control to render on the same layer as a windowed control. You can get some flakey redrawing in some cases but for a quick solution you could try it.
http://msdn.microsoft.com/en-us/library/aa733621(v=vs.60)
I've created a tranparent overlay control to add a kind of annotation layer on top of a VB6 app. I'll attempt to describe it from memory, and if that doesn't provide enough information then you can post back and I'll try to dig up the code.
First, add a new USerControl to you application. Give it a name like ImageEx, PictureEx, or TransparntImage. There are several properties that you will need to use. Ensure the control is Windowed, so it can sit on top of other windowed controls. Locate the MaskColor property and set it to Cyan (or whatever color you elect to use to indicate a tranparent area. There might be an addition property enable the masking behavior, just browse the properties. Set the control background color to that of the MaskColor. At this point you have an invisible control. In my control I painted on top of the surface for annotations, but you can PaintPicture or maybe even set the image property for a really simple approach.
Of course, to make this a re-usable control, you will want to code in your own properties that allow the MaskColor and image, etc to be set so that you can the drop one of these on any form you want.
Some links:
MaskColor Property
MackPicture Property
1) Remove all your textboxes , labels and ... (But memorize their name and location in the form)
2) Go to (project > components) and mark the (Microsoft Forms 2.0 Object Library) then click ok
3) Now you can see new controls under your default controls in your toolbox...
4) Use its textbox and label controls instead of the default controls
5) Right click on your Image Control then click (Bring To Front)
Related
What is the name of event when we start drawing the markup(circle, arrow, rectangle etc.) on the shape when in edit mode? And can we change the markup type in this event?
Problem is: When we are in edit mode and have selected specific shape and color to draw the markup, and in between if we select any markup, the drawing tool takes up that shape and color for the next markup to be drawn ignoring the markup type and color we selected earlier. Is this the normal behavior. Why does the drawing tool take up the configuration of the last selected markup and overrides the type we define through - new Autodesk.Viewing.Extensions.Markups.Core.EditModeCloud(markupExt);
Thanks!
That's an interesting question. I believe the current behavior of markups is as-designed because one would typically only select a markup if they wanted to move it around, scale it, etc. That's why in the current implementation, selecting a markup automatically enters its edit mode.
At the same time I understand your view where if I already activate a specific edit mode, it seems strange that that edit mode would change after simply selecting another markup.
Let me bring this up with the engineering team, and in the meantime, I'd suggest using the Autodesk.Viewing.Extensions.Markups.Core.EVENT_EDITMODE_CHANGED event to detect a change to the edit mode, and if needed, reset the mode to the one you want.
I'm trying to handle background color properly in a dynamically generated property sheet in dynamically generated property pages in win32 api using MFC (though I expect my question is general, and not restricted to MFC, but since my code and examples use it, it's germane to my question anyway).
So we have a:
CPropertySheet
containing multiple
CPropertyPage
I generate the contents of any given page dynamically - from file resources using a custom dialog definition language - all irrelevant other than to say - a list of controls and their coordinates is created within a given page, and the page is resized to accommodate them. This logic is working beautifully.
However, what doesn't work is that the controls and background of each page draws using the dialog default color/brush.
I've tried a number of ways to attempt to force it to draw using the white color/brush that a hard-coded property sheet / page would.
There are two important pieces to this:
Page Background
Control (on the page) background
For #1, I've tried:
acquire the background brush from parent window class (it's dialog bkgrd) (same is true if I do this and ask the tab control)
change the property page to use WS_EX_TRANSPARENT (PreCreateWindow is not called by the framework when generating a page viz PropertySheet::AddPage)
For #2, I've tried:
overriding OnWndMsg / WM_CTLCOLORSTATIC to forward that request to (A) the parent (sheet), and (B) to the tab control (which is what wants the white in the first place).
However, anytime I use any of the above "ask for the background / forward the request" up the chain to either the sheet or the tab control - I get the dialog background color, never the white I'd expect.
Using Spy64, I can see that for a fully hardcoded property sheet / page - that the only discernable differences I can see is that the dialog window created in AddPage (or its moral equivalent) has WS_CHILD instead of mine which has WS_POPUP (the rest of the styles appear to be the same, such as WS_VISIBLE|DS_3DLOOK|DS_FIXEDSYS|DS_SETFONT|DS_CONTROL and WS_EX_CONTROLPARENT.
So, other than the WS_CHILD, I see no significant differences from what I'm creating and from another property sheet that works properly from a standard resource (i.e. hard coded).
I'm also flummoxed as to how this works normally anyway - since forwarding things like the ctrlcolor message doesn't respond correctly - and asking for the windows background colors similar doesn't - then how is it in a standard case the background colors of controls and pages comes out as white, and not dialog background?
Any ideas or help would be appreciated - I'm kind of running out of ideas...
When Visual Styles were added in Windows XP they really wanted to show off this new feature so they made the tab background a gradient (really a stretched image) instead of a single color and this caused problems in old applications that did custom drawing with the dialog brush as the background.
Because of this, only applications with a comctl32 v6 manifest got the new look but there was a problem; old propertysheet shell extensions would load in new applications (including Explorer) and things would look wrong.
To work around this they also require you (or your UI framework) to call EnableThemeDialogTexture(.., ETDT_ENABLETAB) to get the correct tab page look.
As if things are not tricky enough, there is a undocumented requirement that you also need a button or a static control on the page!
If you have custom controls they have to call DrawThemeParentBackground when you draw if they are partially transparent.
Turns out my old code had defined an ON_WM_ERASEBKGND handler - and removing that (and all of my above attempts) makes it work.
So simply doing NOTHING is the correct answer. D'oh!!!
I'm leaving my shame here in case someone else trips on this! [Whoops!]
(Still interested if anyone has deeper insight into how this mechanism works under the hood)
We are all familiar with text highlighting. You hover over any "text" in any application on your Windows OS, your cursor changes into an I-Beam, and you can click and drag across the text to Highlight it. This highlighted text can be copied to the clipboard for later use.
Some applications modify the default highlighting behavior by changing color, opacity, or even shape. Some applications allow for column selection (e.g. Visual Studio "alt-click-drag" creates box like highlighting)
I have scoured the depths of the internet, but I can't seem to find a solid source of information that would explain how one would modify the behavior of text highlighting.
How would I implement column/block text selection, and modifying the appearance of the highlighted text in a compiled application.
Since applications can do this in various custom ways, there is no single solution to change how all of them style text selections.
Many will rely on the current color scheme (using GetSysColor) to determine the highlight colors. So you could modify the scheme and maybe affect the colors used for many applications.
To do this programmatically, you would use SetSysColors to change the COLOR_HIGHLIGHT and COLOR_HIGHLIGHTTEXT values.
Other applications might rely on the current theme (using GetThemeColor). To affect those you'd have to select a different theme that has the colors (and perhaps other styling choices) that you want.
A lot of apps use their own hard-coded color schemes, so you won't be able to programmatically at all.
I'm not sure what you mean with the web application part of your question. A web application is some HTML, JS and CSS that make the browser interact with your system. Any custom selection (coloring) logic that the web application provides, has to be implemented by the browser.
Also you have to realize that "(text) selection" is an rather virtual principle. An application can just render a colored shape (like a blue rectangle) and copy something to the clipboard when it receives a WM_COPY message.
Windows provides in basic substring selection functionality for (rich) edit controls (i.e. start and end position), but for something custom like column selection, custom code is required.
Read more about this in Making a rectangular selection in a RichTextBox with Alt-Left-Mouse sweep?.
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.
I'm using MFC (yes must be MFC and no I can't interop with .Net) to create a CFrameWnd.
My goal is to create a CFrameWnd containing a CFormView which is based on a Dialog Template that resembles something like:
I have got the frame and view to display, and I have an Edit control on there. Now what I want is to have a CToolbar aligned to the top of the Edit Text control but not docked to the top frame.
Ideally I would like to have a child frame/view that I can dynamically add in place of the Statement Group. That way I could just dock the toolbar as normal.
The thing that I find odd is that I could easily achieve this if I had a splitter in there by using the CreateView function. I really don't want to have a splitter and feel there ought to be another way.
In summary, these are the question I need help with:
Q1 - How can I have a CFrameWnd within a CView (like what CSplitter::CreateView does)?
Q2 - How can I position a toolbar within a CView without docking or floating it within another frame (I'm more than willing to resize, position it manually if only I knew how)?
Now I really appreciate how easy things are in .Net.
I wouldn't recommend sticking a CFrameWnd within a CView. You'll be fighting MFC all the way, basically living in a world of ASSERTs as the internal functionality such as message routing assumes that Frames don't live in views.
Instead just use a CWnd instead of the CFrameWnd and in the 'Create' method manually create the toolbar and the edit ctrl and size and position them yourself (create a AdjustLayout method that uses CMFCToolbar::CalcFixedLayout to adjust the position of your other components).
A great example of this is in the Visual Studio sample app PropertiesViewBar.cpp:
http://msdn.microsoft.com/en-us/library/bb983983(v=vs.90).aspx
Note: You might need to override OnCmdMsg to extend the message routing to the internal controls.