We recently needed the ability to do most-recently-updated data caching in our Solution Family products.  Since the products use the OpenNETCF ORM Framework, it only made sense to update the framework itself to include events that fire whenever an Insert, Update or Delete occurs.  In fact I added Before and After versions for each. While I was at it, I also added a full complement of virtual On[Before|After][Insert|Update|Delete] methods to the DataStore base, allowing DataStore implementers to hook into the process as well.  I’m thinking I’ll use those at some point in the future to add some form of Trigger capabilities.

I'm trying my hand at making using some of our stuff a bit easier.  Today I burned some time trying to understand the project template infrastructure and the result was the creation of a couple VSIX files for installing IoC templates into Visual Studio. 

Right now it only supports desktop projects (IoC supports Windows Phone, Mono for Android, Monotouch and Compact Framework). I've also not figured out how to actually deploy the IoC and Extensions binaries with the templates, so when you create your project, the References section will contain IoC references, but they'll be broken.  Still, as a first cut it greatly simplifies setting up a new IoC UI (SmartClientApplication) or IoC Module project.

You can install the templates in one of three ways:

• Use the Extension Manager in Visual Studio (Tools -> Extension Manager ; Online Gallery ; search for 'OpenNetCF')
• Download them via the Web from the online Visual Studio Gallery
• Pull them from Source Controll over at the IoC Project on Codeplex

Ages ago I created an SDK that allows you to extract device CAB files and create a replacement for wceload if you wanted (we used this on a couple customer applications).  We also tried to sell it as an experiment in "value-based pricing".  Well the experiment showed, largely, that people would pay the minimum and very, very rarely come back and pay anything more so either it was of low value, or people are just cheap.

At any rate, I don't feel like maintaining it internally any longer so it has become yet another project that I've open sourced for the community at large.  The full download is now available over on Codeplex.

I just got an email in the Support inbox over at OpenNETCF asking about the libraries support (or really lack thereof) for Wireless Networking in Windows Embedded Compact 7 (rolls off the tongue, doesn’t it?).  While this is a question about a specific feature of the SDF, it really opens up the broader question of what our plans are for the future of the whole product.  In fact you could say it really opens up the question on what our general company plans and philosophy are.

First, let’s address this specific issue, as it deserves answering and has a little bit of a back story leading to a minor rant which is always fun. 

The SDF supports an object model for wireless networks that is based around the Wireless Zero Config (WZC) API.  Microsoft introduced WZC in CE 5.0 (IIRC) in an attempt to “standardize” the way the platform and apps would communicate with the wireless drivers, since NDIS doesn’t really have any specification for a lot of the wireless properties.  While I applaud the spirit, WZC is convoluted at best, and was definitely not designed to make the life of someone who has to use P/Invoke to communicate with it any easier.  Still, it was some sort of standardization so we rolled up our sleeves and created a managed interface for it. 

I’ll readily admit that what we ended with isn’t ideal, but I’m a fierce self critic and I rarely think what we do is as good as it could be.  Still it provided a programmatic interface for something that a *lot* of people wanted and that Microsoft had not implemented in managed code.

Well with Compact 7 (I’ll just call it CE7) Microsoft decided that WZC wasn’t the way to go, but instead Native WiFi was.  Painfully they didn’t follow a sensible “deprecated but supported” track for WZC and support side-by-side, they just dropped WZC support altogether.  That meant that we could not interface with a wireless adapter under CE7 using our existing code base at all – it was a flat-out break.

To make things worse, Microsoft went radio-silent for about 2 years (and still counting – yes I’m looking at you Redmond!) on what, if any, future the Compact Framework, or CE for that matter, might have.  The original WZC work was probably 4-6 weeks of development and it required that we buy several devices for testing.  Believe me, it was a real pain in the ass.  Do we (more specifically do *I*) really feel like doing that all again for the Native WiFi interfaces?  If I do, where do I get a CE7 device with WiFi support?  If I do all of that work, what’s the ROI if Microsoft kills the Compact Framework?  What’s the ROI if they revive it and implement Wireless themselves?

It’s really difficult to answer those questions, and we’re not the only ones who are wondering these things.  I can say, though, that we’ve very recently decided that yes, we will continue to do both support and new development for the SDF.  What that new development will entail I can’t say.  Not because it’s some big secret, but because I can’t make those plans until Microsoft tells us their plans (and they haven’t).  If they decide to release a new version of the Compact Framework, I’d like to not have a load of functionality duplication between it and the SDF.

So, is the SDF a dead product?  No.  We will continue to support it and have plans for feature additions.  We just don’t know exactly what those features will be or when they will be written (confidence inspiring, I know). 

Will we provide Wireless support for CE7?  If Microsoft does not, then yes, we will.  Again, we don’t know if they will or not.  If they did, we don’t know when that would be.  Ideally, though, programming for WZC and Native WiFi should be the same, so if they don’t do it, we’ll add support that looks and feels just like what’s in the SDF today.  If they do add it, I’d be inclined to update our object model to match theirs (keeping the old stuff for compatibility though).

Don’t read too much into this.  Yes, I’m optimistic about the Compact Framework and Windows CE Windows Embedded Compact but I’ve been using them for over a decade and I’ve based a whole lot of my knowledge, business and life on them.  I almost have to be optimistic.  But let’s face it, CE and the CF are still great tools for delivering products.  We’re still shipping products based on them.  Still doing new development and new installs.  Still writing proposals for them. 

Yes, we’ve tested the waters with Android and iOS.  We’ve even delivered finished products for them both, but using those tolls only reinforced my feelings about the strength and possibilities of the CF and CE and we’re still committed to using and supporting them.

I've been working in the Windows Embedded space for over a decade now, and I must say it's a far different picture today than it was in years past.  That's not a jaded nostalgia either - Windows Embedded used to have a real annual conference at nice venues in Las VEgas.  We has good speakers and great content.  The teams in Redmond shared loads of info about what was going on and what was coming down the pike.  Teams cared about what they were doing and what their customers wanted.

Slowly, though, it seems to have atrphied to the state that it's in today.  I know of no one using Compact 7 in an actual product.  The Compact Framework hasn't had an update in something like 4 years and there is absolutely no word at all what its future might be.  The tools required to do development for non Windows Phone devices are no longer available unless you purchase a full (expensive) MSDN subscription.  I can usually count the number of questions that get asked in public forums and places like Stack Overflow in a week on two hands - sometimes just one.

Today I got what had to be one of the most telling things I've seen though.  A sign that the people is Redmond just don't care any longer either.  For years, Microsoft has sent out a monthly embedded newsletter - the Windows Embedded InfoBlast - and while the quality of the contents has been in the same slow decline as the rest of the industry, the one I received today just pegged the "I no longer give a shit" meter.  This is exactly how it looks in Outlook for me:

Obviously either no one cared enough to even look at that before it went out, or if the did they didn't care if anyone actually read it.  Looking at it is like looking into the sun, but without the benefit of the warmth on your face.

In my push to get our fundamental libraries up and working on Mono for Android we've added support for OpenNETCF Extensions and OpenNETCF IoC.  What that means is that now you can have a common code for a lot of application infrastructure that works on the Compact Framework, the desktop, Windows Phone, MonoTouch for iOS and Mono for Android.  So you can now create a single, common code base for your applications that includes data access, event aggregation, dependency injection and inversion of control.

Get the latest code over on Codeplex.

We've started doing work creating client applications for a few of our products to run on Android and iOS devices.  Since I'm a huge fan of code re-use, I took the time this week to port the OpenNETCF.ORM over to Xamarin's Mono for Android using a SQLite backing store implementation.  The biggest challenge was that SQLite doesn't support TableDirect not ResultSets, so it took a bit of code to get running.  Still, it took only a day and a half to get what I feel is pretty good support up and running.  I've not yet tested it through all of the possible permutations of queries, etc, but basic, single-table CRUD operations all test out fine.

So now a single code base can work on the Windows Desktop, Windows CE and Android (probably iOS and Windows Phone as well with very little work). If you're doing MonoDroid work, give it a try.

Occasionally I'm surprised at how old software never seems to really die off.  Take for example an old port I did of the zlib compression library to Windows CE.  Back in probably '05 I built the original sources for the Windows CE platform.  In '07 I created a managed wrapper for the library and some samples on how to use that library.  I put it on the web and then pretty much forgot about it.

Well when we migrated our web site to a new server, some old links died and this just happened to be one of them (if you know of others, please let me know) and today I got an email from someone asking if I still had the code.  Sure, it wasn't the day things went down, but it still means not only was someone looking for it, the cared enough to email me and ask.

For those looking for it, it's got a new, hoipefully more permanent home on Codeplex:  http://zlibce.codeplex.com

Lately it seems that I’m been doing a lot of posts referring to “a customer”.  Often they are different customers, but it really sounds impersonal, so in this one I’m going to name names and point fingers – in a friendly way, of course.

Last week Nicolas emailed me to get some advice on the Visual Studio 2008 Forms designer and the Compact Framework.  Specifically he wanted to know if it’s possible to get a custom TabControl to be designable.  My assumption is that either he’s inheriting from the stock version or they’ve created a fully custom control inheriting from ContainerControl – I didn’t ask because in either case the answer is simple: it’s not going to work in the designer.

I told him that it won’t work, but in retrospect I feel I’ve short-changed him a bit.  As a developer, I like to hear a bit more than an “abandon all hope, ye who sail here for there be sea monsters” kind of response.  Why doesn’t it work?  More importantly, what are my options for a workaround?

In this case it’s interesting to note that even if he could get the designer to work for this control, I’d recommend that he not do it.  And they why to that recommendation is far more interesting.

So, Nicolas, here’s the longer answer to your question.

First, you have to understand that the Studio Designer is very, very brittle.  Any little quirkiness tends to send it into fits, and once broke you often spend large amounts of time unloading things, resetting the toolbox, restarting Studio or even restarting the PC.  This is a huge time drain, so avoiding situations that break the designer is the first order of business.

Getting the designer working for a CF component is even worse.  CF controls often make use of things that the desktop doesn’t even have, which the designer really hates.  You also have to build the Controls for both versions of the CF (for Nicolas this is important since, at least last time I was with his team, they had versions of the application targeting CF 2.0 and CF 3.5).  A control built against CF 3.5 will never show up in the designer of a CF 2.0 project.  There’s also a major bug in the designer that limits CF 3.5 controls that I’ve written about before.

For designer support you also have to maintain an XMTA file and often end up having condition compiler statements which really make the code less readable.  Workarounds for most of these issues exist.  You can create separate set of “designer” assemblies that provide only stuff for the designer and minimal actual control logic.  The problem with this is that you then have to maintain these things, which sucks up developer time that should be spent actually solving your business problem.

You can’t create a desktop assembly and use it for the designer because the designer will then suck in the full .NET framework as a reference and attempt to deploy that to the device when you want to debug.

So if the designer is so brittle and worthless, what’s a developer to do?  Well, my general attitude is to provide “support” only for basic Controls, and by “support” I mean the inherent capability of the designer to show a box with the location and bounds of your control.  No rendering.  No styling.  No collection editing. 

Really the designer’s primary use for me is to aid in basic layout.  I need to put a Control on a Form, set it’s location and Size and that’s it anyway.  Anything else is done via code, and there’s nothing wrong with this.  Embrace it as how you must work and your life becomes much simpler.

That’s all well and good for a simple Control, but what about a container like Nicolas is after?  His team would like to be able to drop on a Tab control and design each individual Tab, right?  So what are they to do?

Well, I think they’re looking at the problem wrong to begin with.  I don’t blame them, people have been looking at this wrong for some time, and the simple existence of the TabControl tend to push people to look at it wrong.  In general, my recommendation is to not use the TabControl in the first place. 

First of all, it’s 2011.  That ass-looking TabControl would have been ok back in 1995 (if the devices had existed then) since it looks just like the ass-looking Windows 95 interface. 

It’s was an ok solution in 2000 when these devices were new and people thought of them as just “mini PCs” so extending the desktop paradigm to the device was what we did.    Yes, we wished we could do a little more to make it pretty by adding icons and custom drawing, but it worked and users really didn’t expect anything more.

But it’s 2011.  Users don’t use a stylus if they can avoid it.  They know an elegant UI when they see one because they’ve been using a smartphone.  Just because they have no choice in the app they use (this is an LOB app, so the user is locked in) is no excuse to not deliver something that is actually nice to use.  The TabControl does not meet that.  It’s tiny, it scrolls weird, and it’s ugly with no options to make it non-ugly.  Plus it’s  Tab motif.  Name the last mobile app you used on a phone that used tabs.  That’s what I thought. Abandon the piece of crap.

So what would I use?  Obviously this will be subjective, as it’s what I would personally do given a blank slate.  Nicolas is trying to put something into an already-existing, very large code base, so his mileage may vary, but I’m betting it won’t be too bad, and implementing this might actually do a lot toward getting other gains they really need like better transition time between views.

I’d start using the OpenNETCF IoC project.  I’d split each of the existing “tabs” into individual SmartParts, which are now fully designable since they’re just UserControls.  So there you are – the designer requirement is solved.  I’d then place on the Form a pair of DeckWorkspaces.  One would display the “selected” view and the other would replace the “tabs” of old with buttons or clickable images that would be used to select the current view.  It would look something like this in the designer for the Form:

And then the SmartPart that goes into the bottom workspace might be something like this in the designer (well it would probably be a bit different, but you get the idea):

See, the designer works.  It meets the business requirement that it provides a “tab-like” capability where the user selects an item across the bottom and the upper view changes.  But now it’s not just usable with a stylus but it’s also likely to be usable with a finger (gasp!) and aesthetically it doesn’t make my want to poke my own eyes out.  It’s a win-win.  Plus now you can lazy-load the views *on demand* rather than loading up every damned control on every tab when the Form is brought up, so the user is going to be pleasantly surprised there too.  Oh, and now it’s easy to change out “tabs” based on user rights or workflow and probably other benefits that I’m not thinking of.

Occasionally we’ve got to break out of the “what we know” and the “what we’ve always done” routine and look out at the horizon.  By doing so we can often make some simple changes and make things easier for both the developer and the user, and that is how we make progress.

I've published new updates to our MTConnect projects on Codeplex. Both the MTConnect SDK and the VirtualAgent have changes and for detailed info take a look at the change logs in the Source tabs on the project.  Here's a high-level list of what I think the important additions are:

• I've added a fully working reference implementation of an MTConnect Adapter for Okuma THINC controllers (full source is included).  If you have an Okuma machine with a THINC-supported controller on it, you now have a simple agent and adapter you can drop onto the machine to start publishing data immediately. I hope to find time to put together a reference implementation for Fanuc FOCAS controllers.  If you're interested or in need of that support, let me know and we can discuss prioritizing it and the features you need.
• I've added support for SHDR adapters.  At the [MC]2 conference in Cincinnati there was concern that once you selected an Agent technology (either ours or the reference MTConnect C++ Agent), then you were locked in to creating Adapters only for that Agent.  That is no longer the case.  Our Virtual Agent now can easily consume data from your existing C/C++ Adapters written against the reference Agent.  No changes are required in your existing Adapters at all.

If you have any questions on implementation, etc, feel free to contact me.  For more info on our entire line of MTConnect products, take a look at our web site.