hcOPF ReadOnly Object Attributes

For those of you looking at upgrading to XE2 for live bindings, or XE3 to get visual live bindings I thought I would mention that hcOPF supports object binding with earlier versions of Delphi (D7 and up).  Not only that, but you’re not reliant on a black box expression engine.  Bindings in hcOPF are written in Delphi and debuggable in Delphi.  In fact, it’s quite easy to write your own mediators to support any non data aware control you want to use and best of all, since hcOPF is open source, you can modify it to suit your own needs, and there are no undocumented ’secrets’.

hcOPF automatically handles ReadOnly attributes ‘out of the box’, by assuming that the domain object is the source of the truth.  That means if an attribute on the domain object is readonly, then the mediator informs the UI control that it should also be readonly.  There are some situations though, where this is not desirable.  For instance, if you want to display some boolean values on a form when a client is selected, but in order to edit the client information, the user needs to go into the client profile form, you don’t want users inadvertently changing client information by clicking on the checkboxes.  In this scenario you can toggle the AutomaticReadOnly property of the mediator (assuming it’s implemented) to False.   AutomaticReadOnly is normally True by default, and means that the mediator will ensure the UI control mirrors the domain object’s ReadOnly attribute, or will behave as if the attribute is ReadOnly if the object itself is marked as ReadOnly.  By changing AutomaticReadOnly to False, you can control the UI control’s ReadOnly behaviour yourself.  In the example given, the checkboxes would be disabled.

I recently added a new ReadOnly field variable to ThcAttribute since I ran into a scenario where I wanted to use AutomaticReadOnly but wanted to make certain object attributes ReadOnly.  Since the ThcAttribute.ReadOnly property is determined by its MetaData, changing it for one attribute in one object instance effectively changed it for that attribute in all object instances.  Adding the ReadOnly field variable and initializing it from the attribute definition (ThcAttributeDef) effectively solved this issue.


5 Responses to “hcOPF ReadOnly Object Attributes”

  1. ncook Says:

    I am trying to find the home of the hcOPF framework itself. I have searched this blog high & low and have found no links that give me any clues. I found a link to a project on source forge that says it was last updated on 2011-10-17, so that is obviously not up to date.
    Please tell me (and everyone else) where to find the hcOPF framework and any documentation related to it.

  2. Larry Hengen Says:


    hcOPF is available on SourceForge.net at http://sourceforge.net/projects/larryhengensopf

    I think you found it on SourceForge, but the Last Updated date shown is not the last updated date of the SVN repository (which is current 7 hours since last update).

    The documentation is in-line, although a more conceptual overview and some specific topics are available as articles in this blog. All are tagged with hcOPF, and the blog is searchable. I am also willing to answer any questions, and there are sample projects with the source to help get you started. Currently you need to use XE2 since I have not had time to update the projects for other compilers since I ported to XE2 and re-organized the source code to support FMX (Windows and OS/X).

    I just received a Documentation Insight license, so I am hoping to use that to publish more comprehensive documentation in the future. The comments are currently in JavaDoc, but I ran into some tool limitations that halted work on it.

    For an overview you might want to start here (http://www.tpersistent.com/?page_id=44).

    If anyone wants to help update the projects for D7 to DXE, or assist in writing the documentation I would welcome it. I could also use some help in automating the delivery of the packages with compilation into the IDE, or support for binary installs (starter edition). There just never seems to be enough time in the day…

  3. Tommi Says:

    To be able to debug bindings (and what not) is very important. All magic that happens behind the scenes is just awful. By debugging the developer will see much easier why something is not working as he/she thing it should.

    I am not sure is the situation changed but mainly why I don’t like .NOT is the fact that you can not debug into the it’s core code…

  4. Stefan Glienke Says:

    First you are saying hcOPF supports D7 and up and then you are saying it only works in XE2? *confused*

  5. Larry Hengen Says:


    It works with D7 and up, but like I said I need to update the projects for compiler versions other than XE2. The current ones are not valid since I re-organized the source files and split some units. It shouldn’t be difficult for someone to update the project files using XE2’s as a guide, but I just haven’t had time.

Leave a Reply