Well i have now taken the plunge and bought 8.2 and am now trying to learn new ways of doing things.

I have history fields and an OML on a button, which copies field B to field C, then field A to field B, then what i've entered in a field to field A.

Basically entering an added history while moving the current history down 1 line.

This is done like:

hist_s3.value := hist_s2.value .
hist_s2.value := hist_s1.value .
hist_s1.value := hist_s.value .

I'm trying to do the same using SetValue(), and/or ExcecDQL() on an 'Execute function/derivation' button but i can't find an example.

SetValue(hist_s3,hist_s2) does nothing.

ExecDQL("SetValue("hist_s20",hist_s19).") doesn't like my script lol.

As you can probably tell i haven't got a clue, i thinki need ExcelDQL but to set values i need SetValue, but don't know how or where i need quotes, full stops.

There  is nothing in the lexicon for SetValue, other than telling you what it is for there isn't even a format let alone an example.  The only example i can find is in the blog for a button to pop a message to a window which works.  The blog points to a format as 

SetValue("objectname",value)

So,

SetValue("hist_s3",hist_s2) seems to follow that ruling but does nothing.

SetValue(hist_s3,hist_s2) does nothing either.

Help please in how to lay this out as the help is no help :D thank you.

In 17 years of using dataease i've never come across this, and a calcuation (derivation) not working because the window i'm looking at isn't physically show the calculating field is deffintely a bug lol.  Imagine Excel not calculating a total at ther bottom of a spreadsheet because it was off screen!  Back to OML to manipulate stuff lol, a calcualtion not running because my field is off screen is well dangerous.

"window i'm looking at isn't physically show the calculating field is deffintely a bug lol. Imagine Excel not calculating a total at ther bottom of a spreadsheet because it was off screen! "

I wasn't specific enough. There is a execution hierarchy in DFW which is quite advanced, and the point of it is efficiency. This is why you can have a table with a "million" virtual fields etc but still create a report of view that only use a small part of them and it will be highly efficient.

You are never in danger of DataEase not calculating a total either because the field was off screen!

A field that is being dependent on in a visual field will always be derived, but a field that is independent of the visual columns will not be derived as this will save processing time.

There is plenty of known way to work around this "shortcoming". One well known one is simply to put all the support fields first in the tab order, that way they will be touched and computed, another is to keep them in the viewport and a third is to make the dummy dependent.

We use virtual field manipulation because for most people this is much more natural than OML, but if anyone find OML more efficient then there is nothing that should stop you from using it.

SetValue() is a GUI function to it use the object name i.e the name of the GUI object rather than the field (column) name.

SetValue(hist_s3,hist_s2) basically set the string value of hist_s2 into the GUI object named in hist_s3 and as there is no object with that name, nothing happens.

SetValue("hist_s3",hist_s2) will give you the result you wish for.

ExecDQL will parse and execute a valid DQL script. So if it won't run in the DQL compiler it won't run in execdql. 

as SetValue() is a function it need to be called as part of a "derivation" or being allocated to something.

ExecDQL("define /'retval/' text . retval := SetValue(/'hist_s20/',hist_s19) .") will work.

Remember that object names are cAsE SeNSITIVE and that you can't use " inside a string, which is why we create the escape codes /' will be interpreted as " inside a string.

Anyone found a fix for this bug or a workaround yet?  Putting fields in top left and as the first in tab order made no difference so it's nothing to do with hierachy.  Hoped to move forwards with the new stuff, never thought I's say this but the old stuff as buggy as it is can actually do what it's supposed to lol.

There is a fundamental difference between PRISM (TDF) and GUI (FRM).

PRISM is traditional DataEase where you work on column names, multi-views and data sets. Here you work horizontal on the data as a database.

GUI is basically the current visual presentation of the data. If you can't see it, you can't access it (with modification). Hidden fields are still accessible from a data view.

When you work in GUI you don't access the column, but the visible value presented in an object.

The object model is also CASE SenSiTIVE when the PRISM model is case-insensitive. 

The idea in DE8  is to make programming of forms/pages more ad-hoc and flexible, this is why everything is implemented as Functions.

OML use Methods, Properties, classes etc. These can only be used in OML which is very limiting. Functions are the most flexible part of DataEase as they can be used as part of a derivation, validation, OML, DQL etc.

The main executor of Manipulation in Forms are virtual fields. 

In GUI you have two types of virtual fields. PRISM virtual fields and GUI virtual fields.

For the sake of manipulation they are the same, but there is a significant difference. GUI virtual fields, can again be placed anywhere in any document. (Form, Report, Procedure) and outside the Record Object (PRISM virtual field is related to the multiview and follow the same restrictions as other PRISM columns (fields)).

So you can put a GUI virtual field on the First FORM object, and basically manipulate the Main Record object (hide, move, size, style etc).

This is revolutionary as you now have complete control over the GUI model.

ExecDQL with the more useful MemoExecDQL, LabelExecDQL, FileExecDQL is not immediately designed to manipulate forms, but because they have the context of the form (document) from where they are called, they can access the GUI objects as well as the PRISM object of its own Multiview.

It is  important to realise that a ExecDQL does not have the data (prism) context of the FORM, but the GUI context and the data context of its own multiview. This means that you can process data and put values back into the form with SetValue(), SetLabelText(), style - SetStyle() etc.

You wouldn't use ExecDQL in your case as simple manipulation is easily managed in a Derivation (Virtual field). 

Functions can be execute in a multitude of ways. so Adding them together SetState("MyObject",0)+SetStyle("MyLabel","NewStyle") and with advanced if threes.

ExecDQL you use if you are going to do looped manipulation or combine data manipulation with form manipulation/document manipulation.

My field names are the same as there object names, the reason dataease had a field name AND an object name was never explained back in datease 3.12 or something and as such I don't know why there are 2 names to deine an object so I always keep them the same.

SetValue("hist_s3",hist_s2) will give you the result you wish for.

An Execute function/derivation button with  that as the parameter does nothing.  All cases are correct.

But

as SetValue() is a function it need to be called as part of a "derivation" or being allocated to something.

ExecDQL("define /'retval/' text . retval := SetValue(/'hist_s20/',hist_s19) .") will work.

So I need ExecDQL with it?  ok, so an Execute function/derivation button with that as the parameter and I get the error invalid right side expression (it doesn't like hist_s19)

Object name is correct, as is the case, field name is the same as the obejct name so that is correct, as is the case, the button has execute function and the parameter is as told so that is correct. Sigh. All i  want to do is copy contents of one field into another,  I worked OML out through trial n error, but this is a nightmare, what i wouldn't give for a simple example in the lexicon.  Anyone know what is wrong this time?  I badly want to learn but everything i try i follow by the book word for word and to the letter but still get errors and failures.  I'm drowned by explanations with no working example to translate these explanations.  So simply, 

ExecDQL("define /'retval/' text . retval := SetValue(/'hist_s20/',hist_s19) .") will work.

So why doesn't it? :(

Create a sample app with the code you are trying to do, and upload it.

That way we know we talk about the same thing. 99% of the times when customers are persistent that they haven't done something wrong, they have but can't see it because they have been trying for too long, so when we get the app and look at it with fresh eyes the problem is normally solved in 10 seconds. Very often the customer solve it themselves when they create the "sample" app, because they then remove themselves from the context of the app with the problem.

SetValue() is the same as any other function. It can be called in a derivation in combination with any other function. It is when you try to call it from a DQL that you need to allocate it to a variable, or do it as part of a derivation.

I.e. you can do:
for Table;
Modify records
dummy := SetValue("Test","Test") .

and you can do 

for Table ;
list records
SetValue("Test","Test") .

and you can do

define "retval" text .

For Table ;

Retval := SetValue("Test","Test") .

But you cannot do a DQL that simply say:

SetValue("Test","Test") .

This is the same with all Functions.

Simon,

On the face of it your code should work. The only thought I have is that the desired changes may have taken place but not displayed on the screen so a RecordSave() or RefreshScreen() might help.

I detect the signs of frustration that I had in bucketloads when starting with DE8 (and still get on occasions) and will tell you the approach which has generally worked for me.

1. If a particular function or construct isn't working create a test application which you can focus on. A good place to start is one of the DE sample applications which embodies the features you are looking for. If you can get it to work in the test application then it must work in the main application too.

2. If you are manipulating data then a DQL procedure is still the most proven approach. One of the advantages is that the code is checked for you in the editor.  Of course you have to point a DQL procedure to the current record which isn't necessary using OML. This is easily achieved - firstly create a global variable using OML (e.g retval := SetVar("RecordID",RecordID))  and in the DQL procedure you start with for Table with RecordID = GetVar("RecordID") ;

3. OML is tricky and doesn't always work as predicted. The triggering is particularly quirky (covered in other posts on this forum), sometimes triggering more times than you think and on other occasions not triggering at all. A message statement saying "we are here" will tell you what is happening. The only events I use are ValueLoaded and Clicked.

4. If the code is proving to be extremely awkward there's no substitute for multiple message (debugging) statements, after each line if necessary.

5. There are inexplicable occasions when DQL coding doesn't work as a single procedure so be prepared to break it down into multiple procedures. Get each one working and tested individually and then string them together.

6. If it still isn't working then move onto to something else for a few days and come back to it with a fresh mind!

The official DE approach is to make greater use of virtual fields and buttons which are slick when they work. My advice is to use them for manipulating the GUI and to use DQL for data manipulation.  I transfer tested DQL into MemoExecDQL procedures if they are to be called from multiple forms, or to LabelExecDQL if they are only needed in a single form. This simplifies the administration of a large number of DQL procedures which becomes complicated if you only use the Catalogue. Using MemoExecDQL you can create a memo field in the DQL store for your programmer's notes which can be very helpful.

I hope this helps.

Bill N.

Thank you both :)  I'm pretty much folllowing the rules but Bill you found the problem straight off.  RecordSave() needed to be adding.  DataEase did the change but didn't think i needed to see it, only once the existing record was saved did it think it was a good ideas to show me what clicking a button did -facepalm-.  At least now I know I WAS on the right track which is a nice feeling! and yes i'm trying to stay calm for a change amidst a lot of frustration lol.

Seems I need to think of these new functions in FIELDS as other 'derived' fields. They only show/do anything when you hit save. Thank you Bill, you've saved my sanity!

I agree OML is temperamental and is why i'm moving away from it, and like you I only try to use value loaded and clicked.

I also use debug messages when stuck to try to see what state fields and variables are at etc :)

Mr DataEase you will see i didn't call it a bug this time time, i knew I was missing something as i've learnt that De8 just has a bigger learning curve and is better behaved that previous incarnations which is a big turnaround lol.

Telling me that when I call it from a DQL is WHEN I need to allocate it to a variable is a big help and i didn;t know that so that will help me in future :) and i've made a note of it.

The fact i've bought De8 means I have more faith in it than I have in years which is also a break through, and I thank you all for your help.

Hi Simon!

It is still a BUG, it is just the paternity we are disputing ;-)

RefreshForm() will refresh the GUI objects without hitting on the database, so any manipulation done in the form that is not yet saved etc, will be refreshed. This is necessary after running Memo Manipulations etc in a form.

RefreshScreen() is re-reading data from the table, so if someone else (or a DQL has changed the data for that form) it will be re-read. (PRISM).

The value in a field set with SetValue() will in most cases be visible, but due to the priority and order of a DE form sometimes it might not.

Derived fields that is based on the changed value however will always be re-calculated as they are dependent on the PRISM value.

Virtual fields will be fired on Load, Save, Refresh and if a field they depend on has changed. If not they will not change or re-calculate.

Another bug in when this I've just found, is the size of your window determines IF it will read a 

SetState derivation in a virtual control field / IF it will update the screen based on these derviations as you go through records.

FULL SCREEN - correct:

DOCKED TO THE LEFT AS A WINDOW - WRONG (the blue and red warning doesn't show):

So So Simon. Now we must be careful with what we call a "bug" ;-)

It is part of the DataEase Hierarchy that it will not derive fields that is outside the viewport i.e. the visible part of the form. As virtual field manipulation is by definition derivations you need to insure that they stay within the defined viewport.

Virtual fields that is inside the "original" viewport i.e. the one defined by the size of the window will always be derived. This is why we always make sure that the manipulator fields is as close to the upper left corner as practical.