Buy Dabur Pharma above 68.00.

Term : Medium Term

Target : 73.00

Stop Loss : 66.65

Current Market Price : 66.40

Imports System
Imports System.IO

Public Class MainClass

Shared Sub Main()

Dim i As Integer
Dim theBytes(255) As Byte
For i = 0 To 255
theBytes(i) = CByte(i)
Next
Dim myFileStream As FileStream
Try
myFileStream = New FileStream(“test.txt”, FileMode.OpenOrCreate, FileAccess.Write)
myFileStream.Write(theBytes, 0, 256)
Finally
If Not (myFileStream Is Nothing) Then myFileStream.Close()
End Try

Dim theFile As FileStream
Try
theFile = New FileStream(“test.txt”,FileMode.Open, FileAccess.Read)
For i = 0 To (theFile.Length – 1)
Console.Write(theFile.ReadByte)
Next
Catch e As Exception
Throw e
Finally
If Not (theFile Is Nothing) Then theFile.Close()
End Try
End Sub

End Class

And what makes it so smart?

The term Smart Client was coined to highlight the differences
between the typical “Rich Client” applications of yesteryear and the
next generation of client applications. To understand these
differences, and to understand how they are likely to change the face
of client-side computing, it is useful to take a trip down memory
lane…

Client Applications: Then and Now

In the dim and distant past (that is, the mid 1990’s) there was a
dramatic increase in the number of client applications being developed
for the Microsoft® Windows® platform. This increase occurred in large
part due to the availability of high-quality developer tools and
frameworks (such as Microsoft® Visual Basic®, Microsoft Visual Studio®,
MFC, and so on) and because of the availability of a feature-rich
client platform. Ah, developer heaven.

The majority of these applications were standalone and operated on
the client machine with no regard to the environment in which they
operated, both with respect to the other machines and services on the
network, and with respect to the other applications on the user’s
machine. Very often, integration between applications was limited to
using the cut-copy-paste features provided by Windows to transfer small
amounts of data between applications. On the whole, though, users were
pleased with the increasingly useful functionality that these
applications now provided.

After a while, two-tier applications started to appear; these
allowed multiple users to access common data that resided on the
network. Shortly thereafter, DCOM allowed applications to become more
distributed, with logic and state no longer tied to the client machine.
Both of these developments were important and enabled a whole host of
new scenarios and better functionality.

All of this increased flexibility and functionality, however, came
at a price. Perhaps the biggest problem with rich client applications
was that of deployment. As the complexity of the applications and the
client platform had increased, so had the difficulty associated with
deploying the application to the client machine in a reliable and
secure way. One of the biggest problems was that of “DLL Hell,” where
one application could break another application by deploying an
incompatible shared component or library.

In addition, the increasingly connected nature of applications
brought with it many other problems. Connected applications were
considerably more complex to develop, despite the availability of
developer tools and frameworks. And as the size and complexity of these
distributed applications grew, the tight coupling between the client
application and the services it consumed became increasingly difficult
to maintain, which in turn exacerbated the deployment and maintenance
problems.

So, while rich clients typically provided a great user experience
and had good developer support, they were still just too difficult to
deploy and maintain.

Around this time, the Internet came along.

The Internet had very little effect on rich client applications.
Some applications provided the ability to notify the user of available
updates, or allowed additional content or features to be downloaded and
installed, but on the whole, the Internet had little influence on how
client applications were developed, deployed, and maintained.

The Internet did provide an alternative to the traditional rich
client model, however, one which promised to solve all of the problems
associated with application deployment and maintenance. Thin client
browser-based applications allowed applications to be deployed and
updated centrally, thereby reducing the problems (and therefore the
cost) associated with deploying and maintaining an application. Also,
thin client applications allowed companies to expose their applications
to a large and diverse external audience.

Unfortunately, this brave new world was not without disadvantages.

Thin client applications at that time often represented the best way
to expose a company’s information and services to an external user
base. But in many cases, internal applications that would have
traditionally been implemented using a rich client application were
also moved to the thin client model. While this movement had advantages
in reducing deployment complexity, it did so at the cost of the user
experience.

The usability of the applications was often much reduced and common
features that the user had grown accustomed to, such as drag-and-drop,
undo-redo, context sensitive help, and so on, were no longer available.
Furthermore, the responsiveness of the application was diminished,
especially for business applications, such as those in customer call
centers, which demanded heavy data entry and navigation across multiple
screens.

And of course, the browser was entirely dependent on having a
network connection at all times. This meant that mobile workers had no
access to the applications at all, requiring them to re-enter data when
they returned to the office. And even when a connection was available,
low bandwidth or high latency connections caused performance problems
and a reduction in user efficiency.

Developers, too, suffered in the early days of thin clients. Tool
support was lacking, and developers had to move from the cozy world of
component-based development, with type safety and object-oriented
design principles, to the harsh and unforgiving world of script and
HTML. Only now can Web developers claim to have anything approaching
the same level of support as client developers enjoyed 4 or 5 years
ago. Even now, drag-and-drop, undo-redo, context sensitive help, and
other common client-side features are still extremely challenging.

Despite these drawbacks, the deployment and management problems
associated with rich clients were so big that the tradeoff seemed worth
it. As a result, the thin client browser-based application model has
dominated in recent years.

Client Applications: The Next Generation

Today we live in an information-based economy. In order to thrive in
this hyper-competitive market, users must access and borrow information
from many sources, including customers, partners, and suppliers. And
users are now demanding more from their applications: they want to be
empowered to act, plan, analyze, visualize, and explore the data, not
just to read it.

Such concerns are not limited to a company’s internal workforce.
Leading companies are increasingly becoming aware that they have to
build a digital relationship with their customers and partners,
allowing them to provide faster and more accurate responses to customer
requests and giving them easy access to purchasing, inventory, and
shipping-status information. These users also need to be able to work
with the data within their own applications.

Without question, the complexity of applications is increasing, and
with it the expectations of the user. The thin client model is no
longer able to provide the required levels of functionality,
performance, flexibility, and integration. Users are now demanding fast
and responsive applications to perform their daily work in a flexible
and efficient manner. Add this to the explosion of devices and the
increasing mobility of the workforce and it is clear that a new
category of client application is required.

So, the pendulum has begun to swing back towards the rich client
model. But what about application deployment and update? The TCO of an
application is still as important as it ever was, probably more so. Do
you sacrifice manageability for usability, or vice versa?

Happily, you don’t need to sacrifice either. Key capabilities
now exist which mean that we can take full advantage of the rich client
model, providing the user with an excellent user experience, while at
the same time reaping the benefits of centralized deployment and
update. In short, this new generation of client applications, the
so-called “smart” clients, provides the best of both worlds and adds
the intelligence to manage data and connectivity to produce an
extremely compelling user experience.

While smart clients provide the benefits of a
rich client model with thin client manageability, they also provide
much more flexibility than the traditional rich client applications.
For example, smart clients need not be designed as monolithic desktop
applications. Smart client solutions can be developed that are composed
of functionality from more than one client application, with each
application collaborating with the others to provide just the right
functionality to the user. Such “composite” applications integrate
client-side software resources into a coherent solution, or extend the
functionality of an existing application to provide smart client
features.

In addition, the client platform has moved on in the past few years
and now includes many different types of client devices, not just
desktop PCs. Such devices include PDA’s, SmartPhones, Tablet PCs,
Laptops, set-top boxes, automotive devices, retail terminals, and so
on. Smart client applications can be built to take maximum advantage of
the features provided by the host device and tuned to provide the best
user experience for the typical users of these devices.

Smart Client Check List

Because of the high degree of flexibility and somewhat ambiguous
nature of smart client applications, it is often useful to talk about
the key characteristics of a smart client. These characteristics serve
as a guide to the features typically provided by smart clients over and
above those provided by traditional rich client applications. If a
client application displays these characteristics, then it can be said
to be smart:

• Utilizes Local Resources
  A smart client application
  always has code artifacts on the client that enable local resources to
  be utilized. What do we mean by local resources? We mean everything
  from hardware to software resources. A smart client may take advantage
  of the local CPU or GPU, local memory or disk, or any local devices
  connected to the client, such as a telephone, bar-code/RFID reader, and
  so on. But it may also take advantage of local software, such as
  Microsoft Office applications, or any installed line-of-business (LOB)
  applications that interact with it.

• Connected
  Smart client applications are never
  standalone and always form part of a larger distributed solution. This
  could mean that the application interacts with a number of Web services
  that provide access to data or an LOB application. Very often, the
  application has access to specific services that help maintain the
  application and provide deployment and update services.

• Offline Capable
  Because they are running on the
  local machine, one of the key benefits that smart client applications
  offer is that they can be made to work even when the user is not
  connected. For applications running in occasional or intermittent
  connectivity situations, such as those used by traveling workers or
  even those running on laptops, tablets, PDA’s, and so on, where
  connectivity cannot be guaranteed at all times, being able to work
  while disconnected is essential. Even when the client is connected, the
  smart client application can improve performance and usability by
  caching data and managing the connection in an intelligent way.

  
  

• Intelligent Install and Update
  Smart client applications manage their deployment and update in a much more
  intelligent way than traditional rich client applications. The .NET
  framework enables application artifacts to be deployed using a variety
  of techniques, including simple file copy or download over HTTP.
  Applications can be updated while running and can be deployed on demand
  by clicking on a URL. The Microsoft® .NET Framework provides a powerful
  security mechanism that guarantees the integrity of the application and
  its related assemblies. Assemblies can be given limited permissions in
  order to restrict their functionality in semi-trusted scenarios.

• Client Device Flexibility
  The .NET Framework
  together with the .NET Compact Framework provides a common platform
  upon which smart client applications can be built. Often, there will be
  multiple versions of the smart client application, each targeting a
  specific device type and taking advantage of the devices unique
  features and providing functionality appropriate to its usage.

Smart Clients and the .NET Framework

So how does the .NET Framework enable all of these smart client benefits?

The .NET Framework provides a number of fundamental capabilities,
which means that we no longer have to face the difficult usability
versus manageability tradeoff. Let’s look at some of the more important
features…

The .NET Framework has very effectively solved the problem of
version conflicts between assemblies shared by more than one
application. A .NET application or assembly has a strong coupling to
the assemblies and components they depend on. Assemblies are annotated
with meta-data, which specifies both their exact version and the
versions of all dependent assemblies. Multiple versions of the same
assembly can be installed side-by-side so that all applications can be
run with the exact same version of the assembly that they were built
and tested against.

This assembly binding mechanism also provides important security
safeguards. Assemblies can be cryptographically signed to prevent
malicious code being run inadvertently, either through tampering or
through luring attacks. In addition, .NET Code Access Security (CAS)
allows assemblies to be granted specific permissions so that they can
be used in semi-trusted scenarios. The .NET runtime ensures that
assemblies can only carry out operations for which they have been
granted permissions. The .NET Framework defines a flexible evidence
based infrastructure for determining which permissions to grant an
application or assembly.

These features effectively address application stability and
predictability, but what about deployment? Assemblies do not need to be
registered on the local machine so they can simply be copied to the
machine before they are run. This greatly simplifies the deployment of
the application. Alternatively, assemblies can be downloaded from a
central server, either at install or at run time.

.NET also provides a deployment feature called No-Touch Deployment,
which allows applications to be run on a URL. When the user clicks on
the URL, the runtime automatically downloads the application, and all
related assemblies, to a special download cache. This mechanism also
checks for version updates so that the user never has to worry about
whether they are running the latest version of the application or not.

Applications deployed in this way are only granted a very limited
amount of permissions by default and are unable to access the local
hard disk or access any network services, apart from the service from
where they were downloaded. Additional permissions can be granted at
the user, machine, or enterprise level if required.

Of course, the .NET Framework provides quite a few other features
that affect how smart client applications can be designed and built. Of
particular important are the Microsoft® .NET Windows Forms classes.
These classes provide very rich user interface controls and give
developers in all languages a common UI framework to work against,
making development and testing much easier. The .NET Framework also
provides many facilities for connecting to network services, such as
SOAP-based Web services, and provides comprehensive XML support.

Smart Client Architecture

As .NET provides a number of key features that make the development
of smart client applications easier, what are the architectural
implications of all of these new features? It turns out that .NET goes
beyond solving the problems that plagued rich clients and enables a
whole host of new possibilities. The client platform now includes many
different types of client device, and .NET supports them through the
full and compact frameworks, but that’s just the start.

The flexible binding, deployment, and security models provided by
.NET allow smart client applications to be designed in much more
interesting ways than traditional rich clients. For example, .NET
provides a lot of flexibility in how the application can be “hosted”:
applications can be run as a traditional desktop application, or can be
hosted within Microsoft® Office or Microsoft® Internet Explorer. Many
combinations are possible. For instance, a Windows Forms application
can host Internet Explorer or Office components and any host can
subsume any other.

Application logic that is volatile, for example business rules
governing volume order discounts, can be factored into assemblies that
are downloaded on demand over HTTP, obviating the need to frequently
“update” the client application in the traditional sense. Additional
(or infrequently used) application features can adopt the same model so
that initial application size is kept to a minimum with additional
features installed on an as-needed basis.

Another popular model is the Composite Application model, where many
applications combine to form a coherent solution. Such solutions can be
formed by coupling together desktop applications, or by providing a
generic “shell” application that houses multiple lightweight
applications combining to form the solution.

The latter model has proven to be extremely useful in situations
where the user has to deal with many applications to do their work. For
example, customer service agents in call centers typically have to deal
with many LOB applications, including desktop, browser-based, and
terminal-based applications. All such LOB applications can be hosted
within a generic Windows Forms application that provides integration
between them, greatly simplifying the user’s job and, most importantly,
reducing the time spent on a particular call.

By providing a generic shell to host these LOB applications, common
infrastructure features, such as security, deployment, window
management, application integration, auditing, and so on, can be
developed, tested, and re-used across different solutions, leaving the
developers of the LOB applications to focus on business functionality.

Perhaps the most compelling example of a composite smart client
application is Microsoft Office. Microsoft Office applications can be
extended using SmartTags, SmartDocuments, or with Microsoft® Visual
Studio® Tools for Office enabling powerful smart client solutions to be
built.

Office smart client solutions can become an integral part of an
organization’s information infrastructure, accessing corporate data and
services and providing a powerful and familiar working environment. Of
course, Web services provide a natural way for companies to expose data
and services, and smart client applications are the ultimate consumers
of these Web services. And since Microsoft Office also provides XML
support, data can easily be shared between both client and server and
between the user’s desktop applications.

Office smart client applications are capable of integrating data and
services provided by multiple line-of-business (LOB) applications, each
accessed through separate Web services. Such smart client applications
can provide valuable Business Intelligence functionality, providing the
user with access to critical business data in powerful desktop
applications, such as Microsoft® Excel, where they can visualize,
pivot, and analyze the data as much as required.

And finally, the advent of service-oriented architectures (SOA)
means that there are huge opportunities for client applications to take
advantage of the many and varied services available to them. All such
services are provided in an industry standard way, which provides huge
benefits in terms of interoperability, developer tool support, and the
ease with which new features can be built into the smart client
application.

Next Up: Whidbey and Longhorn

The above discussion focuses on the benefits that .NET currently
brings to the area of smart clients. What about the future? The next
release of the Microsoft .NET Framework, code-named “Whidbey,” will
bring a whole set of new features that build on the .NET Framework and
make smart clients even more compelling: richer and more flexible user
interface components, easier thread management, better tools, and a new
deployment feature called click-once, which builds on the no-touch
deployment mechanism described above.

Microsoft Windows, code-named “Longhorn,” will take smart clients to
a whole new level, with features like the presentation subsystem in
Longhorn (code-named “Avalon”) providing next generation meta-data
driven user interfaces, and the storage subsystem in Longhorn
(code-named “WinFS”) providing huge integration opportunities between
applications. Check out the Longhorn smart client demo for commercial
real estate at http://msdn.microsoft.com/Longhorn/productinfo/default.aspx for a glimpse of the Longhorn smart client vision.

Many analysts have been predicting for a while now that the pendulum
has swung back towards rich clients and away from browser-based
applications. With .NET, and especially with Whidbey and Longhorn, it
looks like the time of the smart client is well and truly upon us.

by Cory Smith

Table of Contents

1. Introduction
2. Style Guidelines
2.1 Tabs and Indenting
2.2 Option Explicit / Option Strict
2.3 Block Formatting
2.4 Single line statements
2.5 Commenting
2.5.1 Copyright notice
2.5.2 Documentation Comments
2.5.3 Comment Style
2.6 Spacing
2.7 Attributes
2.8 Naming
2.9 Naming Conventions
2.9.1 Interop Classes
2.10 File Organization
2.11 Doing things the Visual Basic .NET Way
2.12 Microsoft.VisualBasic.Compatibility
2.13 Other Considerations
2.14 Special Thanks

1. Introduction

First, read the .NET Framework Design Guidelines. These guidelines exist to extend upon those guidelines for the VB.NET developer. Almost all naming conventions, casing rules, etc., are spelled out in this document. Unlike the Design Guidelines document, you should treat this document as a set of suggested guidelines. These guidelines are not to be taken a law and exist to offer guidance for people who do not have guidelines or are seeking improving upon their existing coding habits.

Note: Portions of this document are based on the C# Coding Guidelines written by Brad Abrams.

2. Style Guidelines

2.1 Tabs & Indenting

Tab characters (ASCII 9) should not be used in code. All indentation should be done with 2 space characters.

2.2 Option Explicit / Option Strict

Although it’s possible to enable these options within the project properties, you should place the following at the top of every source file:

Option Explicit On
Option Strict On

If you are unable to have both of these set to “On”, a comment should be given as to the reason for doing so.

2.3 Block Formatting

All logical blocks should be formatted in such a way as to be clean and clear as to what’s occurring. Every If/Then should have an End If.

If someExpression Then
DoSomething()
Else
DoSomethingElse()
End If

“Select Case” statements should be formatted as follows:

Select Case someExpression
Case 0
DoSomething()
Case 1
DoSomethingElse()
Case 2
Dim n As Integer = 1
DoAnotherThing(n)
Case Else
‘ Normally this would be the default.
End Select

2.4 Single line statements

Single line statements should be avoided in every instance except possibly the Select Case blocks. Even then, strong consideration needs to be given to doing so and only done if the statement in question is a single line and very short. If any of the Case elements are not a single line, make all of the Case elements multiple lines for consistency.

Right:

Select Case value
Case 0: x += 1
Case 1: x += 5
Case Else: x += 10
End Select

Or

Select Case value
Case 0
DoSomeProcessStep1()
DoSomeProcessStep2()
x += 1
Case 1
x += 5
Case Else
x += 10
End Select

Wrong:

Select Case value
Case 0: DoSomeProcessStep1() : DoSomeProcessStep2() : x += 1
Case 1
x += 5
Case Else: x += 10
End Select

2.5 Commenting

Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand a function’s intended behavior and general operation. While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer’s intent and approach.

2.5.1 Copyright notice

Each file should start with a copyright notice. To avoid errors in doc comment builds, you don’t want to use triple-apostrophe doc comments, but using XML makes the comments easy to replace in the future. Final text will vary by product (you should contact legal for the exact text), but should be similar to:

‘———————————————————————–
‘ <copyright file=”ContainerControl.vb” company=”Microsoft”>
‘ Copyright (c) Microsoft Corporation. All rights reserved.
‘ </copyright>
‘———————————————————————–

Contact legal? As you can see with the mention of Microsoft Corporation within the example, this section is included mainly to be consistent with the Microsoft internal C# guidelines. Whatever the reason may be, it’s pretty good advice.

2.5.2 Documentation Comments

All methods should use XML doc comments. For internal dev comments, the <devdoc> tag should be used.

Public Class World

”’ <summary>Public stuff about the method</summary>
”’ <param name=”value”>What a neat parameter!</param>
”’ <devdoc>Cool internal stuff!</devdoc>
”’
Public Sub MyMethod(Byval value As Integer)
‘ …
End Sub

End Class

2.5.3 Comment Style

The ‘ (apostrophe) style of comment tag should be used in most situations. Where ever possible, place comments above the code instead of beside it. Separate the actually comment (text) from the comment tag with a minimum of a single space, begin the comment with an uppercase letter (proper sentence structure) and end each comment with a period. Here are some examples:

‘ This is required for WebClient to work through the proxy.
GlobalProxySelection.Select = New WebProxy(“http://itgproxy”)

‘ Create object to access Internet resources.
Dim myClient As New WebClient()

Comments can be placed at the end of a line when space allows:

Public Class SomethingUseful
Private itemHash As Integer ‘ Some instance member.
Private Static hasDoneSomething A Boolean ‘ Some static member.
End Class

2.6 Spacing

In addition to using the “Pretty Listing” feature from within Visual Studio, follow these guidelines. Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

• Do use a single space after a comma between function arguments.

  Right:

  Console.In.Read(myChar, 0, 1)

  Wrong:

  Console.In.Read(myChar,0,1)

• Do not use a space after the parenthesis and function arguments

  Right:

  CreateWorld(myChar, 0, 1)

  Wrong:

  CreateWorld( myChar, 0, 1 )

• Do not use spaces between a function name and parenthesis.

  Right:

  CreateWorld()

  Wrong:

  CreateWorld ()

• Do use a single space before and after comparison operators

  Right:

  If (x = y) Then

  Wrong:

  If (x=y) Then

• Do use single line spacing between Class, Module, Method and Property definitions

  Right:

  Sub Spin()
  End Sub

  Sub Bounce()
  End Sub

  Wrong:

  Sub Spin()
  End Sub
  Sub Bounce()
  End Sub

Someone asked about defining spacing within the methods. To me, this is something that is pretty dependent on the type and amount of code within the method. My general rule of thumb is methods that contain a section of variable declarations or contain a lot of If/End If testing, I add a single space on either side of the code. For code that is very small and/or doesn’t contain any variable declarations separated on their own, I usually have no spacing within the method.

2.7 Attributes

Attributes should be on the line before the statement the attribute is pertaining to (followed by the space underscore)

<Flags()> _
Public Enum ExitWindowFlags
LogOff = &H0
Shutdown = &H1
Reboot = &H2
Force = &H4
PowerOff = &H8
ForceIfHung = &H10
End Enum

2.8 Naming

Follow all .NET Framework Design Guidelines for both internal and external members. Highlights of these include:

• Do not use Hungarian notation (except for private member variables).
• Do use the m_ prefix for private Class level member variables.

  This is the only guideline in this document that goes against the .NET Framework Design Guidelines, but the guidelines in that document assume languages that are case-sensitive. It is necessary to distinguish the private member variables in some manner as to not collide with the public properties of the same name. To offer complete consistency, this guideline is extended to all private member variables.
  

• Do use camelCasing for member variables.
• Do use camelCasing for parameters.
• Do use camelCasing for local variables.
• Do use PascalCasing for function, property, event, and class names.
• Do prefix interfaces names with “I”
• Do not prefix enums, classes, or delegates with any letter
• Do not use single-letter naming for variables.
• Avoid using constants, use Enum instead. However, when you can’t avoid using constants, use PascalCasing.
• Do use ex as the local exception variable in a Try…Catch statement.

The reason to extend the public rules (no Hungarian, etc.) is to produce a consistent source code appearance. In addition a goal is to have clean readable source. Code legibility should be a primary goal.

2.9 Naming Conventions

2.9.1 Interop Classes

Classes that are there for interop wrappers (Declare statements) should follow the naming convention below:

• NativeMethods – No suppress unmanaged code attribute, these are methods that can be used anywhere because a stack walk will be performed.
• UnsafeNativeMethods – Has suppress unmanaged code attribute. These methods are potentially dangerous and any caller of these methods must do a full security review to ensure that the usage is safe and protected as no stack walk will be performed.
• SafeNativeMethods – Has suppress unmanaged code attribute. These methods are safe and can be used fairly safely and the caller isn’t needed to do full security reviews even though no stack walk will be performed.

  Class NativeMethods

  Private Sub New()
  End Sub

  Friend Declare Sub FormatHardDrive Lib “user32″ (ByVal driveName As String)

  End Class

  <SuppressUnmanagedCodeSecurityAttribute()> _
  Class UnsafeNativeMethods

  Private Sub New()
  End Sub

  Friend Declare Sub CreateFile Lib “user32″ (ByVal fileName As String)

  End Class

  <SuppressUnmanagedCodeSecurityAttribute()> _
  Class SafeNativeMethods

  Private Sub New()
  End Sub

  Friend Declare Sub MessageBox Lib “user32″ (ByVal [text] As String)

  End Class

All interop classes must be Private, and all methods must be Friend. In addition a private constructor should be provided to prevent instantiation.

Use the Declare statement instead of the Attribute/Method blocks for declaring Win32 interop unless there is a need to do so because the Declare statement doesn’t expose some needed functionality.

When handling errors involved with interop, use the follow when the API documentation states to use GetLastError (if you aren’t going to handle the error within the code):

Throw New Win32Exception(Marshal.GetLastWin32Error)

2.10 File Organization

• Source files should contain only one public type, although multiple internal classes are allowed.
• Source files should be given the name of the Public Class in the file.
• Directory names should follow the Namespace for the class.

For example, I would expect to find the public class “System.Windows.Forms.Control” in “System\Windows\Forms\Control.vb”…

Class elements should be grouped into sections. Within these sections, elements should be alphabetized.

• Private member variables
• New / Finalize / Dispose
• Public
  • Events
  • Properties
  • Methods
  • Enumerators
• Protected
  • Events
  • Properties
  • Methods
  • Enumerators
• Friend
  • Events
  • Properties
  • Methods
  • Enumerators
• Private
  • Events
  • Properties
  • Methods
  • Enumerators

2.11 Doing things the Visual Basic .NET Way

• Do use the Visual Basic runtime methods rather than .NET Framework where appropriate.
• Do use the short method for instantiating classes on the same line.

  Right:

  Dim someStuff As New Collection()

  Wrong:

  Dim someStuff As Collection = New Collection()

• Do use Try…Catch instead of On Error.
• Do use Cnnn() methods instead of System.Convert.Tonnn() methods.
• Do not use type characters ($, !, #, %, etc.)
• Do not create a Class containing only Shared methods. Use Modules instead.

Using the Visual Basic runtime seems to cause people to enter into a holy war, so to explain this: First, taking the example of Right(); yes, in the end, it will call upon String.Substring(). It’s doing a bit more than that, which in many cases helps to make sure you code is more stable. Here is basically what the code looks like. Public Shared Function Right(ByVal value As String, ByVal length As Integer) As String If (length < 0) Then Throw New ArgumentException(“Length is too short.”) End If If (length = 0 OrElse value Is Nothing) Then Return “” End If Dim size As Integer = value.Length If (length >= size) Then Return value End If Return value.Substring(size – length, length) End Function By using Right, you don’t have to worry about whether or not the value is nothing or even if the size you want is within the range. However, if this is important to you, then by all means, use Substring directly. I added the “where appropriate” because I think there are some areas where it makes more sense to use the objects (String for example) method over the runtime method. The main point here is to not be afraid to utilize these methods and if you don’t use them, be sure you are aware of the reason as to why you aren’t. The second reason is that this suggestion is shared by members of the VB team; obviously they worked hard to make these available in order to make our development life more productive and I don’t blame them for wanting to see the fruits of their labor leveraged by us. In addition, I’m constantly seeing false information being spread regarding the “non-use” of the runtime and how it’s not the “.NET” way. These are every bit a part of the .NET Framework as say Windows Forms, ADO.NET, ASP.NET, etc. and should be given as much, if not more, consideration in being leveraged, especially by VB.NET developers. Third, the compiler is able to optimize the code when you leverage several of these and my guess is this will improve over time. Not using these puts that responsibility on you, the developer and you don’t gain any of these benefits in the current and future compiler. This is a minor point, but one I feel I should mention for completeness. In the end, use whatever you are most comfortable with. Just be aware that it’s not “wrong” to leverage the runtime, in fact, in many cases its significantly better than trying to do the same task on your own. To be fair, there are some areas in the VB runtime that don’t perform that well; in those instances, you have to decide whether performance is your key concern and if it is, for those instances (and, this part is key, if it truly is a bottleneck), find an alternate solution. Performance is a completely different subject and there is no one right answer.

2.12 Microsoft.VisualBasic.Compatibility

Do not use any methods within the Microsoft.VisualBasic.Compatibility namespace. This namespace is not to be confused with Microsoft.VisualBasic; I encourage you to use these timesaving tidbits. If your project contains a reference to the Microsoft.VisualBasic. Compatibility.dll, remove it and replace any methods that have become invalid with methods either from the Microsoft.VisualBasic or System namespaces.

2.13 Other Considerations

The following are general considerations that you should keep in mind.

• Use collections instead of arrays when returning a group of data from a method.
• Use events instead of overriding methods. For example, use the Paint event instead of overriding OnPaint.
• Avoid requiring the orchestration of multiple objects to do a single job.
• Avoid performing operations within properties, use properties to set state. Configure an object through its properties and then use its methods to do the work.
• Try to gather items in a namespace that directly relate to each other. Try to avoid putting too many classes under a general category as it creates intellisense noise for developers trying to find something.

2.14 Special Thanks

I’d like to thank the following people for their invaluable input while working on this document:

Brad Abrams (Microsoft)
Paul Vick (Microsoft)
Tyler Whitney (Microsoft)
Erik Porter (MVP)

Titanic was sinking.
An englishman asked Santa, “How far is land”?
Santa: 2 KMs.
Englishman jumped into sea.
Englishman: Now, which direction?
Santa: Downwards!

Two days of powercut in Delhi had made life miserable. Worst affected was Delhi Metro station where families of Santa & Banta were struck for 48 hrs on escalators

Public Class Singleton
Private Shared SP As Singleton
Private InnerList as New Collections.ArrayList()

Private Sub New()
End Sub

Public Shared Function Create() As Singleton
If SP is Nothing Then SP = New Singleton()
Return SP
End Function

Public ReadOnly Property List As Collections.ArrayList
Get
Return InnerList
End Get
End Property
End Class

Module SingletonExample
Sub Main
Dim CountValue as Integer
Dim SP As Singleton = Singleton.Create()
Dim SP2 As Singleton = Singleton.Create()

SP.List.Add(“First”)
SP.List.Add(“Second”)
SP.List.Add(“Third”)

For CountValue = 0 To SP2.List.Count – 1
Console.WriteLine(SP2.List.Item(CountValue).ToString())
Next
End Sub
End Module

Truth table for Xor

Imports System

Public Class MainClass

Shared Sub Main(ByVal args As String())
‘ create truth table for Xor
Console.Write(“Xor” & vbCrLf & “False Xor False: ” & _
(False Xor False) & vbCrLf & “False Xor True: ” & _
(False Xor True) & vbCrLf & “True Xor False: ” & _
(True Xor False) & vbCrLf & “True Xor True: ” & _
(True Xor True) & vbCrLf & vbCrLf)
End Sub
End Class

Xor Demo

Imports System

public class MainClass
Shared Sub Main()
Dim Var1 As Short

Console.WriteLine( Var1 Xor 5 )

End Sub

End Class

Exit from While Loop

Imports System

Public Class MainClass

Shared Sub Main(ByVal args As String())
Dim counter As Integer

While counter <= 10
‘ skip remaining code in loop only if counter = 7
If counter = 7 Then
Exit While
End If

counter += 1
End While

Console.WriteLine( “counter = ” & counter & _
” after exiting While structure”)

End Sub
End Class

Exit a For Each loop

Imports System
Imports System.Collections

Public Class MainClass

Shared Sub Main(ByVal args As String())
Dim employees As New Collection
employees.Add(New Employee(“A”))
employees.Add(New Manager(“B”))
employees.Add(New Employee(“C”))

Dim a_manager As Manager = Nothing

For Each emp2 As Employee In employees
If TypeOf emp2 Is Manager Then
a_manager = CType(emp2, Manager)
Exit For
End If
Next emp2
Console.WriteLine(“Manager: ” & a_manager.Name)

End Sub

End Class

Public Class Employee
Public Name As String

Public Sub New(ByVal new_name As String)
Name = new_name
End Sub

Public Overridable Function IsManager() As Boolean
Return False
End Function
End Class
Public Class Customer
Public Name As String

Public Sub New(ByVal new_name As String)
Name = new_name
End Sub
End Class
Public Class Manager
Inherits Employee

Public Sub New(ByVal new_name As String)
MyBase.new(new_name)
End Sub
Public Overrides Function IsManager() As Boolean
Return True
End Function
End Class

Use For Each to Loop an Array

Imports System

Public Class MainClass

Shared Sub Main(ByVal args As String())

Dim friends() As String = {“A”, “B”, “C”,”D”, “E”}

Dim friendName As String
For Each friendName In friends

Console.WriteLine(friendName)

Next
End Sub

End Class

Loop through an Array

Imports System

Public Class MainClass
Shared Sub Main()
‘Declare an array
Dim strFriends(4) As String

‘Populate the array
strFriends(0) = “R”
strFriends(1) = “B”
strFriends(2) = “S”
strFriends(3) = “S”
strFriends(4) = “K”

‘Enumerate the array
For Each strName As String In strFriends
‘Add the array item to the list
System.Console.WriteLine(strName)
Next

End Sub
End Class