Maybe you can split the code, to call an entry from your global proc so you get something like this in your <READ> Trigger:   call SO_READ_ATF   entry DO_DISCARD    if (PRICE > 1000)       discard    endif end

wasn't it that one can not call a local proc out of a global proc? (IIRC)

We use a global proc for our read triggers and in that proc we essentially have

if ($dbocc == 0)

    $collhandle->preRead(t_where, t_order, t_options)

endif

read options t_options where t_where order by t_order

if ($status >= 0)

    $occhandle->postRead($status)

endif

We have dummy preRead and postRead operations defined for each entity in the model and we can override those at component level if necessary.

Hi Andy, Good thinking (as ever), the $collhandle is a very nice way to make local coding accessable from the global proc. Especially because you can use the same operation name over and over again without problems. I use it as well with collection based INIT and CLEANUP operations. These will be invoked during components INIT and CLEANUP operation and perform all these nice tasks like populating valreps etc. I have a #defines dur_formentities = ent1,ent2 to iterate over the entities. The automatic creation of these type of definitions for forms and entities was designed and implemented in the dITo Uniface Reflection (DUR) project.   Greetings from a cold Frankfurt/Germany morning Uli

Hi Uli,    Can you not replace your #defines with a recursive subroutine using $componentinfo($instancename,"OUTERENTITIES")) as the primary, and $entinfo(v_current_name, "INNER") to recurse.  params string v_names : IN endparams variables string v_current_name endvariables forlist v_current_name in v_names ... do your entity level processing if($entinfo(v_current_name,"INNER") != "") forentity v_current_name  call recursive_proc($entinfo(v_current_name,"INNER")) endfor endif endfor

Hi Iain, the dur_* defines are created automatically within a 2phase compile so there is no manual overhead. And dur_formentities is just one of a suite of needul definitions added to the component. Please have in mind that a couple of years ago we learned in some uniface courses that field indirection takes 10 times longer at runtime than mentioning the direct fieldname in the code. So  the #defines is not only a straight forward coding, but results in a much better performance at runtime compared to that messing around with outerentities and innerentities and recursions and ... And: at compile time, the painted entities are fixed, so there is no gain traversion entity trees at runtime So to your question: Especially if you have entity propagation multiple times in your code, the $componetinfo/$entinfo could be used, but the #defines is the much better option. Greetings from Frankfurt/Germany, Uli