A day in the life of...

I've been up quite late working out what I want to cover in the "ECO jump start" document. The trick is to start at a level where the user knows absolutely nothing, and end up where they know enough to decide whether or not they wish to spend some time learning how to use ECO or not. I think I should start off explaining why multi-tiered app development is a good idea; then I think I should go on to creating a package in a DLL; then onto creating a non-persistent WinForm app using that package; then make it persistent; and so on. My problem is that ECO just does so much! I'll paste what I have so far at the bottom of this blog entry to get any feedback. As the list progresses the subjects become more advanced and I am worried that the jump start might actually frighten people off by making them feel overwhelmed. Maybe I should just take it so far and then leave the more advanced items out? Maybe I should just include a section at the end of the document explainin...

We use wireless printing through a COM port over BlueTooth. Having BlueTooth on all of the time can contribute towards energy consumption and cause the battery life on the Pocket PC to deplete faster. Now I disable BT when the application starts, and then re-enable it to print and disable it immediately afters. This adds about 1 second to each print job but it should save the battery power. [DllImport("BthUtil.dll")] private static extern int BthGetMode(out BlueToothRadioMode dwMode); [DllImport("BthUtil.dll")] private static extern int BthSetMode(BlueToothRadioMode dwMode); public static BlueToothRadioMode BlueToothRadioMode { get { BlueToothRadioMode result; BthGetMode(out result); return result; } set { if (value != BlueToothRadioMode) BthSetMode(value); } }

My compact framework application imports XML into a local database. As there is so much data to import this can take up to an hour. During development there were no problems with this, but of course during development the Pocket PC is docked in its cradle which provides it with power. When a Pocket PC is removed from its cradle it manages power differently, just like an unplugged laptop. So every five minutes the Pocket PC would hibernate and the user would have to turn it back on in order for the import to continue. During an hour the user would have to do this approximately twelve times. How annoying, and dangerous too if the employee is driving to their first job. Anyway, I found the following very useful code on the web and thought I'd point it out as it was so useful! public class Device { #region Device sleep support [DllImport("CoreDll.dll")] public static extern void SystemIdleTimerReset(); private static int DisableSleepCallsCount = 0; private static Sy...

Ever played "Spot the difference"? I'm sure you have :-) I'm just looking through an application I have inherited from a Turkish company it was outsourced to. I was just browsing through a 5MB SQL script to generate the DB + stored procs when I saw this.... @MATERIAL_CODE=REPLACE(@REPLACE_MATERIAL_CODE,'Imprinter','Imprınter') Does it do anything? Sure it does, but can you see what it is? There are two clues in this post but I wont tell you where!

Hi all I have finally reached a point where I can dedicate a few hours each today to "something new" and have decided that the ECO book I have always wanted to write would be great fun. My first idea is to create 2 or 3 separate items: Title: ECO jump start This would be in paper / PDF format and would contain a set of exercises for a new user to follow in order to get started with ECO as quickly as possible. It would basically cover creating a simple model, prototyping using auto-forms, using the different handles, databinding, parent-child grids, creating/evolving the DB, OCL / code derived / reverse derived attributes, and stuff like that. Title: ECO API This would be an electronic format which would basically be a "Press F1" reference. Title: ECO book This would either be a paper/pdf format or, if possible, part of the ECO API document. It would be a technical overview of the framework + its services and abilities. I imagine it might be similar to my ECO Ser...

I have just released a minor update to ECO extensions. It contains a fix for a bug that would prevent the DirtyObjectCatcher from catching modified objects for MDI child forms.

I recently developed a simple support application that allows users on a PC to provide a one-off security number to a Pocket PC user and when entered the PPC will perform a specific support function. I used the same class to generate these security codes in both the desktop and compact framework applications, tested it quite thoroughly and it all seemed to work fine. However once deployed it became evident that the codes provided by our support department were being rejected by the PPC as invalid. So what went wrong? Seeing as the same class was used for both applications I thought it would be okay to test the encoding/decoding of command numbers on only a single platform, and this was my mistake! The routines use string.GetHashCode() to add a checksum to the end of the security codes just to prevent the user from performing actions without authorisation. For reasons I cannot imagine the implementation of string.GetHashCode() is different in the compact framework from the one in t...