I’d like a copy of that please. dkusleika@gmail.com

Development isn’t mentioned in my job description, but I’ve written and maintain 5 applications with about 100 users in 12 field offices across the US. I’ve provided more written documentation for 3 of them than the company’s IT department has provided for most of the in-house systems currently widely used. These 5 applications are either entirely Excel-based or Excel as a front-end for character mode programs.

Maybe seeing sample code would help me. The sample code I’ve seen from the Excel developers’ team blog has been uninspiring. Looks like 20 lines of C# code is needed to do what 1 line of well-considered perl or python could do. But I digress. Do any of you know of sites with sample code that could show how useful .Net is?

On a different tangent, how many 3rd party applications (i.e., applications developed by ISVs and sold to any interested parties, not just to clients who’ve retained the developer’s services) are written using .Net? Or is .Net essentially for in-house and specifically contracted development only?

Please feel free to e-mail me about it. But I believe that it’s a good strategy to use Excel/VBA instead of .NET in Your position.

Simon,
I can only represent myself and no other. So my point of view is from a business / developer perspective and nothing else.

Kind regards,
Dennis

Simon, working for a US nonprofit, we can get 6 very-low-cost MS products every 2 years, e.g, single licenses for server products or 50 licenses for Office, so I actually do have VS/MSDN at work. But as the sole part-time, on-site webmaster/user support guy/EUD, I don’t foresee having time to learn to use it for the kind of “somewhat quick and fairly clean” solutions I currently create with Excel/VBA.

How good .net may or may not be is truly irrelevant to the legions of EUDs. They will never get access or support to use it .

Or are you all saying that accountants and marketeers and other business pros get Visual Studio everywhere you go? Thats not what I see.

Yes, not really, yes, yes, with a clause, you could do with out them, but if there there you would want to use them.

Here is the killer thing with .Net - it’s very easy and it’s very quick. Last week I wrote a little video app to look at my golf swing, it tock about 2 hours to down load the direct x SKD then about an hour to write the code, amazing!

I love .Net!!!!!!

>>Could You elaborate with it? Do You refer to VSTO?
Dennis I tired to write a managed com addin, I used your guide, it was good, but I could not get it to install on any other PC, I think in is a issues the security access, I did find some code to help allow assess, but it’s fallen off the wagon at the mo - I’ll get back to it when I have the time!!

“I’ve found creating a DLL addin much more enjoyable in .Net than in VB. (On the other hand, actually getting it installed on other computers is very difficult so far.)”

Could You elaborate with it? Do You refer to VSTO?

Kind regards,
Dennis

The killer-feature about .NET though — in my opinion — is its strong-typing capabilities. In VB.NET it’s called ‘Option Strict’ and it’s every bit as important as using ‘Option Explicit’. If any programmer were to propose not using ‘Option Explicit’ they’d be drummed out of town… But proposing to do without ‘Option Strict’ is just as bad, honest. Once you have this, you will not want to go back.

That said, Excel was developed in a pre-’Option Explicit’ world, using a lot of Variant return types and the like. In VBA you lose IntelliSense when this happens; in .NET the compiler will complain and tell you to use an explicit cast. In this regard, .NET is safer, but is annoying until you get used to it.

I’m guessing that Microsoft is working on this, but in my opinion, the keys to making .NET a platform with no drawbacks with respect to VBA would be:

(1) Integrating .NET into Office as VBA is integrated today. I guess with InfoPath breaking the ice with VSTA, it’s probably on it’s way…

(2) As Stephen Bullen said, I think it definitely needs a macro recording capability that can record in VB.NET and C#. But I actually think that this would actually be a huge step forward. Part of the reason I think this is that I think it could be done even better: no more use of Range(”…”).Select, Selection.DoThis(), Selection.DoThat(), but could instead use dim range1 As Rng = Application.Selection, range1.DoThis(), range1.DoThat(). I’m guessing wildly here, but this is how I would do it. Once you have this, it would feel very comfortable.

(3) Excel needs a strong-typed object model. At one level it could simply be a wrapper for the existing object model, having strong typed results. For example, Applicaton.Worksheets(”…”) should have an ‘As Worksheet’ return type. Range.Cells(), and other methods also come to mind. Anywhere you lose IntelliSense in VBA is an even bigger hassle in .NET. (Esp. in VB.NET, which has a somewhat awkward casting syntax.)

Anyway, I think that .NET is just superb. There’s a big learning curve when using Excel, but the strict-typing environment is very important for larger projects. I still kick around VBA code from time to time, but now that I’m used to .NET, it’s really hard to go back…

Yes, I know some of you may be rolling your eyes, but as someone who has written many special purpose numerical programs all of which using standard (text) I/O, several graphical applications in spreadsheets (not just Excel) and a few with Python or Perl using Tk, I haven’t spent much time figuring out what .Net is beyond something vaguely like Java VMs.

Does it make accessing databases easier than using ADO? Does it speed arithmetic calculations? Does it eliminate memory allocation problems? Or does it just provide lots of controls I could easily live without?