We have a legacy ActiveX grid control built in VB6. In one of our usage scenario, we would like to resize it alongside with other intrinsic VB6 controls like PictureBox using the 'cached window redrawing' functionality provided by the WinAPI DeferWindowPos call. This technique works like a charm for all form controls except our ActiveX. The main problem is that the control is resized as expected, but its contents aren't redrawn. It seems, it remains the same, i.e. its effective size isn't changed.
The MS Spy++ utility reports that the control's window is changed, but if we access the control's Width or Height native VB properties, they remain the same as if the control was not resized at all!
The question is: how to reflect the changes made by DeferWindowPos to the VB Width and Height properties of a custom ActiveX control?
One of the possible idea is that we need to process some special native window messages like WM_WINDOWPOSCHANGING inside our ActiveX and call the appropriate UserControl.Extender methods or properties, but it seems in this case we lose the benefit of the DeferWindowPos call as in fact we call the good old VB6 Move method of the control...
Related
Through experience I have found that the native windows forms/components don’t like to be changed. I know using Delphi or Visual Studio you are given native windows components to populate a form or window with and then you attach code on events that these components may do (onClick for example).
However, how do all of these programs like Word or google’s Chrome browser alter the standard windows’ window? I thought it was somehow protected?
Chrome seems to have tabs actually on the window’s frame?
I know you can also get toolkits like Swing and QT that have their own controls/components to populate a form. How do these work? (How does the operating system/computer know what a non-native button should act like? For example; Chrome's back and forward buttons, they're not native components?).
I can understand how OpenGL/DirectX window would work because you’re telling the computer exactly what to draw with polygons/quads.
I hope this question is clear!
Windows does not protect GUI elements. Windows and controls can be subclassed to handle various drawing operations in a custom way. For example, windows may override and reimplement the handling of the WM_NCPAINT message to draw a custom titlebar and frame:
http://msdn.microsoft.com/en-us/library/dd145212(VS.85).aspx
Some Windows controls have an "owner-draw" mode. If you use this, you get to draw the control (or at least vital parts of the control), while Windows takes care of responding to user input in the standard way.
Swing ant QT draw their own widgets at a low level using basic primitives, but they also have theme engines which can mimic the native controls.
Qt moved to native controls a while back. As for how swing does it, it gets a basic window from the OS. Then much like Opengl\Directx it does all of the drawing with in that window. As for where to position things that is what the layout managers do. Each manager has a layout style horizontal, vertical, grid, components it has to draw and a section of window it is expected to fill. From there it does some pretty easy math to allocate its space to its controls.
There's no magic: non native controls are simply drawn on a blank window. Or, instead of being drawn they may be represented as one of several bitmaps based on state (ie: a button may be represented as a .png for the normal state, another .png for the pressed state, etc)
I have a custom control (inheriting from control; targeting .NET Compact Framework v2) that has a bitmap property.
Currently an instance of the control on the form designer will only paint the selected background color and writes the namespace.control.name overtop.
How can I have the image be rendered by the form designer after it's selected in the property editor?
Edit: The control is fairly basic but I am overriding onpaint and onpaintbackground
Edit2: In an effort to determine the cause I wrote a much simpler control. It's just a bitmap property and a call to graphics.drawimage in onpaint (so a cheap imagebutton). This too fails to render. I even included a check to make sure it wasn't trying to render a null image and never refreshing or anything, but no luck.
Are you manually painting (i.e. overriding OnPaint and drawing that Bitmap out)? Generally speaking rendering in the designer for a very basic control should work.
You'll get the box with the control name if the designer hits something that it can't handle (a P/Invoke fore example) and so often you have to "protect" the device specific code from being called by the designer.
Try backing out functionality until it starts rendering properly to figure out where it's failing (becasue you can't really debug this stuff any other way).
How do I make modal windows with non square borders, for instance a modal window which has a corner to indicate it's coming (sorta being shout) from a text.
Create your modal dialog window as you would normally and then call SetWindowRgn API to set the non-rectangular region you want to achieve.
Note that this will not allow you to do semi-transparent effects, it works only for opaque windows. If you want alpha blending, your window has to be top-level (alpha transparency is not supported for child windows) and you should be usign different APIs.
Also, this works for C++ clients using the native Win32 API. If you are writing C#/VB.Net code, you need to specify if you are using WinForms or WPF, as the solution is different for these.
I have a VB6 program which uses comctrl32.ocx to display a progress bar. I've also had programs using mscomctl.ocx. However, it is displaying it using the ugly, old-style blue boxes progress bar instead of using the new-style progressbar (which presumably varies depending on the OS). Other programs which reference that same ocx file display the new-style progressbar (unless I run them VB6, in which case they still use the ugly one). All of the properties of the control are the same. Any suggestions on what I'm doing wrong?
Most likely, your application doesn't have a manifest and therefore uses the old pre-Windows XP style common controls. vbAccelerator has a great article on how to add one
I have a custom control: it's managed code, which subclasses System.Windows.Forms.Control.
I want to add things like edit boxes, selection lists, combo boxes, radio buttons and so on to places on this control. An easy way to do this is to simply add instances of these classes to the Controls collection, so that they become child controls.
Adding them as child controls might create some subtle problems, for example:
IE 6 select controls(Combo Box) over menu
I have scrollbars on my control which appear to scroll the contents of the control (the contents are bigger than the control itself); when a child control is near the edge of the screen then I'd like to half-display (i.e. clip) that child (i.e. to have half of it located off the edge of the physical screen), but a true child control cannot be located outside the border of its parent.
Are there other potential problems?
When I use IE7 to display http://www.tizag.com/htmlT/htmlselect.php (for example), which contains combo boxes etc., and when I then use Spy++ to spy on IE7 when I'm doing that, I see only a single Window/control instance with no children (whose class name is "Internet Explorer_Server").
I'm guessing this means that in IE7, the functionality to render a combo box is built in to the IE7 control itself, and that IE7 does not use standard controls as child controls.
Questions:
Is it better to reuse standard controls as children of a custom control, or, to reimplement the functionality of standard controls within a custom control itself?
Do you have any caveats (warnings) to share, related to either scenario?
If I wanted to reimplement the functionality of standard controls within a custom control, do you know of any existing code (which implements this functionality) that I could re-use?
If such code already exists, I don't know how to search for it (my searches find, for example, owner-draw combo boxes, and extensions to standard combo boxes): perhaps few people reimplement the standard controls from scratch?
Edit
I found a semi-related question: How to render a control to look like ComboBox with Visual Styles enabled?
Yes, Internet Explorer draws the controls using the Windows theming APIs. You can do this too using the types defined in the System.Windows.Forms.VisualStyles namespace.
The IE team did this to avoid performance problems of having so many controls, each receiving window messages, on screen at once. For example, looking at this StackOverflow.com page, I see 30-40 link label controls, 10 buttons or so, 20+ labels, etc.
It should be noted the Zune software, which is .NET managed code, also uses custom controls; if you try to use Spy++ on any of the controls, you'll see they aren't real Win32 controls. You may use Reflector on the Zune software to see exactly what they're doing. If I recall right, they're using a custom managed UI framework that's included in the Zune software.
As far as rewriting these controls from scratch, I think there's a ton of work to be done. It sounds easier than it really would be.