Good Article
http://www.fawcette.com/vsm/2005_05/magazine/departments/guestop/

Thanks for the link, I will share it.

Saga

Show quoteHide quote

Good?  It was more like KEP found a soapbox!

I was surprised to see a link to his petition was not included in the
article.  Perhaps it got the editor's chop?  Joel's article was an
interesting read, albeit a few years old.

LFS

Patrick begged. <g>

They returned to requiring registration to read entire articles!  What a letdown.
(Bugmenot says to use 'shar***@shareit.com' and 'shareit' to access their content,
btw.)

Now that's telling....


Yeah, it was that hidden content that really packed the punch of the article.
I wasn't in on the VB1-VB3 influx into busineses, but after all is said and
done, it does (on the surface) sound like a win-win-win situation.

I have to say 'on the surface' because I haven't given thought to all that
would be required to include VB.COM into VS.NET.  I would think it would
be a bit like mixing oil and water.  Have you given due thought on just how
integrated VB.COM should be positioned in VS.NET?  For example, does
VB supply its own debugger, or interface with the listeners, to provide output
in the debug window?  I just wonder if your plans advanced that far, or if
the request was made, expecting MSFT to fill in the gaps....

The final question being, would it be best to try to mix the two, or would
most objective observers agree they really should be shipped as two
different products?

LFS

More like mixing unmanaged C++ with .Net. "They've" been telling us all
along that VB uses the same compiler that C++ does so, sounds to me like the
"mix" would be no worse (or harder) than having C++ in the .Net IDE.

I can't imagine this "plug in" as being all that hard. Any compiler should
be able to "learn" VB. Heck... back in the 80's, when I was burning my own
eproms that contained "my flavor" of BASIC, I could've added a keyword
called "Frog" and have that format a hard-drive or print a page to a
printer. Words are words. As long as the compiler recognizes that a keyword
is supposed to generate a specific set of instructions, it shouldn't be hard
to get a compiler to recognize VB. Especially since MS has all of the pieces
already (and the original source).... and, if VB's capabilities are hard to
reproduce in .Net, then I'd consider that a huge step backwards for .Net.

Hi Larry --

So you'll sign the petition?  http://classicvb.org/petition

That's what you'd have to classify as implmentation details.  The point of using a
HLL is to avoid having to think of all that stuff, eh?

Possibly.  But that only speaks poorly of the new IDE, doesn't it?  I would think
Microsoft would *want* to do it, just to show how capable the system is.

Spending too much time on it is pounding sand, at this point.  What needs to happen
is for Microsoft to return to the table, and at that point implementation realities
(which only they truly comprehend) would need to be weighed.

I haven't, personally, studied VS.NET to a degree necessary to make such proposals
credibly.  That's not my job. <g>  I want to see support for Classic VB, the
language, move forward.  As do many, many others.

I'd be quite content with two products, personally, but I would suspect that to
result in quite negative results for Microsoft.  They'd be far better off combining
the two, I believe.

Later...   Karl

Accelerating Extraction of Bits From Text
Form
Folder loading problem.
VB 6 and MS-Word question
Quotation mark as string
How do you make child sub-commands visible in DataReport controls?
Package/Deployment Wizard
how to pass over events in stacked objects?
Releasing lock on MDB file after DataReport1 closes
One procedure for a textbox array?