Re: OPO container anomoly

>Can anyone shed some light on this "feature?" I have mailed to opo-info
>but don't expect a reply any time soon.
 

>It appears to me that it is not at all practical to use custom fields on
>forms. This means it is not possible to control something as simple as the
>font or color that all of your entry fields will use, let alone add a user
>defined method that they all inherit.
 

>Let's say you want be able to change the font in all of the data entry
>fields on your forms (i.e. mimic the capability of Oracle*Forms property
>classes). All you need is a subclass of a standard text field.
 

>1) Since you can not subclass the standard text field, make a new class
>called myField and put a text field in it.
 

>2) Make a new form called frmEMP and instantiate the new class several
>times on the form. Set the recordsource of the form to EMP, the
>recordsource of each myField to =frmEmp, and the datasource of the text
>fields inside each myField to NAME, DEPT, etc.
 

>3) Run the form. Every time you change a value and tab or otherwise move
>the focus out of one of these fields, OPO decides it needs to flush the
>record to the database. If any one of the fields is bound to a column that
>is NOT NULL, and you have not preloaded a value into that field, OPO puts
>up a dialog box that says "Error flushing row to database", then another
>dialog box with an ORA-01400 or ORA-014700 (NOT NULL violations). You can
>not get to the offending field, because OPO won't let you out of the field
>you started in. Same goes for any other database constraint violation.
 

>In summary: every time you tab out of a container, the entire row is
>flushed. The only way to implement a user defined class is in a container.
>If the field in that container is part of a row that violates any database
>constraints, you're SOL.
 

>There are many implications to this state of affairs well beyond being
>able to set the font of my fields. Anyone have any ideas? I really hope
>I'm missing something here.
 

>Michael Kranzdorf mikek_at_krt.com
>Kranzco Realty Trust 610.941.9292

Hi Michael,

        you are absolutely correct. The data is flushed when you move move from one container boundary to the next. See page 17.24 in the user guide. There is going to be a deferred flushing mode, which is not available in this release. As the user guide says the row is flushed if the focus switches to a container with a different record set. So if you set the RecordSrc property of the class when you instantiate it to =Container, it should work. Hope this helps

Kasu Sista, Co-Author , OPO Developer's Guide Links Technology Corp.
Chicago, IL Received on Sat Sep 16 1995 - 00:00:00 CEST