Oh My! The new My Object in Visual Basic.Net 2005

I have historically favored BASIC in its various forms as my programming language of choice, going back to the very first program I wrote on a HP/1000 teletype terminal in 1978. My one exception is a stint with Borland Delphi (circa version 3) which used Pascal as its language. It is no accident that Anders Hejlsberg, the chief architect for the Delphi product, joined Microsoft in 1996 to be a major player on the .Net development team.

So what does that have to do with the new My object in Visual Basic 2005? It continues the tradition of what has always been best about working in BASIC. While other languages have traditionally been more powerful, BASIC has always excelled at getting useful applications completed quickly. As a business applications developer, my goal has consistently been to deliver a quality application that meets the needs of the users as rapidly as possible and then move on to the next needed solution.

The My object provides much simpler access to commonly needed objects in the .Net Framework Base Class Library. It also adds easy access to functionality that previously required use of the Win32 API. This provides a significant speed improvement in many common development tasks.

The My object has five major subclasses:

• My.Application
• My.Computer
• My.Forms
• My.User
• My.WebServices

If you want to learn more specifics about the My object, see the July 2005 article in MSDN Magazine, available at http://msdn.microsoft.com/msdnmag/issues/05/07/My/default.aspx.

I mentioned earlier that prior versions of BASIC often traded power for productivity. With Visual Basic.Net 2005, this is no longer the case. The faithful BASIC developers can now have their cake an eat it too. This is an exciting time to be a developer!

Joe Kunk

When is True not True?

When saving a boolean value to a Microsoft^® SQL Server 2000 database. In SQL Server 2000, boolean values are represented as data type "bit", with valid values of numeric 0 or 1. When building a SQL INSERT or UPDATE statement, we need to convert a value of TRUE or FALSE easily to a 1 or 0 respectively.

I have found the easiest way is to use the IIF command. Depending on your coding preferences, you should find one of the two choices below will work well for you:

Dim MySQLBoolean as string = IIF(MyBoolean, "1", "0")
or
Dim MySQLBoolean as integer = IIF(MyBoolean, 1, 0)

Compared to an IF-THEN-ELSE approach, I like the IIF approach since it delivers the desired result in a single line of code.Readabilityy in code is very important, but with all other things being equal, one line of code is generally more readable than five lines of code.

Joe Kunk

The Power of Panels in ASP.NET

It is fairly common that it takes several pages to be presented to the user to complete a single logical task within a web application.

Say you have a collection of free email newsletters that you want to offer to your site visitors. If a visitor clicks on the link to select one or more newsletters, you may well present:

[Screen 1] a checklist of the newsletters to choose from with a Submit button, then

[Screen 2] a list of just the newsletters selected with a confirmation button, then

[Screen 3] a printer friendly listing of the selected newsletters along with information on how to change or cancel subscriptions and a nice thank you for subscribing to your site newsletters.

Prior to ASP.NET, you likely would have written these as three separate ASP pages; Screen 1 posts to Screen 2 which posts to Screen 3. Easy enough, but it certainly cluttered up the folders on your web server and tracking logic errors was more difficult across three separate source files.

Now with ASP.Net, all three screens can easily be coded into individual panel objects, all within the same .ASPX web page. The code-behind file makes the needed panel visible and sets the visibility of the other panels to false. The user still sees three different screens in sequence but coding is greatly simplified since it is all contained within a single .vb or .cs code-behind file.

I have used this technique in several web applications and it works great. The invisible panels are not included in the final page to the browser so the download times remain tight. I hope you find this tip very useful.

Joe Kunk

Visual Studio Tools for Office - A Great Thing Soon

I recently spent some time checking out the Visual Studio Tools for Office product, a.k.a. VSTO. It allows Visual Studio developers to add features and capabilities to MS Word, MS Excel, and with the release of Visual Studio 2005, also MS Outlook.

The advantage is that the code to add features or capabilities to these environments can be written fully in Visual Studio using standard C# or VB.Net code with full IntelliSense assistance and all the other advantages of the .Net framework. No need to learn VBA (Visual Basic for Applications) or macros to be productive.

The disadvantage is that VSTO only works with Office 2003 or later. This makes it unsuitable for widespread commercial applications at this time. A small disadvantage is that your assembly must accompany the document as it is moved around the network or emailed in order to maintain the functionality.

Conclusion: VSTO and the Visual Studio integration in SQL Server 2005 are key steps toward the programmer's nirvana of "learn one tool well and use it everywhere". Its impact will be even more positive as the majority of home and business users upgrade to Office 2003 or later.

Joe Kunk

VB.Net Modules in ASP.NET - Trick or Treat in July

Here is the story of a feature in VB.Net that is at the same time very useful and potentially very dangerous.

Microsoft carried the construct of a Module forward from Visual Basic 6 into VB.Net (reluctantly as I understand it). A popular feature among VB6 programmers, it can be viewed as a global class available to all other forms and classes. VB6 programmers commonly used it to hold global variables and methods that would be needed by multiple forms. No instantiation needed, it was just there and global. Very convenient.

VB6 was used primarily to write single-user desktop windows applications. Yes, with the proper level of skill and prayer it could be used for more advanced purposes, but it truly shined as a way to quickly deliver high-quality desktop applications. In a single user environment, a shared global module is not a problem. Use of a module in a single user VB.Net application is still not a problem for the same reason.

Now consider the impact of a module in an ASP.Net application running on a IIS web server. Herein lies the power and the danger.

First the danger. Like before, a module is a class that automatically global to the entire application without requiring any instantiation. But now that single application is being used simultaneously by potentially hundreds or thousands of users. See the problem yet? Any variable declared at the module level is single-instance shared global among all users. If you casually define a module level variable of 'UserName' and base your security permissions on that, you will experience tremendous security issues as incoming users take on whatever security permissions were enabled by the last client that set the 'UserName' variable. Ouch!

Now the power. Modules are a great way to share single-instance methods for very efficient memory usage in VB.Net web applications. Only one copy of each module method is loaded in memory for all users of the application. As long as each of these modules are designed with shared usage in mind and do not depend on any static variables or try to maintain state across calls, this can be a very powerful and efficient design strategy.

Conclusion: In VB.Net web applications, use module level variables with great care, or not at all if possible. Use module methods with care to ensure that they can be safely shared.

I hope you find this information helpful. I wish I had known it earlier and saved myself some grief. Your comments are welcome.

Disclaimer: This post is based on some painful lessons learned from personal experience and not the result the detailed research on the topic. All of the statements in this post are correct to the best of my knowledge but please verify any use of this information with sufficient testing in your particular environment.

Joe Kunk

Getting a DataView to work in an ASP.Net WebForm

With WinForms, I have consistently used dataview controls to allow me to quickly change the sort order or filter of a dataset as seen in a datagrid. It has always worked well for me.

I have not been nearly as successful with WebForms. Whenever I placed a dataview control on a WebForm, it would honor the initial settings of the dataview, but then ignore any runtime changes to those settings. I confirmed that I was properly filling the dataset after each form post.

So how is it that essentially the same exact steps work fine in Windows, but fails in IIS? To get around it I would dynamically compose a new SQL query and load the dataset to match the required sort and filter. This required more coding into the WebForm than really should have been necessary.

I searched extensively for a resolution to this situation but did not find one. Finally, I learned that the trick is to refrain from using the design-time property settings for the dataview when used in a WebForm. Leave the needed properties of the dataview blank and set them only at run-time within code. In this way, it will honor each change in setting and provide the same flexibility to quickly and easily change the view of the data as seen in the datagrid.

Please post a comment to request sample code that illustrates this if you want to see some. I'll put together a good example if there is interest.

Joe Kunk

C#.Net versus VB.Net

This is one of the first issues a developer will face when making the commitment to begin working with the .Net platform. Which to use as your primary development language?

There may be external factors that will push you toward one choice over the other, such as standards in your workplace, a large legacy codebase of C++ or VB, or even the personal preference of your mentor. Since the .Net framework is shared by all .Net languages, it is essentially a toss-up. There are functional differences between the two languages, but they are minor. The good news is that the consistent .Net framework method names between both languages makes it relatively easy for a VB.Net programmer to read C# code, and for a C# programmer to read VB.Net code.

I prefer to work in VB.Net, simply because I have worked in Visual Basic for years and am very comfortable with that style of coding. That said, I can work in C# with only slightly more effort and I think you would find the same to be true. I have seen several surveys over the last year on this issue and developers are pretty evenly split among the two, with professional developers slightly in favor of C#, probably due to the strong presence of C++ code in commercial software applications.

If you have the freedom to make this choice yourself, then choose the language that you are most comfortable in and know that you are in good company with either choice. Learning to be productive in .Net application development is challenging enough, there is no need to complicate it with unnecessary worry about which language to work in.

Joe Kunk

Welcome to JBK.Net

The goal of this BLOG is to share my experiences as a professional application developer and as a board member for our local .Net developer user group.

I have been programming since 1978 and have watched application development evolve from very humble beginnings to the depth & breadth of what Microsoft's .Net environment has to offer today. There is intense joy and pride in delivering an elegant application to the user and knowing that it is among the best software available anywhere for that purpose. I felt that joy with my first program in 1978 and I still enjoy that feeling every time I deliver a new application. That feeling, at least in part, is what drives me to be the best programmer that I can be, and continue to strive to deliver an ever more exciting application next time.

I firmly believe that the .Net platform is the most productive application development platform available today. By taking advantage of its rich framework, I can create applications in a reasonable timeframe that I would never have even attempted before. It has expanded my horizons as a developer immensely. It is an exciting time in the application development world.

By sharing my experiences with .Net, both good and bad, I hope to help others become more productive and effective with .Net.

I will share my mistakes so that others can avoid them. I will share my questions when I am struggling, so we can learn together. I will share my successes so that others can add to their knowledge and skills. Like most developers, what I don't know about .Net far exceeds what I know. I expect to learn a lot from the feedback and comments of the readers of this blog and I truly look forward to the dialog.

Welcome to JBK.Net. I appreciate your company and companionship on the shared quest to become skilled and productive .Net developers.

Joe Kunk