Re: Re: chr() .Net equivalent

This is WELL SAID! You show great depth of experience. I hope folks
will take this as gospel!

Also, modifying make the new code unlike the old and a direct
comparison, later, to see if there was a simple conversion "typo" is out
the window, too. Make it in two (and a half) passes, as you mention.

1: Convert,
1.5 Make notes on anything to look at later
2: Fix on the new platform

Then as a new project, look at the notes from the conversion and the
output from the newly functioning program and rationalize any
differences.

A new platform may introduce differences of its own simply due to
changes in the underlying routines, even those of the same name which
have been modified by M$ or some other vendor. Then you are shooting at
a VERY moving target. You have the changes made during conversion and
changes on the new platform and/or called (purchased) routines and one
is not sure which change caused the different output. Then one might
have to back out the change, shoot the difference then put the change
back in causing triple work.

This should be in stone!

Mike

On Sun, 30 Mar 2008 23:07:13 +0100, in
microsoft.public.dotnet.languages.vb "\(O\)enone" <oenone@xxxxxxxxxxx>
wrote:

David Griffiths wrote:
I read many newsgroup articles that say it's better to (or more
correct) to write code without the VB namespace using just the
framework (if that's the correct analogy). Is there any advantage of
writing the code without the VB namespace....?

No.

Particularly if you're upgrading VB6 projects.

One of the things I've become very aware of over the last few years of
upgrading VB6 code to .NET is that it's very easy to "fix" things along the
way, tidying things up and generally improving things. While this seems like
a good idea, it's actually a major opportunity to add subtle bugs to your
code. As a result I now strongly advise my development team to simply
upgrade the code "as is", and worry about fixing things and tidying up
later.

If you start dropping Visual Basic functionality in order to simply avoid
referencing Microsoft.VisualBasic.dll, you'll break your code somewhere
along the line, it's almost inevitable. And for what? There's no benefit to
removing the reference to the DLL, it's a part of the framework so go ahead
and use it. The whole point of the .NET Framework is to provide rich
functionality to applications, and if you decide arbitrarily to ignore a
part of it then it'll just make your coding more difficult.

.

Relevant Pages

  • Re: PDF Framework for smalltalk systems Options
    ... my framework do not make use of special features of DNG. ... If you are using Dolphin, most of the functionality of the framework ... Smalltalk is the platform to avoid ...
    (comp.lang.smalltalk.dolphin)
  • Re: Concerns with COM+
    ... Are you sure your problem is with the framework and not with this "very ... If they want platform independence they can't use COM+. ... Java is interpreted, ...
    (comp.programming)
  • Re: VB6, VB2005, or Something Else?
    ... It seems to me that you are a proponent for the .net framework, ... Relating to the above 4 items: Can't Microsoft: ... Provide better conversion or better abilities to wrap a vb6 project ... in their right mind uses VB's Collection in a speed conscious app. ...
    (microsoft.public.vb.general.discussion)
  • Re: Which is the Best cross platform language?
    ... The only thing I can think of is incompatibility with excel ... the gamers follow the games not the platform. ... Something about functionality & consistency over animated ... Not sure if he was a kook, ...
    (comp.programming)
  • Re: COBOL to Java conversion
    ... experience and at least one of them is currently working in Java. ... platform, but also to change the language to be Java. ... I have not personally seen or worked on a Unisys conversion to Unix, ...
    (comp.lang.cobol)