The Baretta

A few weeks back...  wait.  I'm only lying to myself, let me start again. A few months back, I moved desks at work.  At the time, I merely pushed aside the old desk-owners belongings and plunked my own right in the centre.  My computer.  My books.  My pencils.  My keyboard filled with my skin dust.  It instantly became My Desk. It wasn't until a few days back (truth) when I became severely low on work for the day, that I was scrounging around the depths of the third draw only to find that the majority of stuff in there was not mine! The challenge had been set, how much stuff could I viably throw out without someone asking me later down the track where it had gone. Now the interesting part of this story isn't how much I threw out (it was substantial), but what I threw out, and what I learnt. Here's a list of useless things I found in my draw: Receipts for the departments fruit bowl for the past 5 years (1 for each week) P...

I feel like there are many sites/blogs/articles etc that list all the wondrous things that InfoPath can do.  They praise how user friendly it is for non-coders, how quick it is to design forms in comparison to Adobe & Visual Studio.  What none of them tell you is that if you want to design a code-less InfoPath form, you are severely restricted in many areas that you wouldn't realise, until of course you need to implement that functionality. "Why would you need to stick to a code-less InfoPath form?" you ask?  Well, in our organisation, the reason is simple.  We plan on creating many automated forms, and we plan on pushing them out to the various departments so that they can administer small changes themselves, only asking for help when they need technical advice. So as a coder who knows what can be achieved with a cheeky bit of C# here and there, I am going to list of issues I've found while trying to create a code-less form: ...