开云体育

-= Dave

David F. Lorentzen
Manager, HLA/Molecular Diagnostics Lab
University of Wisconsin Hospital and Clinics
600 Highland Ave
Madison, WI? 53792-2472

开云体育

开云体育

开云体育

开云体育

开云体育

开云体育

-----Original Message-----
From: code@... [mailto:code@...]
Sent: Tuesday, March 16, 2004 6:32 PM
To: pjfern@...
Subject: CoDe Magazine eColumn: Publisher's Point

Other Online Content: ...and much, much more. Visit us at: !

CoDe Magazine E-Mail Column and Newsletter Publisher's Point: Using Your Inheritance Markus Egger Publisher, CoDe Magazine Visual Studio .NET introduced a great feature that was not new to many developers, but was new to Visual Basic developers. It was a feature that greatly increased the options for everyone who previously based their efforts on the COM platform. Am I talking about Web services? Xcopy deployment? The Common Language Runtime (CLR)? Those are good guesses, but what I am talking about is inheritance. To me, this is one of the biggest benefits introduced by the first version of Visual Studio.NET. In fact, to me, the lack of inheritance support was the main reason I avoided VB programming in the pre-.NET world. It was unbelievable to me that a mechanism so fundamental to object-oriented development was not available. The tides have turned though, and now we have inheritance support and more: cross-language inheritance that represents the foundation of everything in the .NET Framework. I am happy to see developers using this great feature in many ways and for many different purposes. It seems that increasing numbers of developers understand not just the theory of inheritance, but also know how to use this powerful feature in real-life situations. Yet there is one area where inheritance is often overlooked: inheritance in Windows Forms. Why is that? Frankly, the thought of re-creating forms that behave like I want them to, re-creating buttons that look like I want them to, and re-creating textboxes that format their input the way I want them to, gives me the heebie-jeebies! To be honest, technically, inheritance is used a lot in Windows Forms, as every new form that gets created is a sub-class of a Form class. But that's not what I am talking about. Consider a simple scenario. Assume that you need to build a Windows Forms application with a variety of different forms. You might right-click your solution and choose "Add Windows Form..." from the menu. This appears to create a brand new form from scratch, but it really doesn't. Instead, the Designer creates a new class that inherits from System.Windows.Forms.Form, and which looks and behaves very much as you would expect a Windows form to behave. The class makes calls to the Windows API to produce something that looks like a window and a form. The class provides easy access to many of a form's features, such as the ability to set the window's title or to specify whether you even want a title bar. The System.Windows.Forms.Form class goes beyond a bare-bones abstraction of a simple window, and provides features such as integrated localization or the ability to set the "Accept" button. Everything provided by the basic System.Windows.Forms.Form class is great stuff, and by adding a "new" class to the project that inherits from System.Windows.Forms.Form, you tell the compiler that you want to create a class that is exactly the same. You end up with something that looks and behaves like a form and you can safely proceed to adding additional objects (buttons, textboxes, etc.) and additional functionality to the form. To state it a bit differently: you started out with a generic form that was just like any other form, and only added and changed the things that were exceptional. This is why inheritance sometimes is also referred to as "programming by exception." So far, so good. But the million-dollar-question is: what are the chances that the basic System.Windows.Forms.Form class fits your needs 100%? Pretty close to 0? How often do you go into your new form and change the same exact property that you have been changing in all the other forms you have ever created, like maybe the icon? All the time? I thought so. So why, I ask, would you keep doing this? My guess is that performing these types of repetitive tasks is not the highlight of your developing day. The solution is simple: use inheritance the same way you use it in other development areas, and use it the same way the Microsoft Windows Forms team used it when they built that part of the .NET Framework. So how do you use inheritance like that? First you create a Forms class the same way you would when building any new form, because that new form really is a subclass of the default System.Windows.Forms.Form class. Then, change whatever you want to change. Maybe you want to change the default icon. Maybe you want to add some functionality that manages the form's default screen position a bit differently. Maybe you want to render the form's background in a slightly different way. Or maybe, you are happy with the way the form works for the time being, but want to give yourself a nice place to add and change behavior and appearance later. Then, whenever you create a new form class, instead of picking "Add Windows Form..." from the right-click menu, pick "Add Inherited Form...". You pick the Form class you created from the dialog box. (Alternatively, you can create a default form and change the source code so the new Windows Form inherits from your form). This way, you end up with a new form that is exactly like the Form class you fine-tuned. Your own Form class inherits all functionality from a default System.Windows.Forms.Form class, so you don't have to fear losing any functionality or incompatibility with future versions of the Framework's Form class. You simply have a version of the form that is a bit more powerful than it would be if you were using the "barefoot" version. But wait: there is more!? ? ? Have you gotten your CoDe CDs yet? CoDe Magazine content is also available on CDs! If you have missed 2000 - 2002, make sure you get your CD now while they are still available. Also, the new 2003 CD is just around the corner! Don't miss out! Get your CDs as well as back issues in the CoDe store: New Web Site Features Have you seen our new web site? The new CoDe Magazine site allows subscribers to read articles online and?post comments. The site also allows subscribers to manage their subscriptions, change addresses online, and more. Want to?know when the last issue has been shipped to you? Find out online!?We encourage you to poke around... We have recently also added an RSS feed to the CoDe web site, allowing you to use an RSS Syndication News Reader on CoDe Magazine content. Is This Spam? No. You receive this email because your CoDe Magazine account/subscription indicates that you are interested in receiving email newsletters. If you do not wish to?receive CoDe Newsletters?by email, you can change your preferences online: Note: It is our policy not to use a "reply to unsubscribe" process, since this is often used by spamers to verify email addresses before they are passed on. Using the above link ensures that this will not happen at CoDe Magazine.

? ?

?

?

开云体育

CHRTRAN(cSearchedExpression, cSearchExpression, cReplacementExpression)

? CHRTRAN('ABCDEF', 'ACE', 'XYZ')  && Displays XBYDZF
? CHRTRAN('ABCD', 'ABC', 'YZ')  && Displays YZD
? CHRTRAN('ABCDEF', 'ACE', 'XYZQRST')  && Displays XBYDZF

开云体育

开云体育

开云体育

开云体育

开云体育

开云体育

开云体育

开云体育

-----Original Message-----
From: code@... [mailto:code@...]
Sent: Tuesday, March 16, 2004 6:32 PM
To: pjfern@...
Subject: CoDe Magazine eColumn: Publisher's Point

Other Online Content: ...and much, much more. Visit us at: !

CoDe Magazine E-Mail Column and Newsletter Publisher's Point: Using Your Inheritance Markus Egger Publisher, CoDe Magazine Visual Studio .NET introduced a great feature that was not new to many developers, but was new to Visual Basic developers. It was a feature that greatly increased the options for everyone who previously based their efforts on the COM platform. Am I talking about Web services? Xcopy deployment? The Common Language Runtime (CLR)? Those are good guesses, but what I am talking about is inheritance. To me, this is one of the biggest benefits introduced by the first version of Visual Studio.NET. In fact, to me, the lack of inheritance support was the main reason I avoided VB programming in the pre-.NET world. It was unbelievable to me that a mechanism so fundamental to object-oriented development was not available. The tides have turned though, and now we have inheritance support and more: cross-language inheritance that represents the foundation of everything in the .NET Framework. I am happy to see developers using this great feature in many ways and for many different purposes. It seems that increasing numbers of developers understand not just the theory of inheritance, but also know how to use this powerful feature in real-life situations. Yet there is one area where inheritance is often overlooked: inheritance in Windows Forms. Why is that? Frankly, the thought of re-creating forms that behave like I want them to, re-creating buttons that look like I want them to, and re-creating textboxes that format their input the way I want them to, gives me the heebie-jeebies! To be honest, technically, inheritance is used a lot in Windows Forms, as every new form that gets created is a sub-class of a Form class. But that's not what I am talking about. Consider a simple scenario. Assume that you need to build a Windows Forms application with a variety of different forms. You might right-click your solution and choose "Add Windows Form..." from the menu. This appears to create a brand new form from scratch, but it really doesn't. Instead, the Designer creates a new class that inherits from System.Windows.Forms.Form, and which looks and behaves very much as you would expect a Windows form to behave. The class makes calls to the Windows API to produce something that looks like a window and a form. The class provides easy access to many of a form's features, such as the ability to set the window's title or to specify whether you even want a title bar. The System.Windows.Forms.Form class goes beyond a bare-bones abstraction of a simple window, and provides features such as integrated localization or the ability to set the "Accept" button. Everything provided by the basic System.Windows.Forms.Form class is great stuff, and by adding a "new" class to the project that inherits from System.Windows.Forms.Form, you tell the compiler that you want to create a class that is exactly the same. You end up with something that looks and behaves like a form and you can safely proceed to adding additional objects (buttons, textboxes, etc.) and additional functionality to the form. To state it a bit differently: you started out with a generic form that was just like any other form, and only added and changed the things that were exceptional. This is why inheritance sometimes is also referred to as "programming by exception." So far, so good. But the million-dollar-question is: what are the chances that the basic System.Windows.Forms.Form class fits your needs 100%? Pretty close to 0? How often do you go into your new form and change the same exact property that you have been changing in all the other forms you have ever created, like maybe the icon? All the time? I thought so. So why, I ask, would you keep doing this? My guess is that performing these types of repetitive tasks is not the highlight of your developing day. The solution is simple: use inheritance the same way you use it in other development areas, and use it the same way the Microsoft Windows Forms team used it when they built that part of the .NET Framework. So how do you use inheritance like that? First you create a Forms class the same way you would when building any new form, because that new form really is a subclass of the default System.Windows.Forms.Form class. Then, change whatever you want to change. Maybe you want to change the default icon. Maybe you want to add some functionality that manages the form's default screen position a bit differently. Maybe you want to render the form's background in a slightly different way. Or maybe, you are happy with the way the form works for the time being, but want to give yourself a nice place to add and change behavior and appearance later. Then, whenever you create a new form class, instead of picking "Add Windows Form..." from the right-click menu, pick "Add Inherited Form...". You pick the Form class you created from the dialog box. (Alternatively, you can create a default form and change the source code so the new Windows Form inherits from your form). This way, you end up with a new form that is exactly like the Form class you fine-tuned. Your own Form class inherits all functionality from a default System.Windows.Forms.Form class, so you don't have to fear losing any functionality or incompatibility with future versions of the Framework's Form class. You simply have a version of the form that is a bit more powerful than it would be if you were using the "barefoot" version. But wait: there is more!? ? ? Have you gotten your CoDe CDs yet? CoDe Magazine content is also available on CDs! If you have missed 2000 - 2002, make sure you get your CD now while they are still available. Also, the new 2003 CD is just around the corner! Don't miss out! Get your CDs as well as back issues in the CoDe store: New Web Site Features Have you seen our new web site? The new CoDe Magazine site allows subscribers to read articles online and?post comments. The site also allows subscribers to manage their subscriptions, change addresses online, and more. Want to?know when the last issue has been shipped to you? Find out online!?We encourage you to poke around... We have recently also added an RSS feed to the CoDe web site, allowing you to use an RSS Syndication News Reader on CoDe Magazine content. Is This Spam? No. You receive this email because your CoDe Magazine account/subscription indicates that you are interested in receiving email newsletters. If you do not wish to?receive CoDe Newsletters?by email, you can change your preferences online: Note: It is our policy not to use a "reply to unsubscribe" process, since this is often used by spamers to verify email addresses before they are passed on. Using the above link ensures that this will not happen at CoDe Magazine.

? ?

?

?

开云体育