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.
Related
I am building a visual studio application and have designed it using visual studio windows form. I am using the siticone library for the GUI but when i lay widgets out on the designer and then run the application all the widgets move. The buttons do not but the labs on them do. Also i have added a user control page that moves aswell. Please Help.
Cheers.enter image description here
Make sure that your Winform Font style and size match with all child controls including all Siticone controls.
Verify that you have anchored your controls accordingly on your form or panel control.
i was wondering if there was any way that you could hide certain GUI components in the GUI editor, in rad studio. not actually hiding the component on run with .hide() function, i mean just so that i can work on the other components and design. for example if i have a panel that pops up that is reused over and over again with certain elements but that covers my screen i cant work on the other components. is the only solution to create the components dynamically?
You know when you create a web app, you can hit F12 from your browser and be able to edit things such as style sheet, remove dom elements etc. on the fly.
This makes for a quick turn around when developing a UI. A real time saver!
Otherwise there's a lot of compile, deploy and clicking click to get to the area you wanted to test. And if the area you're testing is at the end of the workflow, the pain is that much more. I find doing this to be frustratingly time consuming when all you want to do is just change the font size to make it look "better".
Is there any tool similar to that in WinRT environment? Is this just the nature of Mobile App development or is there something out there (regardless of platform) that allows you to edit the UI on the fly?
Yes, you have several options available to you.
First, Blend for Visual Studio--which is installed with Visual Studio Express for Windows--is a great styling tool. It shares the same project structure with VS, so you can have both running at the same time. In VS, in fact, right-click a project in Solution Explorer, select Open in Blend, and there you are.
Blend actually loads the app and executes the JS code, so all dynamically-created elements are also in place. It has an Interactive Mode as well that lets you go into the running app, navigate and set state as you want, then exit that mode and work on styling. For more, I have a video in my book (first edition | second edition preview) that shows the basics of Blend--you can specifically go here and check out Videos 2-2 and 5-3 from the second edition). Chapter 2 gives a little intro in the text as well.
The other two options are in Visual Studio itself.
First, when an app it running there's a command Debug > Refresh Windows Apps (F4) that will reload the HTML and CSS without restarting the app. I use this to reload changes for exactly the reasons you mention. This same command is on the toolbar just to the right of the pause/stop/restart buttons.
Second, a running app will have a DOM Explorer pane in the debugger. If you don't see it, use the Debug > Windows > DOM Explorer command to open it. In that pane you can navigate the DOM tree (like you can in Blend's Live DOM pane) and locate the elements you care about, or you can use the leftmost button in the DOM Explorer to go select and element directly in the app.
On the right side of the DOM explorer you then have tabs for Styles, Trace, Computed, Layout, and Events. You can make changes directly in the Styles pane and they're applied immediately. I use this all the time, in fact, to try out things.
I have a 2 minute video in my book for this as well, see here. Some docs are on http://msdn.microsoft.com/en-us/windows/apps/hh696632.
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.
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.