If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: All this rhetoric is a little perplexing...

> Fortunately, the CLR supports both types of transitions,
> allowing both managed and native DLLs to coexist in a
> single process and call from one DLL to another independent
> of whether or not they are hosted inside the CLR

Paulo: That's the approach I and others have been recommending for the past
year: compile your existing VB6 code into ActiveX DLLs and call it from your
new .NET apps. Or, create new functionality in .NET, and call it from your
existing VB6 apps via COM interop. That's what Don Box is talking about in
the article you cited, but this solution is unacceptable to Dan, Karl and
others.
---
Phil Weber

Re: All this rhetoric is a little perplexing...

"Michael (michka) Kaplan" <former_mvp@nospam.trigeminal.spamless.com> wrote
in message news:3c62b9fd$3@10.1.10.29...
> "Bob" <no@spam.com> wrote...
>
> > Why in the world would I want to do that?
>
> You keep talking about how the conversion wixzard helps -- it does nothing
> for new code you write in VB.Net, obviously.

If you type Pascal, C++ or even old BASIC syntax into VB.NET who is to
blame?.
The conversion wizard or the milkman? <g>

Re: All this rhetoric is a little perplexing...

On Thu, 7 Feb 2002 20:55:22 -0000, "Paulo Costa" <pcosta@esagri.pt>
wrote:
>"Phil Weber" <pweber@nospam.fawcette.com> wrote:
> > ..., I think if someone were able to develop a 100% reliable VB.NET
>> preprocessor that could accept VB6 code and emit perfect VB.NET code at
>> compile-time, people like Dan would probably be a lot less unhappy.
>
>Phil,
>
>I'm one of the *people like Dan* that would be happy if they allowed us to
>make a smooth move, replacing gradually the existing code without such a
>break.

There are a bunch of us. Wait 'till the rest of the crew figures out
what's happened.
>In "Migrating Native Code to the .NET CLR", from the May 2001 issue of MSDN
>Magazine, Don Box wrote:
>
><QUOTE> ... Fortunately, the CLR supports both types of transitions,
>allowing both managed and native DLLs to coexist in a single process and
>call from one DLL to another independent of whether or not they are hosted
>inside the CLR.... <UNQUOTE>

I suppose some folks think I shoulda left it in 16bit DLL's when
that's where it was.

If you're going to move to a new platform, you move to a new platform.
Straddling two leaves you with the restrictions of both.

Example: Does somebody think there will be a Classic VB that will let
you make native 64bit DLL's? C/C++ yup. VB nope.
>Vb.Net could have been implemented without losing Language Compatibility
>with Vb6.

Yup. They sure missed the boat. I guess billions of lines of
application code don't mean much to .NET's success.

Re: All this rhetoric is a little perplexing...

On Thu, 7 Feb 2002 10:21:20 -0800, "Phil Weber"
<pweber@nospam.fawcette.com> wrote:
>That said, I think if someone were able to develop a 100% reliable VB.NET
>preprocessor that could accept VB6 code and emit perfect VB.NET code at
>compile-time, people like Dan would probably be a lot less unhappy.

That's a pretty tall order. Not people's happiness or the lack of it
(likely more of the latter now), but that any converter could be
relied upon to produce 100% reliable, nay, perfect VB.NET code from
VB6 code. How would you rely on it? You would need to run such
exhaustive checks that it would be 2020 before VB.NET could ever see
the light of day. The whole edifice underlying VB.NET is TOTALLY, and
I mean TOTALLY, different from VB6 or what VB6 runs on top of. There
is NOTHING under the hood that is even remotely the same. The entire
VB.NET model is a so-called "managed" system; you've got garbage
collection; there is no DF; memory is managed differently; the
compiler/IL stage is utterly dfifferent; the whole thing has to run
within the .NET framework.

With everything UNDER THE HOOD totally different, let alone the very
many differences inside the cabin, the changes we've heard about, any
converter would itself be a very, very major product in its own right.
And it would cost a fortune to produce something like that.

Because such a 100% converter is not going to be available and the
actual converter seems like it's just being provided so that they can
say they're providing one, I have to say that I believe Microsoft's
original brief was that classic VB programmers would have three
choices: Rewrite in VB.NET; Rewrite in C#; Or bugger off.

Re: All this rhetoric is a little perplexing...

On Thu, 7 Feb 2002 13:35:57 -0800, "Phil Weber"
<pweber@nospam.fawcette.com> wrote:
>Paulo: That's the approach I and others have been recommending for the past
>year: compile your existing VB6 code into ActiveX DLLs and call it from your
>new .NET apps. Or, create new functionality in .NET, and call it from your
>existing VB6 apps via COM interop. That's what Don Box is talking about in
>the article you cited, but this solution is unacceptable to Dan, Karl and
>others.

Hardly surprising. What you're saying sounds far too vague and
simplistic. What about existing VB6 code that interacts with forms?
Suppose an app has dozens of forms, how would it work? As for calling
..NET functionality from a VB6 app, why on earth would ANYone need to
do that? Anything I want to do (and a lot more besides) I can do in
VB6 with the aid of API calls and third-party controls already! Why
would I *want* to complicate matters by introducing a complete
unknown, namely .NET, into the equation?

What it finally, ultimately comes down to is this: Microsoft blew it.
No, wait! They blew it, sure, in the lack of compatibility stuff, the
changes, etc. But more importantly they blew it because their
fundamental idea of how an average VB programmers would react was
wrong. I reckon they thought that 95% at least of ALL VB
programmers/users/non-programmers/etc would welcome VB.NET with all
the enthusiasm of a horny football player on prom night. They DID NOT
EXPECT to have to deal with anything more than a very minor grumble or
two.

I am as certain as can be that if they could turn the clock back now,
they would NOT produce VB.NET as it exists today. I believe that even
if VB.NET still was to work within the .NET framwork, they would have
ensured much more backward compatibilty, edit & continue WOULD NOT
have been DIScontinued, intellisense and autocomplete WOULD work in
the same way it does already and in exactly the same windows under
exactly the same conditions. I think they've realised by now that they
did blow it; but it's too late to do anything about it because the
whole .NET paradigm is kind of self-referential. It is all part of a
whole, and the whole is a sum of its parts. They cannot admit to
anything, because that would deny everything. Possibly, after the
official release, they will be in a better position to row back on
some things. I remember reading some comments a few weeks ago in these
ngs that they could be planning some kind of simplified version of
VB.NET. Perhaps this will happen, but it still won't be VB6.

Re: All this rhetoric is a little perplexing...

On Thu, 7 Feb 2002 07:01:19 -0800, "Michael \(michka\) Kaplan"
<former_mvp@nospam.trigeminal.spamless.com> wrote:
>"Bob" <no@spam.com> wrote...
>
>> Does the conversion utility handle this problem?
>
>No, because you cannot run a utility on your mind that tells you how to do
>something that you used to know how to do. Only time can give you that.

That's if you can overcome the feelings of rage, frustration and
betrayal, while learning the new language, continuing to support the
superseded language, and still find enough time to buy the razor
blades.

What about them? You're betraying your own ignorance...you can have forms in
VB Dlls, you know.. I have one system in MS Access which happily
instantiates VB dlls which contain forms.
Is there some problem I'm supposed to be aware of? heck..the VB Wizard
dialog add-in creates a DLL with forms in it, so what is the problem (beside
COM Interop overhead, that is)...

As for calling
> .NET functionality from a VB6 app, why on earth would ANYone need to
> do that? Anything I want to do (and a lot more besides) I can do in
> VB6 with the aid of API calls and third-party controls already! Why
> would I *want* to complicate matters by introducing a complete
> unknown, namely .NET, into the equation?

<Sigh> Mike...you _really_ owe it to yourself (and all of us) to play with
DotNet a little first before you make statements like that. A lot of
previously arcane API calls etc are SIMPLIFIED vastly because they're just
part of the framework now.

You know I'm not a zealot on DotNet...but geesh...you're not speaking from
such a position of weakness here (in terms of your knowledge of DotNet) that
I can't help butting into (this) rant...

Re: All this rhetoric is a little perplexing...

"John Butler" <nospamjrbutler@btinternet.com> wrote in message
news:3c632e8a$1@10.1.10.29...
....you're not speaking from such a position of weakness here (in terms of
your knowledge of DotNet) that> I can't help butting into (this) rant...

Re: All this rhetoric is a little perplexing...

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:3c632d1d.4717276@news.devx.com...
> That's if you can overcome the feelings of rage, frustration and
> betrayal, while learning the new language, continuing to support the
> superseded language, and still find enough time to buy the razor
> blades.

Hmmmm

I've gotten over the rage, am learning the "new" language and still writing
VB6 code every day...

Re: All this rhetoric is a little perplexing...

Hi Paulo --
> You gave me a great idea, no registry or big runtimes!! That's what I was
> asking for. Have you tested it? I'm going to do.

Tested what? I routinely use VB3 to write AutoRun apps, yeah. Simple as could be.
Just put the runtime in the same directory as the EXE.

Later... Karl
--
[Microsoft Basic: 1976-2001, RIP]

"Paulo Costa" <pcosta@esagri.pt> wrote in message news:3c625a5a@10.1.10.29...
> Karl,
>
> > Yep! In Fact, VB3 is *still* the most straight-forward way to build a CD
> AutoRun
> > app. (Try that with VFred.) It's actually a little amusing, now that I
> think about
> > it -- just picture all those flashy new .NOT apps being distributed with
> VBRUN300.DLL
> > on the same CD! <LOL>
>
> You gave me a great idea, no registry or big runtimes!! That's what I was
> asking for. Have you tested it? I'm going to do.
>
> Paulo Costa
> ----------
> Vb.Net could have been implemented without losing Language Compatibility
> with Vb6.
>
>
>
>

Re: All this rhetoric is a little perplexing...

Hi Phil --
> > Fortunately, the CLR supports both types of transitions,
> > allowing both managed and native DLLs to coexist in a
> > single process and call from one DLL to another independent
> > of whether or not they are hosted inside the CLR
>
> Paulo: That's the approach I and others have been recommending for the past
> year: compile your existing VB6 code into ActiveX DLLs and call it from your
> new .NET apps. Or, create new functionality in .NET, and call it from your
> existing VB6 apps via COM interop. That's what Don Box is talking about in
> the article you cited, but this solution is unacceptable to Dan, Karl and
> others.

Since you feel qualified to speak on my behalf, I'd appreciate that you at least not
make *too* sweeping of generalizations. Were that the only issue, it's likely
something I could live with. Rather, the issues I'm concerned about are what brings
this situation to the fore, not the situation itself. I'm *stunned* that identical
code can produce two different results and they call it a single language. Anyway,
your simplification is pretty gross, and certainly I'd expect more from you.

Re: All this rhetoric is a little perplexing...

Hi Bob --

Why don't you get back to us after you've run a couple simple little samples through
that so-called "conversion" wizard. Here's a few:http://www.mvps.org/vb/samples.htm -- Microsoft couldn't convert *any* of them using
the wizard. Can you?

Thanks... Karl
--
[Microsoft Basic: 1976-2001, RIP]

"Bob" <no@spam.com> wrote in message news:MPG.16cc518425d269c2989684@news.devx.com...
> In article <c7k36u8unk2v4b4b9mjbklf8bm7stbu3f6@4ax.com>, Dan@MVPs.org says...
> > Bob,
> >
> > The issue here isn't whether I can write code that works. Rest
> > assured that I can.
> >
> > The issue is whether code I've *already* written and tested will work.
> >
> > Having said that (yes Phil, there is a reason I'm not clipping this),
> > READ through the mental exercise you just went through for a simple
> > multiplication exercise.
> >
> > Now think of every place a "changed" syntax feature may be used in a
> > large application. Get it now??
> >
> > Dan
> >
> Does the conversion utility handle this problem?
>
> Bob

Re: All this rhetoric is a little perplexing...

Phil,
> That said, I think if someone were able to develop a 100% reliable VB.NET
> preprocessor that could accept VB6 code and emit perfect VB.NET code at
> compile-time, people like Dan would probably be a lot less unhappy.

I'd vote for that. I don't even insist on a 100% conversion, I would be
happy though with at least 95%.

Re: All this rhetoric is a little perplexing...

Now, I'm not trying to defend the wizard (since I've been saying all along
it'll be the butt of many a joke anyway), but let's consider a few things
as well:

First of all, a large part of those samples are using techniques not native
to core BASIC. A large number of them use undocumented functions. While I
personally think the samples are all cool, since I practically made a career
of writing tricky code in old VB, I think it's fair to assume that a conversion
wizard would have trouble with that code due to its very nature.

Secondly, this does nothing to address the issue that some of the code isn't
even needed, so why bother converting. For example, your translucent sample
(which again, is pretty cool), which is wrapped up in 10 kb of code in a
sample with 14 files, can be accomplished simply with one form and setting
the Opacity property to a percentage, or Transparency property to a color.

Again, this isn't meant to get the wizard off the hook. I think the ideal
is to have 100% usable code. However, it's the extreme approach of implying
that all conversion is going to be the worst **** that i have a problem with.
Rather, I'd like to discuss what are really going to be the real issues,
and help people get around them - after all, VB.NET is released, there's
no use crying over spilled milk. At the same time, I'd like to encourage
people to assess the *real* effort involved with converting their code, since
it will be relatively simple for some, and relatively painful for others,
*depending on their code* - rather than just implying it all sucks.