What I’ve been doing
Firstly, I need to make some corrections to my last post about the new Micropendous line of boards: the Micropendous4 board has 128KB of external SRAM, not 64KB as I stated previously, and Matt assures me that it can be disabled to a tri-stated state via PE6. Very slick, and I doubt people will begrudge the potential loss of one pin for so much added functionality.
Now, on to what’s been keeping me busy. Anyone who has been keeping track of my recent SVN commits and email/mailing list activities will notice that there hasn’t been much, well, activity. For this I apologise, but I’ve been keeping busy with my University studies; with exams looming and all my assignments due, I haven’t had much time or motivation to do any personal projects. That will all change on the 20th of November, when I once again become a free man until the next semester begins – I’ll be working heavily on LUFA once again, to be sure.
Over the last few weeks I’ve been working on many assignments in many computer languages simultaneously – a pair of DES and OSS assignments in Java, a semester-long PRG project in Managed .NET C++, plus LUFA with it’s good ol’ plain C. It’s been a real eye-opener into the world of “real” programming; switching languages to fit the problem domain is a skill I definitely will be needing in the coming years. I’ve definitely got more perspective on the old adge of “right tools for the right job” — I wouldn’t try to write LUFA in C++ for the AVRs (although I’ve added C++ compatibility!) and I wouldn’t try to write our programming project in C.
The programming project (especially) has been a right heart-ache, simply because the Managed .NET C++ language simply isn’t any good. At all. While I’ve had some VB.NET experience previously, and I’ve played around in C++ in a limited way, our lecturer’s decision to force everyone into the absolute abomination that is C++ CLI is mind-bending — the University doesn’t even offer proper courses on it, and we were expected to pick it up as we went along. No trouble for my friend Alan and I, although I won’t lie and say it was a pick nick from start to finish.
From working with it for more than a few minutes, you get the feeling that the whole language was an afterthought, a second (or even third) class citizen in the .NET framework, added simply to appease the old-fogeys that haven’t migrated to C#, a language I want to try my hand at next. Everything from the designer (event handler code goes in the header, so you get multiple definition errors! Can’t have two forms include one another! Designer puts a billion access specifiers all through the header file!) to the language itself screams “bolted on”, or more appropriately “jammed onto”.
Admittedly, lots of our troubles have been with the framework itself. Most of the controls aren’t double buffered, although the framework supports it – meaning trying to do any custom drawing and animation – always a loosing prospect under WinForms – comes out jerky and flickery. Of course, they all come with a handy “DoubleBuffered” property, except that the property won’t work on controls like panels, as it has the wrong access modifiers. There’s two solutions to it — either subclass it and set the double buffering mode in the constructor (yuck), or use reflection to force the double buffering despite the private access (double yuck). We went for the former, as I can only imagine the tutor’s face if we turned in code using reflection for such evil.
The other bugs we have encountered were a right pain, ListViews especially. Even when not operating on them, they flicker like crazy when the mouse is moved over them, due to a bug in the low level Windows Message handler (WndProc) routine. The solution is to subclass it like the faulty panels, and both enable double buffering in the constructor and override the WndProc routine to filter out spurious background clearing messages. We also had the problem of there being no scroll event at all for the ListView control, so we needed to implement our own via WndProc once again. The Managed C++ language from Microsoft has undergone such radical changes in the last few years that almost all tutorials and snippets are horribly out of date, so we ended up having to figure out how to do managed CLI events ourselves.
Finally, I encountered one more bit of framework strangeness, in the reflection routines. I had the idea of making our program’s configuration screen use a PropertyGrid control for editing of the live classes, as it contains all the needed functionality and bindings needed to edit any type of data you could ever hope for. With the addition of some metadata attributes on our class members, we had quite a nice configuration screen up and running – except that editing our generic list of String instances was failing when the user tries to add a new item to the collection.
Lots of Googling later, and I discovered it was due to the default collection editor used by the PropertyGrid control only works on collections of items which have a default constructor, which the String class lacks (it requires the string contents in the constructor). The only solutions we found were to either subclass String and supply a default constructor (seriously), make our own String collection editor dialog with all the testing and development that goes along with it, or use the inbuilt string collection editor inside the framework which Microsoft has hidden. Really. That post isn’t kidding – you really do need to supply the private security token to be able to get access to the hidden class within the framework. Again, this is an awful hack, but we documented it, and pushed it into a dark corner of our code hoping the tutor won’t see it when he or she reviews our project.
All in all, a frustrating semester long project, where much of our time was spent fighting the awful language, instead of writing productive code. And that’s why the next LUFA release will be either a bit lack-luster (minor changes only), or delayed. Sorry to all in advance.
