Hermitworks Entertainment Blogs

I’ve got some code compiling right now so I thought this would be a good time to write another entry.

Today’s story starts last Thursday, when our hero (me) finally got fed up with trying to learn wxWidgets and decided to rewrite x42view as a Windows.Forms project. The first iteration of this was written in C++/CLI (because the rest of the libx42 project is written in C and C++ so interoperability was certainly a must) and let me just say I will never again use C++/CLI for a WinForms project.

The reasons for this declaration are many:

• The Forms Designer runs at barely half the speed it does in a C# project. This makes dragging controls around a major pain since you have to drag them very slowly.
• The Forms Designer spits out hideously formatted code.
  • Control variable declarations end up all over the place, each with its own private: in front of it. And by all over the place I mean something along the lines of very often in front of a public function.
  • Event handlers also get a private: in front of them - but then the designer can’t even be bothered to put the method body on the next line down and align it to a tab stop.
• The designer’s insistence that everything go into Form1.h makes for some incredibly messy code.

Now I realize that C++/CLI really isn’t intended as a GUI authoring tool and that the designer was probably just hacked in at the last minute and shipped the instant it squeaked through QA but some of these things bugs are just sad.

For example, C++ already has a powerful preprocessor built in. How hard would it be to have the designer make its mess in, say, Form1.Designer.h and to just #include that file after the opening curly brace in ref class Form1? Or better yet, right before the closing brace so you’d never have to worry about it changing the protection level on you.

And the event handler thing is a bit of a joke too, IMNSHO. I understand that not everyone uses *my* code formatting style and that it would have been a lot of work to build a sane auto-formatter for C++ and expose enough options to encode the most common conventions like the C# team has done. But I’ve also never seen a real C/C++ project where function bodies were indented three tabs and a space - all because they wrote the function in line with the private: keyword and felt they had to line the opening curly brace up with the return type declaration.

My last gripe, the everything in a header file issue, is probably related to some arcane compiler bug I haven’t noticed in my other C++/CLI projects yet - but I’d still like the option to have it put the methods into Form1.cpp file rather than in the header. Moving the function bodies by hand is annoying when there’s a perfectly good tool that could be doing it the way I want in the first place.

So in the end I got fed up with WinForms in C++/CLI and scrapped the original project. I ended up building a .NET wrapper around libx42 and then consuming that from a C# project and accomplished more in a few hours than I did in a day of trying to make the first one work nicely. This was probably a good thing since it’s forced me to put a clean interface on the wrapper classes (I can’t stand ugly interop-isms in C# code), which might make it useful in the future, or to someone else (if anyone else knows the libx42 project even exists, that is).