Re: VB.NET 2008 not backward compatable?

"mayayana" <mayaXXyana@xxxxxxxxx> wrote in message
news:udXugktwJHA.5836@xxxxxxxxxxxxxxxxxxxxxxx
:) How would I rotate a control in 3D? I wouldn't,
so I'm not worried about the ability. VB does have
userControls, which are basically a blank window
with an hWnd, on which any sort of control can be
built.

As do .NET WinForms. WPF has control templates and styles which offer
infinite flexibility. Tell me, how easily can you completely override the
look and feel of a standard button control in VB6? How many API calls do
you have to make? It's all built in to WPF and all easy to take care of.

Perhaps you don't want a 3D rotating control. But maybe you want to display
multi-line, formatted text with images in a listview for example. A piece
of cake in WPF, a long hard slog with the API in VB6. Which reminds me,
screw up a message hook in your VB6 app and restart Visual Basic a couple of
dozen times. See how much fun that is...


As for speed, I don't know of any tests, but I can't
see how you could compare native code calling APIs
(VB) with JIT compiled code calling wrappers around
APIs (.Net).

I've done the tests, and I can tell you it is faster. Try string
concatenation in VB6 vs using the StringBuilder in .NET. Try custom drawing
your controls and see which performs better (using basic GDI+, not even
using WPF which will own VB6 without the need for a comparison test). This
all indicates to me that you're criticising it without having tried it
first, and you're making incorrect assumptions based on what you think you
know about JIT compiled code.


You may be thinking of VB as a tool
using variant data types and calling ActiveX controls
to do everything. As I explained earlier, that's only one
way to use VB. It's mainly the beginner's way.

Even doing it "right" in VB6 will still produce code that performs slower in
many scenarios. The only likely area it will beat a .NET app is cold
startup time.


As for DLLs, I don't know why you think there's a big
issue there. Maybe you've been reading .Net propaganda
about "DLL Hell".

Yeah, about 9 years ago when .NET was first being created, and the arguments
in this thread were actually valid. I don't think they bother with the
propaganda any longer.

That's a rather ironic opinion, given
that Windows is still COM-centric with negligible usage
of .Net. There's been a lot of bad press about COM, but
MS still uses it. And VB is well suited to it. I suspect that
the bad name mainly comes from C++ people who don't
find COM to be so user-friendly.

Irony is you saying that Windows is COM centric and then blaming COM's bad
name on C++ people. What do you think Windows is primarily written in, VB6?
COM was a good system in its day, but it got a bad name from developers for
its clunky installation process. VB6 was well suited to COM for a reason -
both (old) technologies were around at the same time.


Personally I don't use DLLs very much. If I
wanted to, VB can write a standard non-COM DLL. Also,
a COM DLL can be used without registering. I don't
mean reg-free on XP. I mean loading it directly. I'm
currently using a 20KB DLL written by Olaf Schmidt for
loading COM DLLs. It works beautifully. I'm using a COM
DLL to store program settings in an orderly way. I don't
need to register that DLL.

None of which was native to VB6. You're having to use hacks and 3rd party
DLLs to achieve things that .NET coders can do as a matter of course in
their sleep.

Like I've said to others on this thread, if you want to keep using VB6 then
good for you. Just don't post incorrect BS on a public newsgroup about
technologies you evidently aren't using or trying, whilst simultaneously
trying to promote an old dead language like VB6.


.

Quantcast