things to avoid in new VB6 project

[funstone]

I have to do new work in VB6. The company has .NET but due to various reasons it is still in pioneer stage.

Unfortunately I do not know VB well, and even less in .NET. Can someone advise me whether there are links on the net that are useful to people working on new VB projects that have to go .NET a few years down the road?

Some of the more pressing concerns are:
1) Should I be designing object oriented VB6 applications now, giving that .NET architecture is quite different. I am thinking of possible benefit in ability to interop with VB6 components in .NET, and vice versa.
2) Where can I find out more about actual experiences in converting VB6 to VB.NET? I have seen a lot of [a href="[URL unfurl="true"]http://msdn.microsoft.com/vbasic/using/migrating/default.aspx"[/URL]]Microsoft material [/a] on the subject matter but these are not enduser experiences?

Thanks in advance for help provided.

David
6th Nov

 

[SqueakinSweep]

Bite the bullet and move to .NET now. You do however need a good grasp of OOP to get started in .NET. There will be a great deal of conversion work if you start projects in VB6 and later decide to move them to .NET.


Sweep
...if it works dont mess with it

 

[chiph]

I agree with SqueakinSweep - use .NET if you can.

If you're stuck with VB6 for whatever reason, I'd do the following:

1. Use Option Explicit at the top of every form & code module
2. Use strong datatypes -- always Dim your variables as something other than Object or Variant
3. Write your code in layers -- Isolate your database stuff in it's own modules so they can more easily be replaced when you go to ADO.NET
4. Don't use bound-controls.
5. Use Classes, not Modules
6. Don't do string-concatenation to build your SQL statements, or your XML (if any). The ADO Parameters are much safer, and in the case of XML, using the .createNode methods prevents character set encoding problems.
7. Think before you code (as always!)

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[atruhoo]

Good article on MSDN about converting VB6 to VB.Net

http://msdn.microsoft.com/library/?URL=/library/techart/vb6tovbdotnet.htm

 

[funstone]

Chiph, SqueakinSweep and others

Thanks for the advice to go .NET all the way now. In our case it is not possible to go .NET but business functionality changes cannot wait.

There are significant .NET work in our workplace and I can only speculate the reasons for not going 100% being:
1) .NET is a oneway path and one can nolonger go backwards;
2) current .NET resources are stretched too thin and is only in webforms
3) the internal adaptation of the framework (including security) being used is still fluid and productivity impact would be smaller if there is a need to backtrack and not everything is framework dependent
4) there may be a cheaper way to interface legacy VB6 applications later on that may not be available now (e.g. a stable web services wrapper).

Whatever the reasons, including those I am unaware of, I have to use VB6 and I see my contribution is to use VB6 in a way that makes .NET migration as easy as possible.

In terms of XML usage suggested, can you elaborate more?


Specificially, there was a VBPJ article on the MSDN archive (see

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbpj01/html/pc0107.asp)

that advocated using XML to build VB6 applications. In light of current state of XML and .NET, is that suggestion still something I should take on board? Are there any adjustments needed?

Thanks again for help offered.

David

 

[chiph]

Don't go hog-wild with XML. It's best used for integration projects. I would not use it to pass between layers in your application, as it's too easy for the format to get out of control.

Regarding the use of .createNode -- many developers get into trouble because they used string concatenation to build their XML:

sXML = sXML & &quot;<Customer>&quot;
sXML = sXML & sCustomerName
sXML = sXML & &quot;</Customer>  & vbcrlf

If sCustomerName contains Unicode values (and in VB6, it will), you can run into document encoding problems if sCustomerName contains characters which don't belong to the encoding family. So do this instead:

Dim oElem as MSXML2.IXMLDOMElement
Set oElem = new MSXML2.IXMLDOMElement
oElem.Text = sCustomerName
oMyDocumentRoot.AppendChild(oElem)

It's wordier, but can be put into a function for some re-use. With good design, you only have to do it once for every business entity you have (all customer XML stuff is in the Customer class).

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[dilettante]

A teensy bit of your (7) above goes away chiph in VB8 with the re-introduction of "edit and continue." That's probably the least of what you were getting at though.

I wasn't totally clear what you were getting at in (6), becuse it is really easy to get some long SQL strings. But I have to believe the compiler is optimizing literal concatenation out. You're probably speaking about variable data and avoiding the use of string concats to embed values into SQL sub-expressions such as WHERE clauses.

I was wondering about your thoughts on encapsulating things you might use in a VB6 program that would be different in a VB.Net program. To clarify this I'm talking about system ActiveX components and API calls, simple example: Winsock control. This is easy to go overboard on, but many programs would probably benefit from wrapping these in a class anyway, because you generally add value to the lower-level DLL or component in your applications that could be reused. "Wrapping" in this manner should ease porting as well.

Maybe my last point is redundant because your (5) mentions modularization. I'd go further and encourage people to "divide now" so they can "conquer later" when the time comes to port to VB.Net though.

 

[chiph]

I wasn't totally clear what you were getting at in (6), becuse it is really easy to get some long SQL strings. But I have to believe the compiler is optimizing literal concatenation out. You're probably speaking about variable data and avoiding the use of string concats to embed values into SQL sub-expressions such as WHERE clauses.

Exactly -- whenever I see "just use the .Replace method" to deal with embedded single-quotes, etc, I just cringe. Anyone who does that is just begging to get hacked (see the single-quote FAQ in the VB6 - Databases forum)

This is easy to go overboard on, but many programs would probably benefit from wrapping these in a class anyway, because you generally add value to the lower-level DLL or component in your applications that could be reused. "Wrapping" in this manner should ease porting as well.

I agree - with something like Winsock - you can use a vendor's .NET control that previously offered an ActiveX control -- maybe the programming interface is the same and it's a direct port.

Otherwise, you'd be better off putting the design time in on creating a wrapper layer to isolate your network communications -- even if you're using a vendor's library -- What if they go out of business? What if they come out with a new version that sucks? (seen that!) What if another vendor's product does more of what you want? By isolating your code in a wrapper that deals with the vendor's library, you insulate yourself from those changes.

Maybe my last point is redundant because your (5) mentions modularization. I'd go further and encourage people to "divide now" so they can "conquer later" when the time comes to port to VB.Net though.

Hopefully people will take the opportunity of moving to .NET to fix some of their design problems. I know that we are -- there was never time to do it right, it seems, and we paid the price!

I would urge people to learn O-O design techniques. Our new database-access layer allows us to call any DB vendor (Oracle, Microsoft, IBM, Sybase) without having if-then-else statements scattered throughout the code. (The power of the factory design pattern!)

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first