Example 1:

Main Form buttons using mouse over.

define "x" text .

x:=setstyle("CustomerDetailsButton","ASPButtonMouseOver") .

and on mouse exit

define "x" text .

x:=setstyle("CustomerDetailsButton","ASPButtonClearNoOutline") .

This works on a few buttons, but not on the rest. Nearly all forms have the same issue.

Example 2:

Subform field style changes, This one works on the first line of a subform, but not the rest.

The code here contains both old way and new way of doing this. The old colour change works fine on every subform line every time, but is a pain to change on every field if changes are needed. The SetStyle() ONLY works on the first line of the subform.

define "x" text .

x:=Setvar("VCDate",current extended date) .

if SESS_EndDate > getvar("VCDate") then

--x:=setstyle("SESS_NameofAd","SubFormFieldLive") .

HighShade.color.red := 0 .

HighShade.color.green := 255 .

HighShade.color.blue := 0 .

redraw := 1 .

else

--x:=setstyle("SESS_NameofAd","SubFormField") .

HighShade.color.red := 255 .

HighShade.color.green := 255 .

HighShade.color.blue := 255 .

redraw := 1 .

end .

end .

In both of these examples the styles are named correctly and can be applied to the field manually. Its only when its done automatically it fails.

In the other DE9 (DE10?) it worked flawlessly and was used throughout the database.

On any of these buttons or fields and on any of the forms, if I revert back to using the colour change code, it works everytime. 

Hi Paul.
SetStyle() work on the object name and OML work on the object. So when you use any Set command you will manipulate the first object in the object order in the compiled (RT) document. OML is mostly to complex and "programmy" for a lot of our users which is why we did the Set Class functions to allow users to do things more the DataEase way.

But what start off as easy very quickly become complicated when you want to do something "complicated". 

HighShade.color.red := 255 .

HighShade.color.green := 255 .

HighShade.color.blue := 255 .

This way of doing things is for most people "greek" and seems idiotic when for a computer it is brilliant because you tell it exactly what you want. 

With SetStyle we bascially exploit the features of the design tool and abstract the style from the look of the style so you can set the style and then if you change the style that change will permute the entire application. (like CSS in HTML).

If one prefer OML and the specific way of doing it that is great but if not then SetStyle and the SetClass is your thing (SetColor,SetLabelText,SetCurrent etc)

You are allowed to have the same object name on different levels so you can use MyLabel on Main Recod and SubRecord and SubForm and MainForm etc. as it will be classed. MyForm.MainRecord.MyLabel etc. 

When you define a subform you basically clone the first row, row times in RT so if the objetct is called CustomerName and you have 10 rows they will all be called CustomerName. SO if you have code that set style on CustomerName they will all set it on the first CUstomerName.

This is why you can do it like this: SetStyle("CustomerName#3","MyStyle). Then you will set it on the 3rd CustomerName.

THis has been discussed on the forum before and you can read more about it and find a sample in the thread.


http://www.dataease.com/DG3_ForumList/?ParentID=00...

I get the row number thing, each being different on this version.

So I changed code to this:

define "x" text .
if SESS_EndDate > current extended date then
x:=setstyle(concat("SESS_Date2#",GetCurrent("RowNumber")),"SubFormFieldLive") .
else
x:=setstyle(concat("SESS_Date2#",getcurrent("RowNumber")),"SubFormField") .
end .

and it now highlights row three only ...
I also added a virtual field to collect the actual row number, but with same results.
I tried various combinations with and without the wildcard.

These highlight lines are not meant to trigger when highlighted, but whenever there is data on the line.


The buttons in my example1 all have unique names. Some work, most do not. 
This is the same across most forms.

You have kind of put your hand in an ants nest here.

OML was never supposed to be "released" as its part of the internal model of DE rather than something that users should dab in. This is why it was not part of the original release. OML is a hybrid of compiled and interpreted code which makes things a little awkward.
You can't call GetCurrent("RowNumber")  in the code directly due to when things are computed and executed. 
If you combine OML with GUI functions like SetStyle you need to "trigger" DataEase dependency order. So to get this to work you need to have a virtual field that contain the derivation GetCurrent("RowNumber") and then pick that values with ObjectName.Value().

I guess you looked a the sample and thought we were just idiots that didn't call the function directly and wanted to improve it... I would, but its done this way for a very obvious reason when you start playing with it. I also think that when you use the GetCurrent("RowNumber") in a subform it will return 2 rather than 1 while used in a table list it will show 1. Another DE quirk I'm afraid. Its easy to think that we are idiots, but the problem is that we have to go around some long standing development "truths" in WIndows which make something that should and to the untrained eye should be simple very very hard. I guess it was done with the best of intentions in a euphoria of object oriented programming but in reality it is just plain stupid.

So the problem for us that when we are in one place of the code we don't know where we come from or where we are going which allow for these quirky solutions. Pure windows brilliance...

Yes, its very "hacky" but the entire purpose of 

OK, so the subform lines will be problematic. I can revert to the old way of doing this, that still works.

Buttons are the other setstyle problem area.

Example1 :

Main Form buttons using mouse over.

define "x" text .
x:=setstyle("CustomerDetailsButton","ASPButtonMouseOver") .

and on mouse exit

define "x" text .
x:=setstyle("CustomerDetailsButton","ASPButtonClearNoOutline") .

This works on some buttons on each form will work fine with this, but the other 95% just refuse to change style on mouseover/mouseexit. The same issue appears on all forms that use buttons.

On there own, the styles can be added to the button, just not switched.

These were added on the 'newer' DE9 that we had before going back to LE9. They worked flawlessly on that one.