Form resizing
Form resizing
Form resizing
Form resizing
Form resizing
Form resizing Form resizing Form resizing Form resizing Form resizing Form resizing Form resizing Form resizing
Form resizing Form resizing
Form resizing
Go Back  Xtreme Visual Basic Talk > > > Form resizing


Reply
 
Thread Tools Display Modes
  #1  
Old 01-27-2011, 05:09 AM
Poppa Mintin Poppa Mintin is offline
Newcomer
 
Join Date: Jan 2011
Posts: 4
Default Form resizing


I have been trying to discover how to make the contents of a form expand or retract in response to moving it’s borders by grabbing them with the mouse, or by use of the 'Maximise' or 'Restore Down' controls.
The explanation in ‘Help’ concerning TableLayoutPanel, Panel, Anchor and Auto size doesn’t help much, especially as it I can’t get it to work.
Is there a tutorial somewhere that does a better job of explaining how to do it ?

I'm using VB.NET in VB 2008 Express.
My OS is Win.7 (If that makes any difference)

Poppa.
Reply With Quote
  #2  
Old 01-27-2011, 10:19 AM
Mkjo99 Mkjo99 is offline
Regular
 
Join Date: May 2009
Posts: 53
Default

There are no built-in properties/methods to automatically resize all the controls on your form.

To implement custom behaviors like that you will have to write your own routines. Inside the paint event, you would take the width and height values of the container form and use them to proportionally adjust each controls size and position. As you change the sizes on your controls, you would also want to change the font sizes of the text in the control. Sounds like way too much work (unless you only have a couple of controls on your form). Why do you want to do this?
Reply With Quote
  #3  
Old 01-27-2011, 12:51 PM
AtmaWeapon's Avatar
AtmaWeaponForm resizing AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

You'll have to be more specific about what isn't working. Windows Forms was not really made with fluid layout in mind, so some of the controls don't play nicely in the layout panels. I'll go over a whirlwind tour; trying to make an example similar to theirs would take me several days.

(I didn't intend for this to turn into a full tutorial Oh well.)

First things first, you have to understand how Dock and Anchor work outside the context of TableLayoutPanel.

Anchor
Anchor lets you tell Windows "I want an edge of this control to stay exactly the same number of pixels away from the edge of the form as it is right now." If a control is not anchored in a direction, it will move to stay in the same relative position on the form in that direction.

One way to look at this is to consider the anchor to be glue. If you apply no glue to your control (Anchor is none), it will move around as you resize the form because it's not stuck to any edge. It's hard to predict how it's going to move, but there's one useful case for no anchoring: if the control is centered it will always be centered. When you anchor to a side of the form, it's like it's "stuck" to that side and it will move when that side moves. If you anchor to left only, your control will never get farther or closer to the left edge. Anchor to top only, and it never gets farther or closer to the top edge. If you anchor to opposite sides like left and right, when either side moves the control will change its size so it stays the same position relative to each size. Again, think of it as you glued the control to both sides, so if the sides get farther apart the control has no choice but to stretch. If you anchor to all sides, the control will resize in all directions.

Here's the anchoring configurations I use the most:
  • None: I use this when I need something both horizontally and vertically centered but I don't want it resized. (Note you have to place the control in the center for it to be centered; Anchor doesn't do this.)
  • Left and right: I use this when I need a control to fill the width of the form. I make its size the current width, then set this anchor. The control will move about if the form gets taller or smaller.
  • Top and bottom: similar to left and right, it's used when I need something to fill the height of the form and I don't care about its horizontal position.
  • Top and left and right and bottom: I use this when I need a control to fill most of a form. Sometimes it's more appropriate to use a Dock of "fill" for this.
Other combinations can be useful, but I tend to use a TableLayoutPanel instead.

Dock
Dock is confusing. I'm going to be honest with you: in nearly 8 years of WinForms I've never found any dock styles but "fill" and "none" useful. I'll discuss the concept, but not in detail.

Docking a control is similar to moving it as close as possible to an edge *and* applying an anchor in multiple directions. In addition, there's a concept of a docking order, so controls dock to different positions based on where other controls have previously docked. I'm not going to detail that because it's part of what makes docking so confusing.

Here's what happens for the various dock styles; you can only pick one so there's no combinations. I only discussed top and left because bottom and right do the same thing in the opposite direction.
  • Top: the control moves as close to the top edge as it can, is sized to the width of the form, and resizes as if it were anchored to top and left and right.
  • Left: the control moves as close to the left edge as it can, is sized to the height of the form, and resizes as if it were anchored to top and left and bottom.
  • Fill: The control fills all available space on the form, where "available space" is any area that doesn't contain a docked control. It resizes as if it were anchored to all four directions.
Note that when Dock is set, the Location property has no meaning because the control is automatically moved. For dock styles other than None and Fill, only half of the Size property will have a meaning because the control will fill the height or width of the form. When the dock style is Fill, Location and Size have no effect.

Docking is useful when you have some elements you want to stick to the edges of a screen. For example, Visual Studio uses docking. To recreate a VS layout, you might follow this process:
  • Add menubar, dock to top.
  • Add toolbars, dock to top.
  • Add status bar, dock to bottom.
  • Add the right-hand tool windows, dock each to right.
  • Add the left-hand tool windows, dock to the left.
  • Add the code window, set dock to fill.
That order is important because of the "available space" calculations. If the code window were added first, it would fill the entire form and you wouldn't see any of the other controls. If the tool windows were added first, the menu bars would appear to the right of them.

I wouldn't worry about Dock too much other than knowing that Fill makes something use up all of the available space. Unless you're building an application with lots of toolbars and tool windows like Visual Studio, you don't have to know much about it. To some extent, TableLayoutPanel is all you need.

Margins and Padding
This can be an important concept as well. The Margin property is a hint to container controls that a control would like some space around its edges. Not all containers respect it, and it seems like the Dock property ignores it. Padding is similar to Margin, but defines the space a container puts between edges and its content.

I'll give an example, but the information is false. Margins and paddings are inconsistent in Windows Forms and don't work in this scenario. I'll cover them more when I get to a scenario where they do work.

Suppose you set your form's Padding property to 10 on all edges, and you place a button in the form with a Margin of 5 on all edges. If you use a Dock of Fill, the control should be sized to be 15 pixels from each edge of the form. Alternatively, if you don't set the Dock property, the top and leftmost legal location for the control would be (10, 10) (because of the form's Padding), but if you set it at (10, 10) it would appear at (15, 15) and be sized down by 5 pixels on each edge because of its padding. What happens in reality is inconsistent.

AutoSize
This is another inconsistent aspect of sizing in WinForms. Some controls have an AutoSize property. If this is set to True, the control is supposed to be sized to its content. So an auto-sized Label should always fit its text and be no larger than it needs, and if it's in an auto-sized GroupBox the GroupBox should be only slightly larger than the label.

In reality, how AutoSize works is different for each control and can do some unexpected things. For example, Label controls never grow their height or perform word wrapping, so if you're trying to fit a lot of text it won't work. Auto-sized GroupBox controls forget they have a border and a text label, and often render themselves over their content. I almost always end up turning off AutoSize for any control that supports it in Windows Forms.

TableLayoutPanel
Now that you have a good idea of the fundamentals of Windows Forms layout, it's time to learn abot the TableLayoutPanel. As I pointed out, there's some problems with the layout properties in WinForms. TableLayoutPanel fixes many of them.

You can use TableLayoutPanel (TLP) to define cells with sizing behavior, then put controls in the cells and use docking and anchoring to configure how the control is sized within the cell. That's the important thing: both cells and the controls they contain have independent sizing behavior. Understanding how they interact is key.

There are many combinations of sizing behavior, but some are more useful than others. I'm going to focus on things that I tend to use often.

For starters, I almost always start my form design by dropping a TLP and setting its Dock property to fill. Almost all of my WinForms layout for the past 5 years has been in terms of this design. I'm not going to argue it's the best design, but it's easy to learn and consistently works.

(At this point, I'm nearing the 10k character barrier for posts, so I'll have to make another post.)
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #4  
Old 01-27-2011, 12:52 PM
AtmaWeapon's Avatar
AtmaWeaponForm resizing AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

One Control Per Cell
You can only put one control in each cell of a TLP. This may seem like a limitation, but the layout would get more complicated if you could have two controls. Keep in mind a TLP cell can contain *another* TLP; I do this from time to time when I have a complicated layout.

Rows and Columns
Rows and columns share the same sizing modes. There are three sizing modes and some weird gotchas depending on how you combine them. First, let's review the sizing modes:
  • Absolute lets you create a fixed-size row or column. You specify a pixel size and the row/column will always be that size. This defeats the purpose of fluid layout, but can be useful for spacing out areas. I tend to use margins and padding instead, but do whatever you want.
  • Percent makes the cell take up a certain percentage of the size of the TLP. If you have two columns and both are set to 50%, they will be of equal width. The code won't let you specify a total percent greater than 100; if you do it tends to adjust the sizes for you as best as it can.
  • AutoSize picks the smallest possible size based on its content and the other cells in the dimension.
A cell's size is determined by the sizing behavior of its row and column, and the behavior need not be the same. For example, a cell's row might have an absolute height of 50 pixels and its column could have auto-sized width.

The interactions between sizing can get very complex, so it's best to stick to simple sizing behavior. I tend to either make all of my rows and columns AutoSize, all of them Percentage, or mix the two. Mixing is where you can get confused, but it's not that bad. I'm going to guess at interactions with absolute sizing.

Quote:
Originally Posted by Important Note
If there's no control in an AutoSize row or column, it picks a size of 0. Obviously you can't drop a control into a column you can't see. Because of this, I tend to work in a certain order. First, I drop the TLP. Then I add the appropriate number of rows and columns. Then I drop the appropriate control into each cell. Then I configure the size of each column. Then I configure each control's size. If you accidentally get in a state where you can't see a row/column, just reconfigure its size to percentage or absolute until you put a control in it, then change it back.
The basic rules for allocating space are simple. Let's ignore rows to keep it simple; rows follow the same kind of behavior. Absolute sized columns have highest priority and will always get what they ask for, even if it doesn't fit the size of the TLP. Also note that if the control in an absolute-sized column is too wide for the column, it will be clipped. Autosize columns have the next priority and will occupy the smallest amount of space as their control will let them; the column will never be less wide than its control. Percentage columns occupy a percentage of whatever is left, and will clip their control if it is too wide to fit. If the TLP is wider than the space that its columns ask for, the last column occupies all remaining space. Here's some examples:
  • Let's say I have 3 columns configured as "autosize, 50%, 60%". What I end up with is "autosize, 45%, 55%". Since I provided 110% to the percentages, the TLP picked new percentages that added up to 100 *and* had the same relative difference.
  • What about "autosize, 50%, 50%"? If the 50% were to mean "half the width of the entire table", there'd be no room for the autosize column. Instead, the percentages mean "50% of the space left over when all autosize and absolute columns have been accounted for".
  • "autosize, autosize, autosize". This one more or less translates to "autosize, autosize, whatever's left". When only autosize columns are specified, the last column will take up all of the space. This is identical to "autosize, autosize, 100%", and I usually specify it this way for clarity.
  • "50px, 100px, 50px". What you get depends on the width of the TLP. If it's less than 200px, you won't see all of the columns. At exactly 200px all columns are visible. If the TLP is wider than 200px, the last column takes up all available space.
  • "600px, autosize, autosize" (where 600px is wider than the TLP.) In this case, the absolute column wins and you don't see either of the autosize columns until the TLP is resized to accomodate all of the columns. Suppose the autosize columns are going to be 30px wide; you won't see all three columns until you reach 660px. At width greater than 660px, it will behave identically to "600px, autosize, 100%".

Docking and anchoring in a TLP
Controls that are in a TLP use the Anchor and Dock properties a little differently than the standard behavior. You almost always want to set at least one Anchor or a Dock of Fill; Dock's additional behaviors won't work in a TLP since there's one control per cell and Anchor tends to be more useful. You might find the pictures at this page useful.

Inside a TLP cell, think of Anchor as more like a strong magnet than glue; it behaves more like Dock does outside of a TLP cell. Here's some examples:
  • Left: this moves the control as close to the left edge of the cell as possible and will not let it move from the left edge.
  • Left and right: the control is resized so its edges touch the left and right edge of the cell. As the cell width changes, the control's width changes.
  • Left and right and top and bottom: The control is resized to completely fill the cell; its height and width change as the cell size changes.
  • No anchoring: this centers the control in the cell. It's more common to center either horizontally or vertically by doing top and bottom or left and right.

Dock behaves in the TLP the same way it does outside of it. The only real difference is now each Dock setting is the same as setting some anchor setting:
  • Docking to the top is the same as anchoring to top, left, and right.
  • Docking to the left is the same as anchoring to left, top, and bottom.
  • A Fill is the same as anchoring to top, left, right, and bottom.
I almost always use Dock.Fill for controls in a TLP cell. The only exception is when I need it stuck to one edge of a cell I know will be too large for the control; I'll provide an example later.

Margins and Padding in a TLP
The TLP respects its own Padding property. Suppose your TLP is at (0, 0) and has a Padding of 10 on all edges. The first cell will start at (10, 10), and all percentage-based sizes will acknowledge that 20 pixels have been removed from the width and height.

The TLP also respects the Margin property of controls it contains. If a cell is at (10, 10) and it contains a Button with a Padding of 10 on each edge, the Button will be placed at (20, 20) and its size may be adjusted depending on the sizing behavior of the cell, anchoring, or docking. Note that if a column isn't big enough to contain the control and its margin, it might be clipped. For example, suppose a 100px column is to display an 80px wide button with a Padding of 20px. Adding the padding to each side of the button makes it require 120px to display; 20px might be clipped. Which pixels are clipped depends on the anchoring/docking of the control.

AutoSize
The TLP has an AutoSize property. I don't recommend using it. You can read about how it works here. It more or less makes percentage columns work like autosize columns, but that's an oversiplification.

RowSpan and ColumnSpan
Sometimes you might want a control to cover multiple rows or columns. For example, you might have a text box at the top and several buttons beneath it, but you want the textbox to be as wide as the form and the buttons to auto-size in columns. When you add a control to the TLP, the TLP adds a RowSpan and ColumnSpan property to the control. If you set it to a number greater than 1, the control will be able to stretch into as many columns/rows as you specify. You will almost always use a left+right anchor, top+bottom anchor, or dock of fill with this, as it'd be silly to make the control span multiple columns but not fill them.

(Unfortunately I will have to split this into a third post for the example.)
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #5  
Old 01-27-2011, 12:53 PM
AtmaWeapon's Avatar
AtmaWeaponForm resizing AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

Example
Consider the humble MessageBox form. It displays some text in a label at the top. The label is horizontally centered, fills the width of the form, but leaves some space on either side. Beneath the label is an array of buttons, for this example we'll consider the "OK" and "Cancel" combination. The two buttons are horizontally centered beneath the text label. The bounds of these controls are vertically centered. Here's how you'd recreate that with a TLP:
  1. Create a new form.
  2. Drop a TLP on the form and set the TLP's Dock to Fill.
  3. Set the TLP's Padding property to 10 on all edges; this will make it look like all of the controls are horizontally and vertically centered.
  4. Configure the TLP to have 2 rows and 2 columns, for now set them all to percentage sizing.
  5. Drop a Label control into the top-left cell. Set the AutoSize property to False, the Anchor property to Left and Right, and the ColumnSpan to 2. Now the label will fill the top row. Resize the height if desired.
  6. Drop a Button control into the bottom-left cell. Set the Text property to OK and the Anchor property to Right.
  7. Drop a Button control into the bottom-right cell. Set the Text property to Cancel and the Anchor property to Left.
  8. Make both buttons the same width.
  9. Configure the rows and columns of the TLP to have their final sizing behavior:
    • Rows: 100%, autosize
    • Columns: 50%, 50%
The bottom row will be exactly as tall as the buttons. The top row will fill the rest of the form. The two columns are identical in size and fill half the form. The top label fills its space and spans both columns. The OK button is aligned to the right of the bottom-left column, and the Cancel button is aligned to the left of the bottom-right column; this makes them appear to be centered (if they are the same width.) The buttons may appear too close; you can fix this by setting the OK button's right margin and the Cancel button's left margin to the appropriate values.

One sad fact about the Label control: it doesn't really know how big its text will be and doesn't auto-size well. AutoSize doesn't word wrap, so it's no good. For the purposes of this example, make sure the label is tall enough to show the text you want to display. The real MessageBox class measures the string to determine how tall the label should be. There is a lesson here: TLP can't solve all layout problems, and occasionally you have to calculate the right size for a control.

There's usually more than one way to do things. Getting the buttons centered properly using this technique may seem a little weird. Here's another way to accomplish the same thing:
  1. Drop a TLP on a new form and set its Dock to Fill and give it a 10-20 pixel padding on all sides. I'll call this TLP "outer".
  2. Configure the TLP to have one column and two rows. Set everything to percentage.
  3. Drop a Label control in the top cell. Set its AutoSize property to True, Dock to Fill, and give it some text.
  4. Drop a TLP in the bottom cell; I'll call this one "inner". Set its Dock to Fill.
  5. Configure the inner TLP to have one row and four columns; set everything to percentage.
  6. Drop a button into the 2nd cell of the inner TLP. This is the OK button.
  7. Drop a button into the 3rd cell of the inner TLP. This is the Cancel button.
  8. Configure the sizing of the inner TLP. The row should be autosize, the columns should be "50%, autosize, autosize, 50%".
  9. Configure the sizing of the outer TLP. The rows should be "100%, autosize" and the column can be either autosize or 100%.
In this layout, ColumnSpan isn't required for the label because there's only one column. The buttons are horizontally centered by having two no-content columns of identical size on either size of the auto-sized button columns. If you think the buttons are too close together, you might use their Margin property to add some space or you might insert an absolute-sized column between them. Use whichever makes you more comfortable.

Is it possible to make the same dialog using no TLP? Sure. Just maybe not as intuitive. Here's the process:
  • Set the form's size to 450x150.
  • Drop a Label on the form. Set AutoSize to False, Size to (400, 50), Location to (15, 15), then press the "Center Horizontally" button in the toolbar (or set Location to (17, 15)).
  • Drop two buttons beneath the Label. Move them as close to the Label as you desire, and move them the distance apart you desire.
  • Select both buttons, then press the "Center Horizontally" button.
  • Make small adjustments to the size of the label, location of the buttons, and/or the size of the form so that there is the right amount of space between everything. You can eyeball it or use a calculator to figure out a nice layout.
  • Set the label's Anchor property to Top, Left, Right, and Bottom.
  • The left button is the OK button; set its Anchor property to Bottom.
  • The right button is the Cancel button; set its Anchor property to Bottom.
Now as you resize the form, it should behave like you'd expect. By the number of steps, it's just as easy as using a TLP. The difference here is I had to think about the size of the form and the controls to get the sizes I wanted; The only reason the Label has 25 pixels on each side is because its size is 50 less than the form's and I centered it. Likewise, you have to eyeball the distance between the Label and Buttons. The Anchor values were carefully selected so that the Label would grow with the form and the buttons would "stick" to the bottom. To me, it's harder to think about the layout this way, and if we tried a more complicated layout I might end up reverting to handling the SizeChanged event and using geometry to lay everything out.

WPF
Layout is much improved in WPF. While you can use WinForms style designer support, if you give up and use XAML it's easier to get fluid layout. I'm not going to go into WPF in detail, but it won't hurt to say that in WPF the Grid panel is similar to TLP, and there are some other layout panels that are better than what you get in WinForms. Automatic sizing is a natural part of WPF, so controls behave much more like what you'd expect.

Here's the XAML for a dialog box like the one we've been making, followed by a discussion of how it's put together and if it's any better.
Code:
<Window x:Class="WpfApplication1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="DialogBox" SizeToContent="WidthAndHeight">
    <Grid Margin="10">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto" />
            <RowDefinition Height="Auto"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*" />
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        
        <TextBlock MaxWidth="480" TextWrapping="Wrap" Grid.ColumnSpan="2" Margin="0 0 0 5">
            <TextBlock.Text>
                This is some really long text designed to take up a lot of space. It's going to wrap
                because of the MaxWidth property. 
            </TextBlock.Text>
        </TextBlock>
        
        <Button Grid.Row="1" Width="72" HorizontalAlignment="Right" VerticalAlignment="Top" Margin="0 0 2.5 0">
            OK
        </Button>
        <Button Grid.Row="1" Grid.Column="1" Width="72" HorizontalAlignment="Left" Margin="2.5 0 0 0">
            Cancel
        </Button>
    </Grid>
</Window>
The <Window> element is the form in WPF. Since I set "SizeToContent" to true, it will automatically size itself to fit its contents (respecting margins and padding.)

The <Grid> element is assigned a margin of 10 so it doesn't touch the edges of the Window. By default, WPF controls fill the entirety of their container. Since I didn't change the default, the grid acts like a WinForms control with Dock.Fill.

The <Grid.RowDefinitions> and <Grid.ColumnDefinitions> parts set up the rows and columns. There are two rows, both autosized. There are two columns, with "*" as the size. This is equivalent to saying they're both 50%; "star sizing" is WPF's percentage sizing. (If I wanted 25% and 75% I'd have used "*" and "3*".)

<TextBlock> is similar to a label. I give it a maximum width of 480; in WPF units that means 5 inches. I set its column span to 2 and tell it to wrap its content, then give it some text. The default grid row and column is 0, so it's in the top-left cell and covers the top-right.

<Button> is obvious. I had to manually set their widths so they'd be the same size; by default they auto-size to the text and it looks weird if they are different sizes. The HorizontalAlignment property is how I tell them to stick to an edge as if anchored; by default it is set to Stretch which is like Dock.Fill.

I set the margins in controls to put some space between them. You do this by specifying 4 numbers in the order "left, top, right, bottom". So the TextBlock has a margin of 5 on the bottom, and the buttons share a 2.5 unit margin between them.

One advantage this has over Windows Forms is the layout behavior is more intuitive. As the label fills with text, it wraps text and gets taller. I'm able to put maximum dimensions on controls to limit their growth; if I didn't constrain the TextBlock it would never wrap and continue to grow off the side of the screen. The sizing behavior extends from the controls to the window; the buttons and text boxes influence their rows, the rows influence the grid, and the grid influences the window. I can control how each control grows or constrain it to a particular size. It's quite powerful, but it also requires a good bit of knowledge of WPF's layout system, which is a different story entirely
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #6  
Old 01-30-2011, 04:24 AM
Poppa Mintin Poppa Mintin is offline
Newcomer
 
Join Date: Jan 2011
Posts: 4
Default

Wow!
Thank you AtmaWeapon, That must've taken a lot of time... Thank you so much.
I've been away for a couple of days hence the tardy reply...
I shall study this and I'm sure I'll be able to get to grips with it now.

Thank you again.
Reply With Quote
  #7  
Old 01-30-2011, 05:58 AM
Poppa Mintin Poppa Mintin is offline
Newcomer
 
Join Date: Jan 2011
Posts: 4
Default I'm stuck !

Oh dear, I hate to seem thick but...

Quote:
Originally Posted by AtmaWeapon View Post
  • Add menubar, dock to top.
  • Add toolbars, dock to top.
  • Add status bar, dock to bottom.
  • Add the right-hand tool windows, dock each to right.
  • Add the left-hand tool windows, dock to the left.
  • Add the code window, set dock to fill.
Ok, for 'bar' and 'windows' I'm assuming 'strip'. 'Add the right-hand, left-hand' I reckon you meant 'Add two'... (Not 'the') ?
But I can't fathom out 'Code window' ?

After all the time and effort of your answer I feel dreadful having to ask what is probably a simple question... sorry,

Poppa.
Reply With Quote
  #8  
Old 01-30-2011, 07:09 PM
AtmaWeapon's Avatar
AtmaWeaponForm resizing AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

It's a generalized series of steps, not exact instructions for creating a Visual Studio layout. "Menubar" and "toolbar" was meant to mean whatever controls you use for that; don't get hung up on the name. Depending on how your VS environment is set up, you might have tool windows on the left and/or the right sides. The only real important part about those steps is they have to come after the top-docked pieces since they never appear to the right or left of the menu/toolbars. "Code window" is the portion of Visual Studio where you type code. It tends to appear beneath the top-docked portions, to the right of the left-docked portions, to the left of the right-docked portions, and above any bottom-docked portions. Incidentally, this is what happens when the last control in a docking order is set to "Fill". WPF has a DockPanel element that simplifies this layout greatly.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
Form resizing
Form resizing
Form resizing Form resizing
Form resizing
Form resizing
Form resizing Form resizing Form resizing Form resizing Form resizing Form resizing Form resizing
Form resizing
Form resizing
 
Form resizing
Form resizing
 
-->