One challenge that has been present since OML was introduced and one could start to manipulate GUI object directly is to manipulate different Rows/Records in a Subform etc.

Record objects in Subforms are clones, and hence don't have their own unique names. You are able to give the objects in the first row/record unique Object Names, but all the successive records will hence have the same object name. 

With the introduction of ExecDQL and the opportunity to manipulate much more directly in the GUI we felt this very strongly so we decided to look into how we could "address" this issue.

One of the nice things with the SetFunctions is that they are top down. I.e. we don't go in via PRISM but via the GUI object that represent the field etc. PRISM is very "strict" and rigid in its structure, but when you go in via the objects this rigidity is not affected. The Set functions are "opportunistic". They look for the first object that fits and do their "deed". With this update, we take that logic one step further (or many steps further ;-)

You can keep on using them as before but we have added an optional numbering system. SetValue("MyField","MyValue) and SetValue("MyField#1","MyValue) will give the same result, but SetValue("MyField#10","MyValue") will jump 9 objects with the same name (clones) and set the value in the 10th.

But how is this useful?

Here is one small example:

This is a subform on a tab that display Documents on a customer. It will show a maximum of 20 rows. The problem is that DFW will always show 20 rows, and if I have no records it will be 20 empty editable rows. That is fine if that is what I am looking for, but as this is just for reading I don't want to show the records thats empty and if all are empty I want nothing to be shown or maybe just a message...

And this is how it looks after we have doctored it by using SetState to hide the empty records.

We do this simply by generating a "displaynumber" that corresponds with the row in the subform this way:

This column need to be part of the Table so we can reference it in the virtual field that actually hides the record. We Set the global "RecordNr" to 0 earlier in the form so it is 0 when the subform is drawn. 

SetState("Manipulator",ShowStatus )+SetState("DQL",ShowStatus )+SetState("NrTowns",ShowStatus )+SetState("ShowNewTown",ShowStatus )+SetState("NrCountry",ShowStatus )+SetState("ShowNewCountry",ShowStatus )+SetState("DQLToLookup",ShowStatus )+SetState("ShowStatus",ShowStatus )+SetState("DeleteAll",ShowStatus)+<span style="color: #c0504d;">SetGlobal("RecordNr","0")</span>

And finally we just insert a virtual field in the subform:

And thats it.

This "setup" simply check if the heading field is blank, if it is it hides the record. ;-)

This is just one simple way of exploiting it, imagine all the others when you combine all of the Set function.

SetFunctions can be called as much as you like and as they are opportunistic, they don't do any "harm" if you try to set an object that doesn't exist, nothing happens....thats it!

So go for it!

Ahh before we forget.

Another annoying thing in DataEase is that it doesn't give any message if your search don't hit or if the results are empty.

This search resulted in one hits. As indicated in the right hand corner of the search field, and you can see that only one row is displayed.

We add a b to the search criteria and we end up with nothing, we see that all the rows are gone and it has been replaced with a message.

In this example we use a slightly different approach and run a DQL via MemoExecDQL() to disable all the empty rows.

define temp "telle" number .
define temp "myreturn" text .
telle :=1 .
while telle < 61 do
telle :=telle +1 .
--myreturn := SetColor(concat("Record1#",telle),"#ff0000",if (floor(telle/2) not =ceil(telle/2),"#0000ff","-1"),"-1") .
myreturn := SetColor(concat("Record1",""),"#ff0000","#ff0000","#ff0000") .
myreturn := SetState(concat("Record1#",telle),if(telle<=data-entry field1+1,1,0)).
end