In November last year I was playing with setcolor() in FIELD DERVIATION

SetColor( "testa","-1","#707070","-1") should fill the field called testa a grey colour. 

Just reminding myself how it works with the intention of buying De8 and found a bug!

FORM called product entry

if testa field has data in it already and i save ... the derivation does NOT work, i.e. no change to the colour.

if testa is blank with no data and i save changes it works, and all testa field records become grey as they should have been. Close form, reopen form ... fielda has reverted back to default (white)

if I create a NEW field with the above derivation it doesn't work

But,

If I create a new form witth a new field it works as it should.

I tried a different form, called product_order_form - it DID work

Tried it on form called wefn DESTINATION - did NOT work

Form called uzers form - DID work

So what would make 1 particular form unreceptive to a simple derivation suc as SetColor( "hist_t8","-1","#707070","-1")   ??

I checked and there is no OML on this form to cause any problems,

The field name and object name are the same and correct.

forms with a space in their name has been ruled out as the cause as per above tests.

Forms with lots of fields / long fields have been ruled out as wefn destination  only has about 7 fields and they are all short.

This was originally a 7.2 database.

Using GetValue() for this was more a "curios" rather than how you should do it.

In derivations simply reference the column.

When referencing a Choice Field you don't use "" but when you use GetValue() you do as the returned value is always text.

You don't have to use choice either, we just did that for simplicity.

We use all the functions all the time and there is nothing wrong with the functions, but you will always be able to not get the result you want. ;-) 

1. If you want to change the look on any object in DE8 it is better to use SetStyle() than SetColor(). SetColor() was a natural first step, but it only set three different properties i.e. Font, Fill, Border so objects with more properties or lacking these properties will not be manipulative. With SetStyle() you basically change the style of the object, so any styleable property will change, so you can change font, font size, shades etc. etc. It is also easier to maintain in the long run if you want to change something as you simply change the style rather than the programming on each object.

2. We have a similar reported problem with SetColor() once before but as we never received a sample database that showed the problem we were unable to investigate it further. SetColor() is the Primeval Set function so it is possible that it has some weaknesses that the later ones don't suffer from. If you can send us a sample application with this problem it would be much appraciated. You can send it to techsup@dataEase.com, drag and drop it here on your reply (just choose image and drag it into the box) or you can dropbox it to techsup@dataease.com.

3. 7.x is the version that should never have been. It had a lot of ambition in the wrong areas and was sloppily executed and released prematurely. A very bad combination. The same way it is better to migrate from 4.53 to DFW rather than go via DFD 5.x it is much better to migrate from DFW 6.x to 8.X than going via 7.x. If you have migrated to 7.x you will loose old style memo, you will get a lot of corrupt GUI objects which might respond to manipulation the way you describe here.

Thanks for the prompt reply.

1. The De8 lexicon starts at Abs and stops at percent !  Every function after P is missing.  I've already looked in the blog, and i've looked in the forum.  Can't use new functions without a basic structure to follow.  Where can i find the setstyle() info?  Thanks.

2.I'll sort something out for you.

3. I'd love to migrate from 6.x to 8.x for you but this has been a 7.x database since 2009, and i can't go backwards from 7.x to 6.x.

1. This is useful information ;-) And necessary information. The DE8 website is a mini version of the actual website and obviously "our" people don't use it as nobody as discovered this discrepancy. (If you go on http://www.dataease.com/help_functions/) you will ge the complete function library, but inside DE8 it should definitely show everything. So Sorry for that and it will be fixed shortly!)

2. Thanx.

3. This was more a general warning to anyone thinking that going via 7.2 is a good idea on the way to 8. 7.x had all the best intention I am sure but it turned out to be our Vista. Strangely enough every odd version of DataEase has been bad and every even one has been good. They even skipped 3. 2,4,6,8 was all well received, while 1,3 was not even properly released, 5 (both DFD and Windows was not well liked) and 7 is a chapter on its own. So maybe 9 should be skipped to ;-)

We have now updated the DE8 catalogue help so it will show all functions. We have also had a quick run through of the same function to make sure all of them contain atleast a minimum description on "usage".

The Website in the DE8 Catalogue is using the dame DE8 database as the main website, so please visit the main website too as there will be more help attached to a topic than can be visualised in the little window in the catalogue help.

HELP button on the main toolbar is access to the same as Lexicon in DE8 Catalogue help.

Got the same problem wtih setstyle() as i did with setcolor.  New form works, an existing form doesn't.

So I've abandoned looking at that one.  I've got a perfect example of the earlier problem SETCOLOR which i'll send over in a few moments.  2 fields with setcolor, one works, the other doesn't.

Example emailed over, i've stripped out all other tables and dql's so it's nice and small.

Hi again Simon and thanks for the sample.

The problem is not that the function is not working, but the way you apply it.

Setfunctions including SetColor are manipulation functions and this is conceptually completely new in DataEase terms (there is a lot conceptually new stuff in DE8.....)

Up to 7.x DataEase was built around a couple of simple concepts which basically can be labeled as "pull". If you wanted something to happen to a field you needed to do that in the field derivation and the result of that derivation was what happened to that field.

This is very limiting. You had push via DQL but it wasn't something you could really do in a form to achieve a dynamic form.

In DE8 this completely change. You can say that the most important change in DE8 is that you now have push too.

SetClass is push functions which means they do something rather than return anything.

The point is really that Set functions can be included in a derivation to do something without interfering with the derivation.

So if you have a field with derivation: MyField1*Myfield2+SetFocus("MyField3") will just be the multiplication of MyField1 and MyField2 as SetFocus return blank string i.e. 0.

What you do wrong in your app is that you use SetColor in the field you want to manipulate. You can do that, but then you have to follow the rules above and the rules for derivation.

You set it in a field that is saved and editable, so the problem is not that SetColor() or SetStyle() but the derivation and field from where you call it.

In a saved field with a value in it, the derivation is not executed and that is your problem.

if You want your derivation to execute all the time you have to exploite the derivation rules of DataEase.

Any virtual or write protected field that is dependent on another field is execute when the first field in changed so if you don't want the function ONLY to be called when the derivation in the saved field is ACTUALLY triggered you need to create a "support" field (Virtual).

In the supportfield you do the manipulation like this(Object name of Supportfield is Manip): If (Field1 something, SetStyle("Style1"),SetStyle("Style2")))+SetState("Manip",0) -- Last SetState hide the support field.

So the problem is not that the functions don't work but that you put them in a place where they don't trigger.

Only just found this reply, not got a notification and never noticed it on the home pg, odd. Nevermind.  I understand what you're saying, I misunderstood the nature of how it SHOULD be used, I incorrectly took the virtual field example as a best practice.

So:

Virtual field called, let's say 'trigger':

Virtual field with the derivation:setstyle("testa","sred") turns my field red

Virtual field with the derivation setstyle("testa","sgreen") turns my field green.

This proves my styles work :)

Now 

Virtual field with the derivation

if("testa"="q",
setstyle("testa","sred"),
setstyle("testa","sgreen"))

testa is a text field, 1 character long.  Record 1 is character q, record 2 is w, etc through qwerty.

So record 1 with field testa containing q should turn red, and all other records should stay green.

On this test though every record is green.  It always returns the ELSE value. Field testa showing value "q" is green.  I've looked at the demo but it doesn't show this, and at the blog and teh dease help lexixcon and i don't see anything wrong.

Download Sample

This is a good occasion to point out the difference between ObjectName and FieldName or PRISM and GUI.

What we used to know as DataEase (DFD) is basically PRISM. This is the server side of the equation and negates all the transactions and business logic like Derrivations, calculations, data, columns, DQL etc.

On top of that we have the GUI part of the app. Originally this was very simple and the only real thing you could do was Actions (buttons) and reporting (QBM).

Then OML was added and Object Names appeared.

DataEase has always been very inclusive and accepting. It will accept extended characters and spaces in field names and it is case insensitive.

OML is Windows and it is notoriously prickly. It will accept extended characters and spaces (it shouldn't...) but it is CASE SENSITIVE.

When you reference columns (PRISM) you do so without "" and it is case-insensitve, but when you reference an Object you use "" and it is case-sensitive.

All SetFunction() are GUI functions and reference the object name, so be careful with the case and make sure there is no added spaces back or front.

The problem in your little derivation is however not that you haven't got the case right, but the reason I mention above is that it might have confused you a little ;=)

if("testa"="q",

setstyle("testa","sred"),
setstyle("testa","sgreen"))

If you look again you will see that you compare the string value of "testa" with "q" and that will always be untrue, it will equate to 2=3.

So the simple fix here is:

if(testa="q",

setstyle("testa","sred"),
setstyle("testa","sgreen"))

Here you reference the column so no "". You can't in any way reference the object value this way as you have to use GetValue() to pick the value out of an object so if you went down that route the Derivation would be.

if(GetValue("testa")="q",

setstyle("testa","sred"),
setstyle("testa","sgreen"))

This would obviously be "meaningless" here as you are working within the derivation of a field (PRISM) and will have full referencing right of this column, but if you had used a GUI field this would be the way to pick out the value.

PS! When you work with styles like this also make sure that you have saved the style changes i.e. the style file. If not it will work when you test it and then when you restart the application it won't.

I wondered about where quotes appeared but the only demo for setstyle is using the on click.  Anyway, got it working on TEXT fields :) .... but CHOICE fields confuse it.

Testa now a choice list; q,w,e,r,t or y.

Created new styles for choice fields and my field called trigger now says

if(GetValue("testa") ="w",
setstyle("testa","fred"),
setstyle("testa","fgreen"))

So testa now always green except when value is w, when it is RED.

But sometimes it is wrongly green, go to next record, then go back to it and it's changed to the correct colour; red.  I can do this time and time again.  I'vr re ordered the data and all sorts , tried an existing table and that does the same with INC, dec, note and order as the choices.