🚀 go-pugleaf

James--

re: "Many objects show up as a generic Object when they should be a specific object."

That's probably because they *aren't* a specific type. Take Paragraph.AppliedParagraphStyle, for example--in some ways, you'd think that that could only be a ParagraphStyle object. But it can also be a string that is the name of a paragraph style in the document. For most forms of VB, this adds flexibility--you can simply use the name of the style, rather than having to acquire an object reference to the style.

re: "Furthermore VB.Net requires, as Ole says, several additional files to support the EXE. If they had a native mode where all the support libraries can be included in the EXE like C++ it would be a different story. All the marshaling of variables and just in time compiling has not made an improvement that I can see. Programs run very slow and there are more run time errors and fewer compile errors."

I have to say that I do not like the changes in VB in the .NET version. In trying to make VB more of a "real" programming language, they have harmed it as a scripting language. To me, this is pointless--if I want to use a "real" programming language, I'll use C++. I had thought that Microsoft was showing us the future with VBScript--where everything is a Variant. Doing away with Variant in .NET is a big step backward.

Speed is the other thing--a rule of thumb is that VB.NET programs run at about half the speed of their VB6 counterparts--even after optimization for .NET.

I am very disappointed. I love VB, but I really don't like the direction Microsoft has taken with VB.NET.

re: "VBScripts are probably the way to go. Single stepping and examining variables is still available with the debugger."

What I advise people to do is to get VB5 CCE--it's a free download. Develop/debug with VB5 CCE, then copy the scripts to VBScript files for deployment.

Thanks,

Ole