The Tool Palette

When the ASP.NET Web Form designer is displayed, the Tool Palette (shown in the lower right of Figure 11.2) shows available controls, categorized in groups. One of the first things a developer may want to do is customize the Tool Palette to make it easier to perform the task at hand. For instance, the order of categories in the Tool Palette may not be just right. To fix this, select the Categories drop-down and notice how each category is highlighted as the mouse passes over it. You can rearrange the categories by holding down the mouse button and dragging the category to another position in the list. As the category is dragged, a horizontal line will show where its new location would be if the mouse button were released. My preferred arrangement is to have the Web Controls category at the top because those are used more frequently and then the HTML Elements category would be next. Because I like using the Borland Data Provider (BDP.NET), I would put it before the Data Components category. The categories I rarely use would be positioned toward the bottom. Positioning categories toward the top of the Tool Palette for the components and controls used most can help productivity.

The Object Inspector

The Object Inspector (shown on the left side of Figure 11.2) changes dynamically to show the properties of the current component, control, or object with focus in the designer surface. If a component or control is selected, the Object Inspector will add another tab for Events. When selected components and controls have editors associated with them, hyperlinks to those editors may also appear at the bottom of the Object Inspector, called the Designer Verb area. For example, if a DataGrid control were dropped onto the visual designer surface, the AutoFormat and Property Builder editors would appear as Designer Verbs.

The Designer Surface

The designer surface (shown in the center of Figure 11.2) is where Web forms are constructed using visual drag-and-drop tools. Components and controls are dragged from the Tool Palette and dropped onto the designer surface, and their properties are modified in the Object Inspector. The toolbar above the designer surface lets the developer perform object and text alignments, customize fonts, and perform other miscellaneous page formatting and viewing functions. Below the designer surface is a tag editor, which is a shortcut portal to quickly get to the raw code of the selected object. Later in this chapter, the section titled "Creating an ASP.NET Web Application" demonstrates the relationship between the tag editor and designer surface and shows how they are synchronized.

At the bottom of the designer surface are three tabs; the one named Design is for the designer surface itself. Clicking the WebForm1.aspx tab opens a code editor for the raw ASP.NET tags that form the visual appearance of the Web Form. The other tab, WebForm1.aspx.cs, shows the C# code editor containing the code-behind file. If one of the tabs doesn't appear, the designer surface area of the screen may be too small to accommodate them all, and arrow buttons to the right of the tabs will appear. In that case, use the left and right arrows, to the right of the tabs, to move a tab into view. If you would like to see these arrows, which are not visible when the tabs fit in their allocated space, rename the Web page to something long, such as ThisIsMyLongWebFormFileName.aspx, that will force the tabs to exceed their space.

Project Options

There is a special page for ASP.NET applications in the Project Options dialog, which you can open by selecting Project, Options or pressing the key sequence Ctrl+Shift+F11. Under the Debugger folder is a branch for ASP.NET (see Figure 11.3).

Figure 11.3. ASP.NET project options.

graphics/11fig03.gif

Like other project options, ASP.NET options can be saved to a custom option setting configuration. The two available configurations are Debug, the default, and Release. Clicking the Save As button allows you to create a new configuration. The two other sections, Launch Browser and Host with Web Server, permit specification of options from the perspective of launching the Web application from the IDE and Web server configuration.

In the Launch Browser section, the Start Page field specifies the Web page in the Project Manager that will be started when this program is launched from the IDE. This name will change when the name of the identified file in the Project Manager changes also. To see how it works, close the Project Options dialog and change the name of the file in the Project Manager that appeared in the Start Page field. Then reopen the Project Options dialog (Ctrl+Shift+F11) and observe that the name was changed. However, the converse is not true. If the name in the Start Page field is altered, the filename in the Project Manager does not change, which is something to remember to avoid problems when trying to launch Web applications from the IDE. Although modifications in the Start Page field do not change the Project Manager filename, they do alter the filename in the HTTP Address field, which is the URL specifying where the browser should find the Web page for the current application when launched from the IDE.

The Host with Web Server section contains a Server field, which identifies the Web server to use for hosting this application, and a Virtual Directory field that identifies the virtual directory the Web server will use for this application. The Server field options shipped with C#Builder are Internet Information Server (IIS) and Cassini. The only option for the Cassini Web server is the Virtual Directory field. However, a Server Options button is available when Information Server (IIS) is selected in the Server field, which, when clicked, displays the Configure Virtual Directory dialog (see Figure 11.4).

Figure 11.4. The Configure Virtual Directory dialog.

graphics/11fig04.gif

The Configure Virtual Directory dialog has all the options that would be available if creating a virtual directory with the wizard in IIS. The Location field identifies the physical directory where Web application files reside. The Alias field is the same as the Virtual Directory field on the Project Options dialog. If the Alias field is changed, the name of the Virtual Directory field is also changed. If a virtual directory already exists with the same name as the contents of the Alias field, the check boxes on the Configure Virtual Directory dialog are grayed out and may not be changed and the text "Directory exists" appears in bold red letters to the right of the Alias field. Modifying the Alias field makes these check boxes active. See the IIS documentation and the previous section in this chapter that discusses the ASP.NET wizards for more information about these options. If the Alias was modified, a new virtual directory will not be created until the OK button of the Project Options dialog is clicked. You can verify this by opening the IIS console and seeing that the new virtual directory with the same name as the Alias field has been created.

Creating an ASP.NET Web Application

When a new ASP.NET application is started, the designer surface is set to GridLayout, which places all controls in absolute positions on the Web Form. Most of the time, this isn't the best layout because there is no telling what browser and screen resolution a user will have when viewing the deployed Web page. The other option for Web Form layout is called FlowLayout, which behaves like normal HTML when laying out the Web page, without absolute positioning of form elements. To change this, make sure the Web Form is open on the designer surface and selected and find the PageLayout attribute of the Document object in the Object Inspector. If the Document object is not selected, go to the drop-down list, which contains a list of all designer surface objects, at the top of the Object Inspector, and select the Document. Because getting controls located where they need to be can take some time, a developer may want to make the layout decision before adding controls.

As mentioned earlier, this first application will be very simple to keep the focus on using C#Builder tools to properly get a Web Application built and running. If the layout has been set to FlowLayout, the caret will go to the top left corner when selecting the designer surface. The only content on this page will be the text "Welcome to C#Builder Kick Start." If you're following along, type this text but don't put punctuation at the end of the sentence yet. As you type this, observe how the text appears in the tag editor at the same time. To show the two-way editing and synchronization between designer surface and tag editor, click in the tag editor with the mouse cursor and place the caret at the end of the text. Next, type an exclamation point, "!", and observe that when the text in the tag editor changes, so does the text on the designer surface.

As another interesting exercise, select Document from the drop-down list at the top of the Object Inspector. This will change the tag editor to display the form element (see Figure 11.5), which contains the string entered earlier. Because C#Builder provides so many ways to work with the code, developers can choose to work in whatever way they feel comfortable and productive.

Figure 11.5. The form element in the tag editor.

graphics/11fig05.gif

The tag editor only shows the HTML code currently selected in the designer surface and Object Inspector. To see all of the HTML code, select the WebForm1.aspx tab below the tag editor (see Listing 11.1).

Listing 11.1 An ASP.NET Web Form (WebForm1.aspx)
 <%@ Page language="c#" Debug="true" Codebehind="SimpleWebPage.aspx.cs" AutoEventWireup="false" Inherits="SimpleWebPage.WebForm1" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html>    <head>       <title></title>       <meta name="GENERATOR" content="Borland ASP.NET        Designer for c# Package Library 7.1">    </head>    <body ms_positioning="FlowLayout">       <form runat="server">Welcome to C#Builder Kick Start!       </form>    </body> </html> 

As you can see, the code in Listing 11.1 looks like a typical HTML Web page, but there are a couple of exceptions. The form element contains an attribute named runat, which is set to server. This means that code associated with the form element will execute on the server and be rendered to the client as HTML. Server controls, discussed later in this chapter, contain the runat="server" attribute for the same reason. In many cases, the HTML rendered by a control is much more complicated than what is entered into the HTML editor by the developer.

The other non-HTML part of Listing 11.1 is the Page directive, which looks like "<%@ Page ...%>". Directives are typically located at the top of the listing by convention. This directive has several functions, represented by attributes that communicate information about the Web Form to ASP.NET when the page is compiled. A later section, titled "The ASP.NET Architecture," will explain what happens when ASP.NET compiles a page and how it is processed. Table 11.2 outlines available attributes of the Page directive, including the ones shown in Listing 11.1.

Table 11.2. Page Directive Attributes

NAME

PURPOSE

AspCompat

Lets the page call Single Threaded Apartment (STA) COM components.

AutoEventWireup

If true, will automatically set Page events, such as Page_Load, to be called. Otherwise, the page will need to explicitly assign a delegate to the event.

Buffer

Turns on response buffering if true.

ClassName

Name of automatically compiled page.

ClientTarget

Type of browser this page targets.

CodeBehind

Used by C#Builder to find the code-behind file associated with this page.

CodePage

Code page to use for the response.

CompilerOptions

Same as options that would be given to a compiler on the command line.

ContentType

MIME content type.

Culture

Specifies page culture setting.

Debug

Enables debugging when set to true by generating debugging symbols.

Description

Text for describing the page.

EnableSessionState

Defaults to true to allow using session state on page. See Chapter 12 for more information about session state.

EnableViewState

Turns on view state if true.

EnableViewStateMac

Helps with securing view state if true.

ErrorPage

Page to redirect to when unhandled exceptions occur.

Explicit

Option Explicit for Visual Basic .NET code.

Inherits

Used by ASP.NET to find the code-behind page that this page inherits.

Language

Identifies .NET language to use. Defaults to Visual Basic .NET. C#Builder will set to C#.

LCID

Locale identifier for page.

ResponseEncoding

Encoding to use in page response.

Src

The source filename of the code-behind file. Used in situations where the code-behind should be dynamically compiled when requested by the user.

SmartNavigation

Internet Explorer 5.5 and later have a feature that allows a page to return to its last scroll position when reloaded. This attribute enables that feature.

Strict

Sets Option Strict or Visual Basic .NET.

Trace

Enables runtime trace messages when set to true.

TraceMode

Controls sorting of Trace messages; may be SortByTime or SortByCategory.

Transaction

Specifies transaction handling information for page.

UICulture

Sets UI culture for this page.

ValidateRequest

Validates page for potential security threats, such as cross-site scripting attacks, if set to true.

WarningLevel

Sets warning level to abort page compilation.

The code-behind page is located on the tab at the bottom of the designer surface named WebForm1.aspx.cs, which is also the name of the file. A code-behind file is important because it forms the separation between the user interface presentation layer and the business logic layer in an n-tiered Web application. This is a significant improvement over ASP.NET's predecessor, ASP, because in ASP all code and user interface were combined into the same file. Such a combination of code and interface in one file is still possible with ASP.NET for migration purposes, but by default the ASP.NET Application wizard sets up the application with a code-behind file. Because having the code and the interface in the same Web page goes against proper n-tiered application development, this book doesn't discuss it further. Listing 11.2 shows a default code-behind created by the ASP.NET Application wizard.

Listing 11.2 An ASP.NET Code-Behind Page (WebForm1.aspx.cs)
 using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Drawing; using System.Web; using System.Web.SessionState; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.HtmlControls; namespace SimpleWebPage {    /// <summary>    /// Summary description for WebForm1.    /// </summary>    public class WebForm1 : System.Web.UI.Page    {       private void Page_Load(object sender, System.EventArgs e)       {          // Put user code to initialize the page here       }       #region Web Form Designer generated code       override protected void OnInit(EventArgs e)       {          //          // CODEGEN: This call is required by the ASP.NET Web Form Designer.          //          InitializeComponent();          base.OnInit(e);       }       /// <summary>       /// Required method for Designer support - do not modify       /// the contents of this method with the code editor.       /// </summary>       private void InitializeComponent()       {          this.Load += new System.EventHandler(this.Page_Load);       }       #endregion    } } 

Because the AutoEventWireup attribute was set to false in the Page directive for Listing 11.1, the InitializeComponent explicitly sets the Page_Load method as the handler for the Load event. Each time a Web page loads, the Page_Load method will be called. The code-behind page doesn't have a constructor; rather, it overrides the OnInit method of the Page class, which then calls the InitializeComponent method to initialize the class.

If the Project Options have been set, as discussed earlier, and a virtual directory has been created, this application can be executed by selecting Run, Run Without Debugging. The application will launch in the browser and display the text that was entered earlier. This section has introduced some basic concepts and provided information on how to get started. The next section describes how these pieces fit together and how it works.



C# Builder KickStart
C# Builder KickStart
ISBN: 672325896
EAN: N/A
Year: 2003
Pages: 165

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net