Trying to identify all the members in a class, i can use CodeElement.Kind and build a large case statement against vsCMCodeElement.. But once I hit vsCMElement.vsCMElementEvent I hit a dead end. All the others have CodeBlah interfaces I can use to get .Access from, but there is no CodeEvent.
Digging around the net for a while i found the Microsoft.VisualStudio.VCCodeModel namespace, which has VCCodeEvent which in turn doesn't have an .Access member. And anyhow how does this sucker relate?
It would be nice if there was a reference from the vsCMCodeElement enum to the appropriate CodeElement interface.
And while we're wishing, how about a C# to EnvDTE reference. Oh, well, more experimenting to come
Lately I've been trying to do a lot more design before sitting down and cranking out code, thinking that it would cut down on some of the iterative revisioning I see being the staple of programming. But how to do that design without having to do it all over again once the coding starts.
UML is cool and all, but I find it better for explaining things to others, after the design has progressed, than for designing objects. It also doesn't let me express C# syntax properly and I still have to transcribe everything by hand into the IDE later on and the link between the two is lost.
I could write out the object design as text, describing inheritance, members, etc. That usually works best for me, but then I still have got to transcribe it into the IDE and again the link between design and implementation is lost.
I briefly played with code generation, creating an XML schema to define the classes, then generating code from that. Still suffers from the design/implementation disconnect. As soon as the generation is done, and i fill in the code, they diverge. I considered writing the Code Generator to be able to parse the code back in, update the XML and then be able to generate any changed code from that.
I think I've stumbled across a better approach though. Integrating straight into VS.NET and using the CodeModel that the IDE builds on the source files, to alter and design classes. Everything stays in the native code format, but i can still tweak it without touching code.
My current design goal is an Add-in that mimics the Object Browser, but allows you to alter the classes on the fly, as well as add new classes, members, etc. Then build onto it a way to create "code templates" so that you can autogenerate more than just method stubs, such as creating fields with accessors. Eventually you have a Class Editor with a plug-in system for code generation templates. If i then add a way to annotate the design, probably by extending the XML doc format already in there, i have a nice system for keeping design and implementation together.
So far, my add-in can mimic the Object pane of the Object Browser. Tonight I hope to add the Member pane functionality, then comes Adding new classes/members.
I figured I might as well blog this, since otherwise, i'll just loose the information I've come across. Simply this exists to write down useful or cool things I come across coding.
The impetus right now is on documenting my forays into EnvDTE in Visual Studio .NET 2003. EnvDTE is the namespace containing all the IDE automation classes, which I must say so far proves to be the worst documented portion of anything .NET related. I mean the MSDN docs are not even in the same format as the rest of the MSDN docs, the only examples in those docs are sparse at best and in VB.. Did I mention, I'm tackling this from the C# end.
Well, I made some headway so far and it's amazingly powerful stuff in there, but it's certainly a form of black magic. Nobody said it'd be easy.
Back in the day (read: 1991ish) I thought that programming GUIs must have at least as sophisticated an interface as the GUIs themselves. Shortly thereafter I got to spend a day with a color Next Slab. That short exposure to the Next Interface Builder seemed to prove that supposition.
Sure, it was only a couple of hours, and really, I wasn't in the drivers side of the demonstration, but watching a word processor being built in an hour or two with lots of visual drag and drop was amazing. And this wasn't just a Form editor, but you actually visually connected visual components to code components. Cool stuff. Unfortunately, NeXT didn't make it (ok, a good bit of NeXT tech is in Mac OS X). Nonetheless, an expectation was set.
So I tried my hand at MPW (Macintosh Programmers Workshop) under Mac OS 7.1. Ugh. Not what i'd call elegant. And visual? No chance. I tried ThinkC.. A little easier to understand, but still all sorts of calls to toolkits originally written in Pascal, and nothing visual about that development.
Then came the new kid in Mac Development, Metrowerks. In its Codewarrior development suite there was a tool called Powerplant. It helped build the interface and create code stubs to fill in. It was ok at the time, and in many ways, it's what's now standard in most form builders. But still, it seemed like a lot of typing to do something inherently visual
Still pining for NeXT, i became a BeBox developer as soon as it became available for sale. I was full of that kool-aid drinking enthusiasm that comes naturally to any Mac Geek. Everything about BeBox screamed "technically superior". The community was full of people whose hopes and dreams were used to being crushed: Mac Developers, NeXT developers, Amiga programmers. I even saw a guy with a Taligent Pink T-shirt at the developer conference.
The one thing that didn't enter my mind when thinking BeBox was "immature technology". And it was. Very cool, with much potential, but the OS was still being written as people started doing development of application. Lots of things changed rather radically under the hood. The edition of Codewarrior that came with it didn't even have Powerplant. There were stories about and Interface Builder coming, but when it came it wasn't revolutionary in any sense of the word.
Long story short: Development under BeOS was no more advanced than any other OS and I moved on from the platform after realizing that it wasn't going to make it, especially when Apple didn't buy BeOS and bought NeXT instead.
Last couple of years I've spent most of my time working on the server side, saying "Bah!" to non-browser GUIs.
Now I'm back in GUI land, this time with C# under Visual Studio .NET and, all things considered, it is probably one of the best out there. Even if it is only incrementally more advanced than other suites for GUI development I've worked with. It's fun (even lacking Emacs mode) and quite productive.
But I still think that the potential of Visual Programming has not even had it's surface scratched. Ho hum.