A day in the life of...

At work we use SourceSafe for our version control, and I used SourceAnyWhere as the client. I would like to outline the facts and let you decide what happened for yourself. 01: I checked out my model (EcoModeler) 02: I added a new class. 03: Generated code. 04: Checked in the mode. 05: Checked out. 06: Added two new associations 07: Generated code. 08: Checked in. 09: Checked out. 10: Added a parameter to a method. 11: Changes a state machine diagram. 12: Checked in. After each of the changes I would implement code in my application that used them, so if the changes were lost at any point during this process then I would notice because my app would no longer compile. Today I checked out the model and noticed that my new class was missing. I backed up my generated source code and then regenerated code from the model. Using BeyondCompare I checked for differences and came up with the list of changes in the steps above. Somehow the model in my source control had 3 revisions missing. I...

In an ECO app I am writing it is very important that updates by other users are identified as soon as possible. This is because there will be multiple users all selecting jobs to do from a predefined list, and it is not only possible but also very likely that more than one user will select the same job at the same time (the job at the top of the list). To implement this I chose to use the remote persistence feature of ECO and in particular its Sync Server feature. Every 5 seconds my client apps will contact the server and retrieve a list of updates made by other users, it will then apply those updates to the cache of its own EcoSpace. So when a user selects a job to do at the top of the list their app will stamp it as InProgress and update the DB, the job will then automatically disappear from the screens of all other users. As I like to use undo blocks in my app to allow the user to cancel changes (using my DirtyObjectCatcher component) it is highly likely that during these synchro...

There are exciting times ahead! The team that brought you ECO for Delphi are now a separate company named Capable Objects ( http://www.capableobjects.com ). ECO will still be part of the next release of Delphi, but according to the official statement ( http://dn.codegear.com/article/3673> ) and comments in the newsgroups it is quite obvious there will also be a version of ECO for Visual Studio! In the past the ECO guys released patches for ECO bugs, unfortunately it was not always possible to provide a patch. With the guys now being a separate company they are free to decide their own release schedules. Instead of having to wait for a Delphi update they can now release updates as often as they wish. Just like the good old BoldSoft days when we used to get an official update really quickly if ever a critical bug was found. Not only that, but it would also seem that they will be shipping source code too! But that's not all John! The guys at Capable Objects have asked me to wr...

It is amazing! I'll leave that previous post just in case anyone ever needs to create an ECO object instance first and then connect it with an EcoSpace afterwards, but you don't need it for MonoRail! public void Join([EcoDataBind("User")]User user) { PropertyBag["User"] = user; if (this.Params["User.FirstName"] != null) { GetErrors(user.AsIObject(), Errors); if (Context.Params["ConfirmEmailAddress"] != user.EmailAddress) Errors.Add("Email address confirmation does not match email address."); if (Errors.Count == 0) { //TODO EcoSpace.UpdateDatabase(); Redirect("Account", "Home"); }//No errors } } That's all there is to it now! I have created a small set of classes to enable ECO support in MonoRail. Instead of descending your controllers from SmartDispatcherController you will now descend from EcoSmartDispatcherController . This gives the following abi...

So I didn't like Ruby on Rails much. More accurately I didn't like the Ruby language or ActiveRecord much, but the "Rails" part I really quite liked! So my investigation continues and I have found myself looking at MonoRails. MonoRails is what I would have as a child called "a rip off", but these days it is known as a "clone" :-) It's basically a .NET version of Rails, which obviously appeals to me because I liked the Model-View-Controller approach of Rails and I obviously like C#. MonoRails has its own version of ActiveRecord (which I shall be avoiding) and an interface into NHibernate too (which I haven't looked at in great depth, but it certainly doesn't look as powerful as ECO). So I have been trying to get MonoRails working with ECO instead. Considering I don't know MonoRails at all I am surprised at how quickly I managed to do what I wanted. Take the following controller method as an example, when the user visits localho...

I've just been driven mad by a "Quantum bug". What is a quantum bug? Well, it's a bug that doesn't exist unless you look at it :-) I kept getting a NullReferenceException in my code. It happened whenever I changed a property of a class. I assumed it was something in the framework, but it was in fact in a library of my own. When the property changed it would trigger an observer I had attached, the purpose of this observer is to check if the form that owns my component is the active form, if it is then it records the object that changed; the purpose is to know which objects were modified by which form. Anyway, to check if the form is active I do this Form activeForm = System.Windows.Forms.Form.ActiveForm; Form activeMdiChildForm = activeForm.ActiveMdiChild; if (activeForm == this.Form || activeMdiChildForm == this.Form) ..... Now the quantum! If you are debugging your app Form.ActiveForm will always return null! How useful is that eh? :-) So, when debugging ...

I was REALLY looking forward to programming some apps on the Mac using Cocoa and objective-C. I am reading "Cocoa programming for MAC OS X" by Aaron Hillegas. I had read as far as page 30 when I saw the following: "Objective-C is a very simple language. It has no visibility specifiers: All methods are public; and all instance variables are protected. (Actually, there are instance specifiers for instance variables, but they are rarely used. The default is protected, and that works nicely.)" WHAT? Works nicely? I disagree! It is actually possible to make a class's method private by not including it in the interface declaration (myclass.h) and just adding the implementation file instead, but what about protected methods? public I expose as little as needed to ensure the class provides the service it was designed to. The signatures/names of members in my public area change as little as possible so as not to break other people's code. Public members are ...