In my application when I make a form as a child form of my main MDI parent form, the child form stops showing Windows 7 default shadow effect behind forms. How do I get child forms shadow to show?
Form obj = Application.OpenForms["My_form"];
if (obj != null)
{
obj.Focus();
}
else
{
My_form c = new My_form();
c.MdiParent = this;
c.Show();
}
This is normal, entirely by design. MDI child windows are not top-level windows, but rather a special type of child window that is designed to be hosted in an MDI parent window.
The Desktop Window Manager (DWM), which is what is responsible for the Aero effects in Windows Vista and 7, only adds drop shadows and glass transparency to top-level windows. Your MDI child windows don't qualify for this treatment. In fact, the shadow isn't the only thing they're missing--they look like they're drawn using the Aero Basic theme, which is pretty visually jarring on a machine that is using the Aero theme for everything else.
Unfortunately, there's no fix for this other than to switch away from MDI altogether. The multiple document interface has been pretty much deprecated nowadays anyway. Such interfaces provided more difficult for people to use than was originally expected, and they've fallen into almost complete disuse, particularly by Microsoft's own software. You'll notice that rather than using MDI, Microsoft Office uses multiple top-level windows. You should probably consider doing the same thing with your own software.
Another popular alternative to MDI is a tabbed interface, commonly used by web browsers. Here, you have a single, top-level window and all of the child windows appear as "tabs" at the top of this main window. The user can switch among child windows much more easily and intuitively as tabs rather than as independent MDI children.
I got the answer finally , if i make a form as child form like
c.MdiParent =this;
It makes the appearance of the form as flat , If you like to show the form as default windows like forms
dont make the form's mdi parent !
Related
I am supporting a large existing windows forms application. It makes use of panels that sit over the other content on forms. The panels have their visible property to false in the designer. At runtime, visible is set to true when appropriate to display the panel.
This system works fine. However, it's hard to maintain the forms that have these panels because the designer shows them even when they should be invisible. Here is an example:
The Panel_archive has Visible set to False. However, it's still showing in the designer. This makes it hard to edit the fields that it hides.
Is it possible to hide this panel (and all its child controls) so that I can edit the stuff behind it? I assume there is a way to do this (at least, in earlier versions of the Visual Studio IDE) as the original developers created the forms like this. However, I can't find a way.
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)
In other words, if I want to write a winforms db application with an appearince like VS that has docked panels and also the ability to show/hide forms within some of those panels, how would I structure the interface? How would I have the ability to open several disparate forms at different times (with big data grids on them) while avoiding floating forms and also using memory efficiently? I want to avoid floating windows.
Check out this article to build a VS like interface:
Visual Studio IDE like Dock Container
I haven't tried the component myself but it looks interesting.
Visual Studio is definetly MDI
In the technical sense, Visual Studio is an MDI application whose document windows are anchored by tab navigation.
MDI refers to "multiple document interface," and refers to the fact that there are multiple documents open and visible inside a larger parent window.
In the modern application development realm, typically MDI has been frowned upon -- but that was the "old school" MDI, with the free-floating windows. Those are widely considered to be a usability nightmare.
On the other hand, MDI implemented as tabs inside a parent window is so successful from a UI consideration that even environment which didn't traditionally have MDI (EG, Mac OS) are implementing them.
In order to implement something like this, you can "roll your own," or you can use any of a variety of custom control/API packages which will allow you to easily develop tabbed-interface MDI apps. One of the last things I did with Infragistics NetAdvantage (before moving away from it) was a Visual Studio-inspired app, with docking sidebars, search results as a pane at the bottom, and all the primary data forms as tabbed MDI documents. (Indeed, WinForms is one of the few places Infragistics really shines.)
In terms of memory management, that will be on you. :)
I think technically Visual Studio would be classed as an MDI.
The main form holds disparate controls. Each of these controls can then be docked as required etc. Visual Studio for example has a single control (with multiple tabs) to display the documents you edit. A single control with multiple tabs that holds (eg) Solution Explorer, Properties etc etc.
As a starting point to creating your own IDE style interface I would create a form with 5 panels, one docked to top, one to left, one to right, one bottom and one 'fill'
Thats your starting point. Add splitter bars to allow the panels to be resized. Each panel can then hold a Tab control, and each tab holds a 'MdiBaseControl'
An MdiBaseControl can be whatever you want. So in VS terms you have things like SolutionExplorer, Properties, Breakpoints, FindResults etc etc.
Each MdiBaseControl can be dragged from its current tab and dropped into any of the docked panels (which then adds it to the Tab control as a new tab)
I just noticed that Developer Express have some controls for building IDE-style interfaces.
In both interfaces, multiple forms can be seen at the same time but in MDI, things float freely. In this sense, Visual Studio is a SDI.
In Vista and Windows 7 almost any time the system uses a standard Listview (ie: Explorer Windows) it's accompanied by a little split button that shows a slider when the split is clicked that allows you to switch between the different views available for that listview (Tile, Details, List, etc.) as well as sliding smoothly between icon sizes (from 32x32 is to 256x256) using the top half of the slider.
This is a cool little bit of functionality, so I was wondering: Is that control available to developers, and if so what is it called and where is it documented? (Win32/C++ preferred)
Turns out in Windows 7, the explorer window is no longer a standard listview (though it does an extremely good job of looking like one). Open Spy++, point it at an explorer window list pane, and you'll see a classname of "DirectUIHWND" instead of the old "SysListView32".
The actual slider itself is indeed a real ComCtl32 slider; so you could perhaps roll your own; but as far as I know there's no way to reuse the existing explorer pane's functionality.
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.