OK. It had to happen. Things have been cruising pretty well with .Net. My little experimental application is almost finished. Basically the idea was to do as many of the things I’d need to have to do in MixAction at a very elementary scale. Something more interesting and satisfying than fifty thousand sample projects trying out “stuff”.
I’ll post some screen shots of that next week. Any similarity to the MixAction screenshots seen on this blog or the MixAction website are purely intentional. 
Note though that this isn’t theatrical software. I’m not even sure if I’ll market it or not, but it’s certainly been very rewarding.
So – what was it that had to happen?
Data access. MixAction under Delphi uses a custom database format descended in the true spirit of the Delphi TDataset. This is one of the most powerful features of Delphi and the main reason I have stuck with Delphi for so long.
However, that’s not going to work so well under .Net unless I perform some really weird magic that I simply don’t want to get into right now. I have enough to do.
OK. That means ADO.Net. I figured – “How hard could it be?”
As it turns out it’s a piece of cake once you grasp it, which took me admittedly two days work, I’m ashamed to say, and experimentation.
One of the nice things under .Net is persistent application settings. Everything saved to a nice XML file. User preferences, application settings and so on. However the connection string for ADO.Net when saved using this method is read-only. Go figure.
I searched high and low for solutions for this and most of them were kludges, many were broken in VisualStudio 2008 and all of them were convoluted.
I did not want data access to be convoluted!
Here be dragons!
Repeatedly I saw VB6 programmers telling the .Net noobs to do it much inline with how things are done via good old VB6.
OK. Bloody useless to me. The last thing I wanted to do in 2008 was hand code field access to visual interface elements when I had perfectly good binding support under ADO.Net. Been there, done that – circa 1986-1995 under, gulp, DOS.
Nor did I want to grab the XML file and update during program initialization, experiments here were interesting but fallible.
One option I saw was to virtualize the connection string and trick the settings, but that to was anything but robust.
Finally, doing a manual edit of the connection string in the IDE meant every change to the configuration of the application saw the settings over written.
As it turns out the secret to using application settings for a connection string to a database, for my purposes (given this is a desktop implementation), short of forcing the installer to write the XML update at install time, is simply not to use it and hard code – using variables and not physical paths of course, the connection string at app startup.
Simple. Works fine it seems. In fact it’s working 100%.
So the next job is to locate a descent database file format for MixAction to use that works with ADO.Net. I’m not wrapped in SQLite, some of the .Net implementations I’ve played with seem to have memory leaks – quite an achievement as SQLite is pretty robust. Access is out for MixAction, it’s a tad too vague in terms of reliability and SQL Server, even the light edition, is rather large.
So I’ll keep looking for that, in the meantime I’ll add data access to this little application for the experience. After that I’m pleased to say I’ll be ready to fully implement MixAction again. Certainly looking forward to it, the beta testers are getting itchy!
Scott Kane
18 Comments
One Trackback