VB.NET or .NET is NOT BILL GATES BASIC. It is a new language, very C like, to the extent that the young kids ask why not C# instead? It tries to con you by using VB like commands like LEFT() but it is a different horse. It does think like VBA or VB6, you are advised to move on to new command equivalents and so on. It is not an end in itself, it is a scripting language to control that monster .NET framework from hell. I am migrating from .NET 1.1 to .NET 3.5 and the new tech is again one level different.

Coming back to the Office dilemma – Office is an intewoven bunch of COM / ActiveX objects. It is not built on .NET. They don’t know how to build a blow by blow equivalent in .NET. They either lost their documentation or never wrote it. Over the years, COM based Office has been extended and extended and extended. Some team has to re-engineer the beast in .NET. But at what cost, resource and time handicap? Is it suitable use of $$$ and resources to re-engineer a new Office in .NET which only just makes it the same feature equivalent? Like Office 95/Win95 was compared to Office 4.3/Win16. No – if you look at Office 2007 – there are a raft of feature enhancements including the Ribbon, Quick Parts in Word, Smart Tables in Excel, New Masters and Layouts and in Powerpoint, a whole new SmartShapes, Smart Charts shared module – they have again extended Office/COM instead of re-engineering it as Office/.NET.

And as long as you have Office/COM, VBA is sweet. It is not a programmers language, it is a business man’s language. It has superb interactive yet simple IDE and debugging. It has the minimum of conversion by Datatype Casting or esoteric PASS BY VALUE vs PASS BY REFERENCE concepts. Sure you can cobble on .NET in VSTO and satisfy the young hands who dream in C# or Java and feel they need a object oriented, leading edge language, but so far VSTO etc.. are EXTERNAL to Office, not built in. Can it be clothed to look as internal as VBA and stored inside the compound document object? Maybe, if the document is XML based.

VBA is the upper hand Microsoft Office has over Star Office and Open Office. Essentially, a team of good programmers can make Open Office blow for blow equivalent to Microsoft Office, one version delayed. No big deal. But Open Office cannot equate to VBA because VBA is proprietary. They have a team translating VBA to some kludge of Open Office languages – a crude Basic, a Java like script etc… but it’s not 100% or even 50% VBA.

VBA is the reason why people use Excel. Take it away and there is no need to use Excel. You could use Open Office Calc. Or Google Calc.

Using VSTO with MS Office 2003 UI

?VSTO is a new MS office developer tool by which we can upgrade old VBA based MS Office documents to .NET based managed code application. This provides complete functionality to implement managed code advantages and use of any .NET languages like C# instead of only VBA in macro modules. This approach provides an incredibly rich set of libraries and functions for managing the user interface, communicating across the network, publishing and consuming XML Web Services, accessing the file system and relational databases, security and more.
?Using VSTO one can develop UI using MS Office as front end. In this case VSTO code acts as code behind to Office Documents and templates.
?Using VSTO one can add custom Action pane, Add-In menu or Windows form having Menu strip.

Using VSTO with Windows forms UI

?We can add VSTO class library in Widows form application. Using this approach we can use MS office (Word / Excel) as reporting tool without client side office installation requirement. But we can not use office as OLE object in VS 2005 forms to provide in-place editing with Word or Excel document. This is because MS Office is one MDI Application and windows form architecture does not support to make any other MDI UI to become its child form. In Visual Studio 2005 (Whidbey) there was one control named ActiveDocumentHost control which was aimed to act like OLE control but due unknown reason Microsoft did not include this control in final release of Visual Studio 2005.
?Currently we can open office document in Windows form using Microsoft explorer control but this has many limitations like we can not edit office document as it is read only at run time. We can not use any MS Office API or VSTO library function to perform activities like insert table, delete text or bookmark.
?We can add windows form in VSTO application (as a part of office document which can also act like data entry form for edited region) but we can not add Office as part of windows form
?If we use MS explorer to view office document then for every new event performed by windows forms events on office document like inserting a table, deleting selected text one has to recreate word documents on the fly and reload in explorer.

The .net language structure is developed to support full object orientation which leads to more understandable designs and code on larger projects, rather than just to add new functionality.

In terms of when .net will be the ‘norm’, I would think around the time that most potential customers have the .net runtimes already installed, and a compatible version of Office. Stephen suggests tail end of 2007, which sounds reasonable, I certainly can’t see it before. Unless Windows XP sp3 installs the runtimes to make deployment straightforward (and Office 12 take up is much quicker than recent versions).

I think there is plenty of life still in VBA for anyone considering a career move. If you are worried about change, and redundant skills, don’t go into (business) software development.

2Gb RAM is about right for VPC too
cheers
Simon

I disagree, for the majority of the users it will be a blessing in disguise. So much functionality has been hidden from the user far too long. Not deliberately, but simply because the menu structure is far too complicated. Even I have to search menus when I need a specific feature in e.g. Word (which is not my area of expertise, but I use quite extensively). And remember: I often know some functionality is there and sometimes still have a hard time finding things. If you don’t know its there, things will be even harder to find!

Dennis: 2 GB Ram? hmm. I have 512 MB. Time for an upgrade I guess .

Doh!!!

I meant 8-byte (64-bit) integer (without using currency type).

You don’t need to completely re-structure a language to add funtionality

M

Kind regards,
Dennis

Many of the forced changes in VB.net for instance were unnecessary for progress. Others represent truly enhanced functionality. There is a difference.

>Customers can choose which technology works best
>for them, which seems pretty good to me.
Yes, indeed, choose.
To get a new licenced copy of VB6 were had the right to choose to switch to VB.net or go to ebay. Microsoft did not “allow” the old product to compete for long. They did allow the “downgrade route”.

The irony of the “illusion of progress” paragigm is than in my field, numerical analysis, most code in use today is still written in either Fortran or ports of that Fortran to C. It works today as well as it did when it was originly written 25-y ago and gives correct results (unlike my spelling).

Don’t get me wrong: I love Excel. I want Excel to expand (particularly in a positive direction: 1) more rows and colums is good. 2) 16-bit integer and double-double precision floats would be great. OTOH changing the design and arrangement of buttons is pap.

M

Virtual PC is great isn’t it?

I maintain an application written in an older version of Oracle Forms… occasionally.
The installation of Oracle Forms is straightforward, if you don’t already have a later version installed. If you mix newer and older versions it can give you headaches – kind of like mixing versions of Excel I guess (not that I’ve ever done that).

Not long ago I discovered Virtual PC, and all my install problems were over.
I dont have to worry about my new version clashing with the old. I just keep the old version in a Virtual PC.

I’ve been very impressed with the features, screen resizing, performance, drive mappings, networking.

Again, it’s great!