Easy to Create, Easy to Change - Easy to use!


SetState() not working for subform and record1


Started by George Washington
Search
You will need to Sign In to be able to add or comment on the forum!

SetState() not working for subform and record1

Hi there,

I am running the latest version (8.2.0.1700) of dataease and playing around a little with the subform as a dialogue example. The example works as expected, but I have problems making it work on my application. When I use the SetState() function with editbox field or buttons it works, but it seems it has no effect on the record1 and on subform. I am stuck at the Mani editbox derivation. I put the code in it and the code seems to work, in fact the Manip field itself is hidden (first instruction is SetState("Manip",0) ), but the subform (SetState("System - Info",0) and of course I put the name of my subform instead of system info) it always visible (by the way, I suppose that the object name for a subform is the form/relationship name, as I did not find a way to change it). I tried also to put the setstate instruction in the OML code of a button, but still the subform is not hidden. The same happens with the record1 object: I cannot hid it. I made some tests (putting the instruction in the OML code, in the derivation of a field or in the "execute function/derivation" of the button) and it seems that the SetState can work on editbox and buttons, but it has no effect on record1 and on subform. Any suggestion is welcome.

Thanks.

Written by George Washington 15/01/15 at 10:06:33 Dataease [{8}]FIVE

Re:SetState() not working for subform and record1

It is annoying that you can't name/rename a lot of objects in the DE GUi model.

The most annoying is Record or Record1 as it will become.

All Records will end up being called Record1 (before first same and reload of an FRM it is called Record so be aware that if you work on a Fresh form (first edit) it will work with Record and then not work forever after as it will be renamed Record1, so just create a form save it and open it again in DT and it will be renamed and forever stay as Record1).

Object names are Case Sensitive so it have to be exactly as the object name. The trick to get the right name is just open OML and copy the Object name from there, then you are sure you get it right.

When you have more than one object with the same name, you need to use the # to point at the right one. The order in the Object three is Top to bottom, left to right. So object that has the same y position it will be left to right, but one pixel higher up and it is before in the object order.

Your problem is either that you have another object with the same name, or you have got the spelling wrong one way or the other.

Written by DataEase 15/01/15 at 11:06:55 Dataease [{8}]FIVE

Re:Re:SetState() not working for subform and record1

Thank you DataEase, you saved me again :) . For the records, it was the case thing. Oh, there is still a problem: if I create a derivation with some wrong cases (e.g. record1) and then change the case only, dataease will not actually change the derivation (i.e. when I open it again I find names with wrong cases), so I need to delete the whole derivation, save, open put the derivation with right names and save.

Written by George Washington 15/01/15 at 12:00:31 Dataease [{8}]FIVE

Re:Re:Re:SetState() not working for subform and record1

You are of course right. This is the problem with moving from old to new ;-)

One of the deep entrenched principles in DataEase was case-insensitivity to such an extent that it permeates both data and programming. With the introduction of Object names this was broken. One could think that it was for some deeper reason, but the most likely reason is simply that object names in WIndows are case sensitive so to use "default" functions this was the easiest route...

It is a problem in DataEase that the development team in DFW didn't understand or relate to the traditions of DataEase so they basically constantly caused problems when introducing and inventing functionality in contravention with the deep rooted ideas.

Anyhow, we are no better as we got involved from a Web Angle and there too everything is case-sensitive so again the product goes further towards case-sensitive rather than case-insensitive.

At this stage the grown up thing to do would be to simply make the product case sensitive throughout, but the problem then is with heritage.

The problem you have come accross is due to the fact that DataEase use the same logic throughout, so the parser logic that is used in Derivation is the same as used in RT etc, and it being case-insensitive it don't see a difference between 

SetState("myField",0) and SetState("MyField",0) so it doesn't save your change as to the parser there isn't one...

So you need to trigger a further "change" as it then will save your derivation AS IS.

So the trick is to add some spaces around commas etc...

So by writing  SetState("MyField" , 0) will work ;-)

Written by DataEase 15/01/15 at 12:33:57 Dataease [{8}]FIVE