Regular users will know that calls to SET_PROPERTY and GET_PROPERTY can be made more efficient by passing @rm delimited arrays to the routines rather than making multiple individual calls.

Although using the @rm concatenation method can lead to improved performance you need to be aware of how it is actually implemented, otherwise it can lead to some subtle bugs that may be hard to track down. This is because internally there are two types of properties; PS (Presentation Server) properties, and Synthetic properties, and the order in which they are processed when combined together could cause your code to behave in a manner that you are not expecting.

The PS properties are implemented at a low-level inside the Presentation Server (OINSIGHT.EXE) and generally deal with “real” visual properties such as TEXT, SIZE, LIST and so on: basically they wrap the low-level UI attributes of forms and controls. Access to these properties is via two functions called ps_Get_Property and ps_Set_Property. They are not documented but are used internally by the normal Get_Property and Set_Property functions as needed.

The Synthetic properties are implemented in Basic+ and deal with Form IO logic, data conversion and suchlike; i.e. the things that are specific to OI rather than Windows.

When you don’t use the @rm concatenation method then Get_Property and Set_Property first try to process the request as a Synthetic property, and, if not found, it is then passed on to the PS. This obviously doesn’t cause any issues as no concatenation is involved.

When you do use the @rm concatenation method both Get_Property and Set_Property first pass the arrays onto the PS, which deals with the properties it is responsible for. After that the arrays are scanned for any Synthetic properties and processed accordingly.

In many cases this would have no effect unless the order in which the properties are called is critical. Consider the following example:





In this case both BLOCK_EVENTS property calls (PS properties) will be processed before the DEFPROP call (a synthetic property), meaning they will have no effect and the CHANGED event will fire. Consider yourself warned!

This is taken from the document "OI Coding Standards" published by Sprezzatura.