A day in the life of...

Oh boy, what a nightmare! After days of messing around I finally found where the memory leak is in my app, it was in DirtyObjectCatcher! The DirtyObjectCatcher used to subscribe to the DirtyListService, so that it was notified whenever an object was made dirty. I experienced this problem... 01: User creates a "Call" to a customer site. 02: User edits a purchase order. 03: Save purchase order (merges the undo block to the Call undo block and closes the form) 04: Edit the purchase order again from the Call form The PurchaseOrder is already dirty so it wont get triggered again, this used to result in no constraints being checked etc and the possibility of entering dodgy data. The solution at the time was to have a static list in DirtyObjectCatcher private List Instances; whenever a new instance was created it would be added, whenever Dispose was called it would be removed. I then hooked into the cache chain and whenever a value changed I would call a static method on DirtyObjec

That's it, my short evaluation of TC is over! Problem 1: I emailed support with a question weeks ago, didn't get a response. Not impressed. Problem 2: I reinstalled my O/S recently so had to restore my version control folder. When I try to check files out I now get an "Object not found" error, whatever that means? Some searching reveals it is a bug that has been fixed in the version I have, I beg to differ. Problem 3: This one was the worst! I use TC client for a customer already which is why I decided to try out the server. I connected to the customer server, checked out loads of files, upgraded my VS2005 project to VS2008 and then checked everything back in. What a disaster! TC had replaced the source in the customer files with source from my private local server! I couldn't believe it! As I looked through Assembly.cs files I could see WinForm code from the last project I worked on locally! This is obviously bad because I had exposed source code from one concern

I recently had to tweak my remote persistence server settings. I noticed that I had leaft the SyncHandler.HistoryLength at the default value of 10,000 items. This was overkill because my clients sync every 3 seconds. I thought maybe I should drop this down to about 100, that should be okay? Each client only does about one update every few minutes so I it should, right? Problem is not all of my users are people. One user is a messenger service which looks for unsent messages, sends them one at a time, marking each in turn as sent and updating the database. This gets run every five minutes so probably sends about fifty messages at the most, but what if someone decides to change it to ten minutes, or thirty? So maybe I should increase the HistoryLength to about 200? Then there is the other client, this one syncs with an external database. This could perform hundreds of updates every minute. If the messenger is set to run every thirty minutes...I'm not sure what a good History

List<Person> p = new List<Person>(); This works fine, but what about this? Type someType = typeof(Person); List<someType> p = new List<someType>(); Nope! But you can do this... Type genericType = typeof(List<>).MakeGenericType(someType); Why would I want to? Because I am creating a tool that generates plain old .NET objects from an EcoSpace's model, and I wanted to implement multi-role association ends as public List<Building> RoleName; rather than just public Building[] RoleName;

In a previous post I showed how to return a binary file from a controller action, well, this no longer works in release candidate 3 of the framework. Instead you have to create a new ActionResult descendant to do the job for you. This is how I did it.... return new BinaryResult(data, Path.GetFileName(productFileName)); and the class is implemented like so: public class BinaryResult : ActionResult { private string ClientFileName; private byte[] Data; private string VirtualFileName; public BinaryResult(string virtualFileName, string clientFileName) { if (string.IsNullOrEmpty(virtualFileName)) throw new ArgumentNullException("VirtualFileName"); if (string.IsNullOrEmpty(clientFileName)) throw new ArgumentNullException("ClientFileName"); ClientFileName = clientFileName; VirtualFileName = virtualFileName; } public BinaryResult(byte[] data, string clientFileName) { if (data == null) throw new ArgumentNullException(&q

I'm trying to upgrade from Preview 2 to Preview 3. I think the idea of having each action return an ActionResult was a good one, so far it has actually made my code slightly smaller. What I don't understand though is why Html.Select seems to have disappeared... Compilation Error Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately. Compiler Error Message: CS1501: No overload for method 'Select' takes '5' arguments Source Error: Line 8: Product Line 9: Line 10: <%= Html.Select("SoftwareID", (object)ViewData["SoftwareList"], "Name", "ID", (object)ViewData["SoftwareID"]) %> Line 11: Line 12: When I go into the APX and type Html. there is no Select method listed along with

Although I have not (yet) needed this myself I can see myself needing it in the future and the question has been asked before. "Setting HasUserCode=True on a Child.Parent single role does what I want, but how do I handle the scenario where Parent.Children.Add(item) is called on a multirole?" By default you can’t, but with the addition of a single class and a small amount of tweaking you can get it to do what you want! Here is how to do it: 01: Mark Parent.Children’s association end with HasUserCode=True in the modeler and then generate code. 02: In the source code of your class (not within an ECO region) add the following   private EcoMultiAssociation<Child> m_Children; This is a class that does not yet exist, I will show the source code for it later. 02: In the source code locate the "Children" property and change it like so   public IEcoList<Child> Children   {     get     {       if (m_Children == null)       {         m_Children= new EcoMultiAssocia