TPersistent.com

In my current project I dynamically create controls in a container for the settings dialog.  I was getting some flicker so I mistakenly used LockWindowUpdate() to solve the problem.  I had used this API call years ago, so I knew of it and then discovered via the EMB newsgroups that using LockWindowUpdate() is a common, and very bad practice.  Thanks to Karl Pritchett and Remy Lebeau for setting me straight and providing some of the following  resource links:

http://blogs.msdn.com/search/SearchResults.aspx?q=LockWindowUpdate&sections=2905

http://msdn.microsoft.com/en-us/library/dd145034(VS.85).aspx

What is surprising is that Delphi’s VCL doesn’t provide a native mechanism to achieve this, and document it as the preferred method.  The VCL isolates developers from the WinAPI messages for the most part and this appears to be a fairly common issue from my google searches.  If you’ve ever burned time on this, or think it would be a valuable additional to the VCL, consider voting for QC 88375.

A while back, I came across an edge case with hcOPF that I had not anticipated when I wrote the binding mechanism.  When an object has calculated attributes, it forces the attached mediators to update the UI by triggering an ObjectChanged event which calls:

//notify all mediators of the change
FSubjectDelegate.NotifyOfSubjectUpdate;

which cycles through all mediators forcing them to update their controls.

Normally this isn’t a problem, but if you have outside stimulus that triggers a calculation event, such as a timer, or I/O device, then an update may be triggered while editing the object.  What’s worse, is that if the user is changing an attribute value, and the calculation is triggered before the editor control updates the object attribute (this will happen if the control doesn’t use an OnChange event), then the user’s changes will be overwritten.  It makes for a challenging situation for the user to make a change before the object is changed by the external cause.

What would be more appropriate is that the ThcCalcObject should trigger the UI updates for only the attributes it modifies.  This blog post should serve as a good reminder to both make this enhancement, and continue to use the work that you produce so you can see it through the eyes of a consumer (dogfooding).