Writing and deploying applications in next-generation windows

This article is based on the version of Microsoft Windows codenamed "Longhorn" before PDC is held. All information contained here can be changed.

Download the code in this article: longhorn.exe (113kb)

Note: This article is completed before the release of the product is put into production. Therefore, we cannot guarantee that any details contained here are exactly the same as those found in the release product. The description of the product in this article is limited to the product published in this article, and is only used for planning purposes. The information in this article may be changed at any time without prior notice.

SummaryThe next version of Microsoft Windows, codenamed "Longhorn", not only marks a significant change in the operating system's way of working, but also represents a significant change in the way applications are built. Longhorn versions of Windows include a new storage system and natural search technology, with more emphasis on security mechanisms and trusted computing. The author provides an overview of Longhorn in this article. The focus of this Article is on building and deploying an application model N times at a time. In addition, he discussed the code "XAML", the new language used to create UI elements, and provided some operation examples.

Content on this page

	Longhorn Application Model
	Understand Longhorn applications
	XAML Language
	Example of building an application
	Conclusion

In many aspects, the next version of Microsoft Windows, codenamed "Longhorn", is an important milestone. "Longhorn" is the first operating system built with managed code. It adopts the latest storage subsystem (codenamed "winfs") for the first time "), this storage system is a revolution in the concept of a file system. It is also the first operating system that supports the natural search technology (natural UI). This technology automatically solves many inherent ambiguity issues in the query text. In addition, longhorn is the first operating system designed from the beginning with the security mechanism and trusted computing as the core. The preceding information and other features indicate that Longhorn will change the way applications are built-not every day. Since the advent of windows, I remember two equally important milestones-one was the migration of Windows from 16-bit to 32-bit, and the other was the birth of the managed environment of the Microsoft. NET Framework.

One of the most important changes in longhorn is that this operating system enables applications to be coded at a time and used in multiple deployment solutions. To achieve this great goal, Longhorn-based applications are fully object-oriented, and the entire application is built on a core object application, this object provides all the key services required to run the application. This article will guide readers to experience the Longhorn application model in a certain depth and apply it to several basic examples, including the classic Hello world application.

Longhorn Application Model

The application object is the core of the Longhorn application model. With this object's complete set of attributes, methods, and events, you can use the tag page set-an enhanced version of HTML-to write consistent and typical Windows applications. The application object is the root application object provided by longhorn. It provides basic application support, usually used for applications that require low overhead and do not use page navigation and status management. More complex Longhorn applications will use closely related navigationapplication objects inherited from applications, but added support for navigation.

A typical Longhorn application can be considered as a set of pages that write scripts using certain process code. The application object controls program execution and generates events to user code. Pages are written in a new declarative markup language, codenamed "XAML" (eXtensible Application Markup Language ). With XAML elements, you can control the layout of each page, including text and image display, insert button, text box, and other interactive components. In short, XAML is the language used to present the user interface that forms the page of the application in a declarative manner. Of course, in addition to using XAML, you can also use process code to write Longhorn applications. Generally, a successful application based on Longhorn has both the XAML page and the managed process code. You can combine them in your own way, but any combination of the two is acceptable.

By using the combination of XAML and C # (or Visual Basic. net) code, you can build various types of output files, including traditional Windows desktop executable files, DLL libraries or console applications. In addition, if your application is simple enough, you can also use an independent XAML flag to write it. In this way, another type of application is added to longhorn. As long as the independent XAML file does not reference the code hiding class, it can run in Longhorn shell and browser. Finally, it should be noted that Windows executable files can run in either a window or a browser. In both cases, the Code remains unchanged, as long as it is re-compiled with different project attributes.

For Longhorn, the desktop executable file is the next version of today's Windows Forms client application. However, on the other hand, XAML and browser-based applications also represent an innovative client programming model on the web. Currently, existing client applications are rarely deployed on the web. If you want to embed a Windows form into a browser page, the original features will be reduced and you must modify the code accordingly. In Longhorn, the general application model allows you to write a program and deploy it on the web. However, the final application is specific to Longhorn, which is very different from traditional Web applications (such as ASP. NET.

When you compile an application, the code is "Whidbey" for the next version of Visual Studio and. net Framework (or the underlying msbuild.exe tool) will generate. EXE file, a list of applications (the extension is. manifest) and a deployment list (the extension is. deploy ). If you click the. exe file, the application starts running as expected. If you set the application to run in a browser, click the. exe file to start an Internet Explorer instance and run the application. You can also deploy an application from a remote server. To complete the deployment, follow these steps. First, copy the deployment list file to the appropriate location on the server. It can be an FTP or HTTP path. Then, copy the compiled application file and list to the appropriate location on the server. The deployment list, application files, and list may not be the same on the server. If they are placed in different locations, You can manually edit the deployment list to point it to the location of the Application List. List Files are common XML files. When you direct the browser to a specified deployment location, Longhorn automatically downloads the application and its list, installs them on the client computer, and creates a point. deploy file shortcut. Finally, you can click the. Deploy file to run the application.

All longhorns share a common structure-a XAML page with Process Code (Inline or hidden using code)-the root object is derived from the application. The Application Object acts as the Controller; its lifecycle is consistent with that of the application. The application object allows you to process advanced events and sometimes share code and status between pages. It also allows users to navigate between pages based on the application logic. In a typical Longhorn program, the user executes the task first and then advances in the application by navigating from one page to the next page. Navigation is usually achieved by replacing the old page with a new page. However, you can also open a new pop-up window to display the new page. Navigation is not required by all Longhorn applications; simple applications that only contain one page do not need navigation.

As mentioned above, in addition to marking elements, the XAML page can also contain Process Code. Process Code is required. For example, it is used to process events generated by a XAML element on a page. The process code can be embedded into the body of the XAML file or in a separate code hidden file.

Programming in longhorn is based on managed code. However, only a few. Net-compatible languages can be used to write XAML-based applications. Currently, these languages include C #, Visual Basic. net, and JScript. net. When longhorn is released, other. Net-compatible languages will also be included. Currently, only these three languages can be used because the source code of the XAML file must be analyzed and compiled in real time. Therefore, the compiler and the relevant document object model must be ready in advance. However, it should be noted that if you fully use process code to write an application, you can use any language compatible with. Net, which has a valid compiler. Note that XAML-based applications can only use these three languages. If Process Code is embedded in the XAML page, you must compile the application before running it. If there is no process code in the XAML page, double-click it to display it, like HTML web pages. Longhorn does not process uncompiled code, nor can it compile code instantly. You can't wait to see what the Longhorn "Hello World" application looks like? The following is an example of the simplest XAML code you can write:

<Canvas     xmlns="http://schemas.microsoft.com/2003/xaml"     Background="LightCyan"     Width="100%" Height="100%">    <Image Source="lh.bmp" Canvas.Left="5" Canvas.Top="5" />  <Text Canvas.Left="90" Canvas.Top="20" FontSize="36">Hello, Longhorn!  </Text></Canvas>

Figure 1Simple XAML page

Save the code in a text file and use. XAML as the extension. Then, point to the file in the Longhorn browser or double-click the file in the shell. Figure 1 shows the result. <Canvas> A node defines the User Interface Area of the application-basically, equivalent to a canvas. The background attribute specifies the background color of the area, and the width and height specify the surface size. The <image> and <text> elements define the content of the page. These two elements use the left and top attributes of the parent canvas object to define their absolute positions.

Back to Top

Understand Longhorn applications

Longhorn provides a set of framework classes that expand and enhance. NET Framework 1.1. Longhorn extensions include: XAML support, storage systems, application models, trusted computing, and advanced Web Services. In Microsoft's roadmap program, Longhorn and Whidbey represent two very different milestones. Whidbey is expected to be released several months earlier than Longhorn. Therefore, when longhorn is released, it will include an upgraded version of Whidbey to provide core services in longhorn.

Let's take a look at the common basic-XAML language for all Longhorn applications. The XAML language is an XML-based language used to describe the user interface of an application. Programmers familiar with Win32 and. Net frameworks can see significant similarities between XAML markup and traditional Windows controls. However, compared with a full set of Win32 public controls or Windows Form Controls, The XAML tag is more abstract and wider in scope. To quickly understand the meaning of the XAML representation and how you should view the XAML, you can think about the ASP. NET page. Or, to be more specific, you can imagine an ASP. NET page with only the server-side control (runat = "server.

Each XAML tag corresponds to a. NET Framework class and contains many methods, attributes, and events. You can set attributes and write events in a declared manner in a XAML script, or use Process Code encapsulated into a code hiding class. The control hidden behind each tag is instantiated at runtime and an area on the screen is obtained to present its output on it. From the highest abstraction level, this model is very similar to ASP. NET, except that this model is abstracted and can be used on a general and richer Windows platform.

Each element in XAML uses a base class, but many classes do not have the corresponding XAML element. These classes are often abstract classes and are mostly used for inheritance. Everything created using XAML can be created using process code. For example, you can use the following code to create a button element in XAML:

<Canvas xmlns="http://schemas.microsoft.com/2003/xaml">   <Button Canvas.Left="10"            Canvas.Top="10"            Width="90px"            Height="32px">Click Me</Button></Canvas>

You can also use the following C # process code to create an identical button:

Button btn = new Button();btn.Width = new Length(90);btn.Height = new Length(32);Canvas.SetTop(btn, new Length(10));Canvas.SetLeft(btn, new Length(10));btn.Content = "Click Me";

In a XAML file, you cannot use methods, but you can set attributes ). Attribute in XAML usually corresponds to the property of the class, but several properties of the class do not have the corresponding XAML attribute. You can set class attributes one by one or use style sheets. A style sheet is a set of style attributes. The Compiler automatically applies it to controls that use the style sheet. All XAML pages have at least one panel element, which acts as a form container and controls the position of sub-content and global attributes such as the background color and font. The elements of a XAML page are organized in hierarchies and have only one root element. Generally, this root element is a class derived from panel, such as dockpanel or canvas, or a class derived from decorator, such as border. The canvas element is used to determine the content location based on the absolute coordinates. In general, each element is drawn at a different position. If more than two elements are drawn on the same coordinate, the order in which the elements appear in the tag determines the order in which they are drawn.

In addition to attributes and methods, the XAML element also supports many events. By creating an event handler, you can make the page dynamically respond to various notifications. The method for creating a longhorn event handler and associating it with elements is almost the same as what you are using in. Net-based applications today. The event handler Declares through an attribute, and then integrates the handler into the application through the Code hiding class:

<Button Width="90px" Height="25px" Click="OnHandleClick">Click Me</Button>

The elements in the page form the application tree, which is an object model that includes all runtime components of the application and can be accessed through code. Each control provides its own sub-level access method. Main modes include panel. Children. Add (element), ListBox. Items. Add (object), button. content = object, and textbox. textrange. Text = string.

Child-level controls support arbitrary sub-level objects-strings, elements, or a completely random object (in this case, tostring can be called ). Each control has a parent attribute to access its parent level in the tree. Note: Each attribute accessing the tree only returns a direct sub-level, not a child. With the object model, you can freely manipulate every aspect of the elements on the page. It also provides additional features that cannot be implemented through XAML. For example, you can dynamically create elements, but you can also instantly create elements based on runtime conditions.

To illustrate this point more clearly, let's look at the second application example. As mentioned above, any standardized Longhorn application includes Process Code and XAML scripts. We will discuss a situation that is more complex than the original Hello world application and handle some events.

Figure 2Displays all the source code of a new application, where XAML is bound to some Process Code stored in the Code hiding class. If you compare the XAML solution with an ASP. NET web form page, you can hardly find any obvious difference except for the syntax. Def: codebehind and Def: class attributes encapsulate C # code in a similar way as Visual Studio code hiding class encapsulates ASP. NET code. Let's name it.Figure 2The XAML file in events. XAML and its name also appears inFigure 2The Code hiding class in events. XAML. CS. If you direct the browser to the file, a runtime error occurs, as shown in figureFigure 3. This error message is not clear in my internal version, but the cause of the error is obvious. This error must be related to the failure to dynamically compile the XAML code. Unlike ASP. NET, Longhorn requires you to explicitly compile any embedded or simply referenced Process Code by a XAML script. This feature may change significantly in future internal versions, but at present it forces you to manage Longhorn project files in Visual Studio. Alternatively, you can familiarize yourself with msbuild. Its executable file is msbuild.exe. The Longhorn solution and project file extensions and structures are consistent with those in Visual Studio 2003. Longhorn project files are roughly as follows:Figure 4The Code listed in.

Figure 3XAML Error

The project file contains important information about the project. <Project> the flag specifies the type of packages that must be generated by the compiler. The project attributes and items are in the nested tag-<projectgroup> and <itemgroup>. The name of each element is easy to understand. The project file is passed to the msbuild.exe utility in the command line. Msbuild resides in the framework folder under Windows/Microsoft. NET. The following simple command generates an executable file based on the events. proj project file:

msbuild.exe Events.proj

Unless you want to practice the msbuild tool, you do not have to pay too much attention to it. As mentioned above, Visual Studio of Whidbey is highly integrated with Longhorn SDK. You only need to click the toolbar button or press F5 to build the Longhorn application.Figure 5ShownFigure 2The Running Effect of the Code in. In the application tree, only one blue panel with text on it is visible. The application tree is actually betterFigure 5Is a little more complex. The root node is a window containing the dockpanel object. Dockpanel is the outermost container of all user interface elements. It contains a child-level-flowpanel, and flowpanel contains a text object. Text is represented by an instance of the text class. You should have noticed that the XAML tag has several attributes used to control its display. More importantly, these tags support the ID attribute, which provides the runtime identifier. The mouseleftbuttondown event associated with the flowpanel class is triggered as long as you click the mouse in the area allocated to the control. The onleftmousedown event handler code is called. The width and height of the flow panel are doubled, and the text is also changed. Click the mouse again, and the Panel is restored to the original size.

Figure 5Run the application

Although you can also use process code to write an application, The XAML file simplifies the description and templatification of the application user interface.

Back to Top

XAML Language

The XAML language consists of four main types of elements: panel, interactive controls, document-related elements, and graphics. Although the border (Border) element does not belong to any of the above four categories, it is also important. Technically speaking, it is equivalent to the "decoration worker" responsible for the detailed layout, which only contains one child level, but adds the rendering effect. In XAML, a panel is responsible for page layout and serves as a container for other elements. A panel is a component that manages the painting, size, position, and content of the contained elements. Longhorn has six built-in panel classes, but developers can create their own panels by using custom painting behavior. Predefined panels include canvas, dockpanel, flowpanel, gridpanel, table, and textpanel.Figure 6These panel types are described in.

The canvas panel is the only pre-defined panel that supports explicit positioning. All its child elements are drawn from a fixed position, extending the specified size. If the two elements overlap, the area drawn later will overwrite the following area. Note that the coordinates are relative to the canvas, which means (0, 0) indicates the pixels in the upper left corner of the area. The following is an example of a canvas object:

 <Canvas xmlns="http://schemas.microsoft.com/2003/xaml"    Height="600" Width="800">    <Border Background="red"        Canvas.Top="0px" Canvas.Left="0px"        Height="100px" Width="100px" />     <Border Background="green "        Canvas.Top="100px" Canvas.Left="100px"        Height="100px" Width="100px" />     <Border Background="blue"        Canvas.Top="50px" Canvas.Left="50px"        Height="100px" Width="100px" />  </Canvas>

The dockpanel component develops the same concept of inclusiveness in different ways. All child levels of the Panel are docked horizontally or vertically. In this case, positioning is relative to the previous control, and coordinates are not required at all. Dockpanel is an ideal choice for creating a button bar like a toolbar. The following is an example:

<Border xmlns="http://schemas.microsoft.com/2003/xaml"     Background="black" >    <DockPanel>        <Button DockPanel.Dock="Left" Width="50px" Height="32px">Open        </Button>        <Button DockPanel.Dock="Left" Width="50px" Height="32px">            Save        </Button>        <Button DockPanel.Dock="Left" Width="50px" Height="32px">Print        </Button>        </DockPanel></Border>

The first button is located at the far left of the Panel, and each other button is arranged horizontally next to the previous button (seeFigure 7).

Figure 7Button Layout

The flowpanel element allows child components to flow in various directions in available areas. The Panel also contains logic that can process content beyond the panel width. In this case, according to the object configuration, the content of the excess part can be folded and displayed in the next line or truncated. The following XAML example illustrates how flowpanel interrupts the content and returns a line-by-line display (this type of content is logically designed to fit a single row ). In this example, the four square elements are contained in a larger element. The sum of the width of the four squares is greater than the width of the container. Because all small squares cannot be displayed in one row, these four squares are truncated and the last one is displayed in the second row. Note: The default direction of the panel is from left to right, from top to bottom:

<FlowPanel xmlns="http://schemas.microsoft.com/2003/xaml"                 Width="250px" Height="250px">        <Border Background="red" Width="75px" Height="75px" />     <Border Background="green" Width="75px" Height="75px" />     <Border Background="blue" Width="75px" Height="75px" />     <Border Background="orange" Width="75px" Height="75px" /> </FlowPanel>

Gridpanel is an element with little overhead. It uses a grid-like method to arrange the layout of objects to build a relatively simple table. Through gridpanel, you can place controls on rows and columns to form a matrix, but in general, its functions are still very limited. To build more complex tables with advanced functions, you can use the table panel. The table panel structure consists of multiple groups of rows. You can define a group of rows for the header or footer, or insert multiple groups of rows with different settings. With the layout function of this panel, you can create complex table representations for data.

Finally, textpanel is an ideal choice for complex text la S. However, for basic text support, the text element is a better choice, because it has lower overhead (of course, fewer functions ).

The msaveon. Windows. Controls namespace centralizes all user controls for user interaction. The classes that belong to this namespace are familiar to you: button, ComboBox, ListBox, and checkbox, but there are also some new members, such as contextmenu, pageviewer, and radiobuttonlist. The basic class of user interaction elements is control, which provides a set of common attributes and methods.

Figure 8Page Viewer

In particular, the pageviewer control provides a user interface for viewing online documents and Provides paging and page navigation functions. The following example generates a page Viewer (for exampleFigure 8), It occupies the entire workspace. The page viewer page displays the text in the file specified in the source attribute marked by pageviewer:

<DockPanel ID="root" xmlns="http://  schemas.microsoft.com/2003/xaml"  xmlns:def="Definition">  <Text DockPanel.Dock="Top">See a   PageViewer control in action below.  </Text>  <PageViewer DockPanel.Dock="Top"     Source="Sample.xaml" Height="80%" Width="80%"/>  <Button DockPanel.Dock="Top" Width="50%">OK</Button></DockPanel>

Interestingly, the source file viewed through the pageviewer control cannot be pure text, RTF, or HTML. At least for the moment, it must be a XAML file containing non-formatted ASCII text and encapsulated by the pagination-supported aveon control. Avron is the new subsystem code in Longhorn (see Charles Petzold's article in this article ). For example, let's look at the textpanel class:

<TextPanel ID="root" xmlns="http://schemas.microsoft.com/2003/xaml">text to show goes here</TextPanel>

Save the code snippet above to sample. XAML to run the previous example. Remember, the xmlns namespace is required.

The class in the msaveon. Windows. Documents namespace is responsible for displaying the document. These classes are combined to look like supersets of advanced HTML tags. The classes include: Block, column, heading, footer, columngroup, rowgroup, hyperlink, and list.

The text class you saw earlier belongs to the pre-release Longhorn system. Windows. Controls namespace. The text class supports multi-line and various text format settings, including bold and italic, font size, and nested child elements. When the required text is relatively simple, text is an ideal class because it has a low overhead and comprehensive functions. Longhorn indicates that the model uses the XAML panel element to draw the image. The Panel provides many attributes for size and alignment, and controls the border, background color, and fill.

Longhorn uses Windows vector graphics (Windows vector graphics) to draw graphical content. It has many advantages over GDI and GDI +. Windows vector graphics is a graphic markup system based on XML, which is easy to use and reuse. If you are a fan of Scalable Vector Graphics, you will be obsessed with Windows vector graphics. Windows vector graphics provide predefined shapes, including ellipse, line, path, polygon, polyline, and rectangle, which are inherited from the shape class. These elements inherit many common attributes from the shape, including stroke, strokethickness, and fill, plus attributes used to specify coordinates and vertices. By performing deformation, the shape can be skewed, rotated, translated, and scaled. In addition to specifying the solid fill color and background for the shape, you can also specify the progressive color. The following example sets the horizontal progressive color to the fill attribute of a rectangle (rectangle) shape, sets red (red) to the starting color, and blue (blue) set to the final transition color:

<Rectangle xmlns="http://schemas.microsoft.com/2003/xaml"    Canvas.Top="10" Canvas.Left="10"    Fill="HorizontalGradient Red Blue"    RectangleLeft="0" RectangleTop="0"    Width="50" Height="50"/>

Back to Top

Example of building an application

You can quickly and effectively build a user interface prototype using the XAML language. I am sure that when longhorn is released, many development tools will be updated (or re-built) to fully support the XAML with WYSIWYG features. Longhorn's technical preview version already includes some extensions to Visual Studio. NET in Whidbey version. Next we will look at a more standardized interactive application. You will soon find that this is not much different from writing Windows Forms applications, and you will be pleasantly surprised to find that you have mastered it. net skills can be well applied to longhorn. For exampleFigure 9As shown in, you can see a very small application sample user interface, which contains a text box and a context menu. The text box is defined in XAML; the context menu is dynamically created. All source code of the application is displayed inFigure 10.

Figure 9Context Menu

In Longhorn, all applications are represented by an instance of the application class. This object is the core of the Longhorn application model. However, the application object only supports basic applications. Generally, only applications that require low overhead and do not use the navigation function use this object. In fact, most Longhorn applications use a closely related navigationapplication object that inherits from the application and adds navigation support.

Navigationapplication objects support various methods, attributes, and events, allowing you to combine a large number of XAML pages into an application. In a sense, the Longhorn application based on the simpler application class can be compared with the dialog box-based Win32 application. Similarly, you can compare the applications that support navigation with the complete Win32 applications. In such Win32 applications, various windows and forms form a combination of the overall functions of the application. The following code shows an example of this navigation function:

myApp = NavigationApplication.Current;win = (Navigation.NavigationWindow) myApp.Windows[0];•••private void Button_Back(Object sender, ClickEventArgs e){    // If possible, go to the previous window    if(win.CanGoBack())       win.GoBack();}

You can use the static property current on the application (or navigationapplication) navigation object to get reference to the Application object. The preceding example shows how to obtain a reference to the first window in the stack. The button_back event handler checks whether the previous window object exists. If yes, it jumps back to it in a browser-like way.

The next example shows how to customize the behavior when the application is started by deriving a new class and overwriting the onstartingup method. The following code snippet overwrites onstartingup. A navigation window is created and displayed when the application is started:

public class MyApp : NavigationApplication{    NavigationWindow win;    •••    protected override void OnStartingUp(StartingUpCancelEventArgs e)    {        win = new NavigationWindow();        // Add elements to the window        •••          navWin.Show();    }    •••}

Let's go backFigure 9Application Example. Based on the reasons I have just discussed, you can use application or navigationapplication as the base class because the application will use a single window, dialog box-based application. The running class named sample1 overwrites onstartingup and defines several event handlers. Override the onstartingup method is required because it represents the initialization step for application startup, so it is an ideal place to perform your own operations before the window opens.

The operation completed in onstartingup is the creation of the window. The content of the window is described in the XAML file and its hidden code class. A XAML page consists of controls and other components, which are organized in a layered tree. The relationship between these different components (called elements) largely illustrates how pages are presented and presented.Figure 9The sample page in contains a Textbox Control with a given size and font. This text box is bound to the contextmenuevent event. The event is triggered immediately after you right-click the workspace of the control.

The event processor will create a contextmenu object (seeFigure 10). After the context menu is filled and configured graphically, it is bound to its parent object-textbox. There is no doubt that in Longhorn, you can easily customize the appearance of menus (and the appearance of all controls) by selecting the background color and foreground color, border and font ). If you think that earlier windows and. Net frameworks may have completed the same task, you will be wrong. In Win32, this kind of customization requires a lot of programming work, which is not simple at all. In the. NET Framework, the packaging class encapsulates the necessary code, leaving few properties for user control. On the other hand, in Longhorn, the control's user interface is as simple as it looks.

The context menu elements are created from the menuitem class. They trigger event handlers in almost the same way as framework-based applications:

mia = new MenuItem[3];for (int i=0; i<3; i++){    mia[i] = new MenuItem();    cm.Items.Add(mia[i]);    mia[i].Foreground = Brushes.Black;}mia[0].Header = "Lower Text";mia[1].Header = "Upper case";mia[2].Header = "Select all";mia[0].Click += new ClickEventHandler(LowerCase); mia[1].Click += new ClickEventHandler(UpperCase); mia[2].Click += new ClickEventHandler(SelectAll);

When a menu item is clicked, immediately execute the event handler and use the first parameter passed to retrieve references to its source object:

public void LowerCase(Object sender, ClickEventArgs args){    MenuItem mi = (MenuItem) args.Source;     ContextMenu menu = (ContextMenu) mi.Parent;    TextBox thisTextBox = (TextBox) menu.PlacementTarget;    thisTextBox.Text = thisTextBox.Text.ToLower();} 

To retrieve Textbox, you must trace up in the tree. First, it reaches menuitem, and then contextmenu. Finally, you can access its owner textbox. In this case, it is easy to modify the textbox content.

Back to Top

Conclusion

Longhorn represents an important milestone in the history of windows. It will become the first Windows Version dedicated to hosting code. The new application model further establishes the importance of longhorn.. NET Framework applications (especially ASP. with rich experience in application modeling, its design and implementation reach the vertices.

The Longhorn application is built around the application object, allowing you to combine a large number of tag pages in an application as a whole. You can also regard the XAML language behind the Longhorn application as the Abstraction Level sign used to design the Longhorn application model. The final goal of longhorn is to allow you to code once and deploy it in various solutions, whether based on web or client.

It is not easy to introduce an application model for a new platform that few people have used. This task becomes more difficult if we consider that there may be significant changes in some aspects in the future. From this perspective, you can take this article as a snapshot to understand the current situation and future development direction of longhorn.

I have provided sample projects that can be downloaded as code to help you practice longhorn. You can click the link at the beginning of this article to obtain this project.

Dino Esposito works in Rome, Italy and serves as an instructor and consultant. As the author of Microsoft press's programming ASP. NET, he spent most of his time teaching courses on ADO. NET and ASP. NET and giving speeches at various meetings. If you want to contact Dino, send an email to your cutting@microsoft.com.

Go to the original English page