I am creating / updating records in a sub-form using a DQL procedure. I wish to show the updated data and have tried using

RefreshScreen() both from the DQL procedure and via a button on the main form, but nothing seems to happen even though this function is supposed to refresh the screen from the saved data as I understand it. If I close the form and reopen it the data appears in the sub-form as expected. Maybe I am using the wrong function?  Any suggestions will be very welcome.

Thanks,

Bill Nicholson

There is plenty of different ways to achieve this, sadly none of them goes through RefreshScreen() or RefreshForm().

RefreshScreen() re-reads the main record and since the Relational Key has not changed it doesn't re-read the Subform. RefreshScreen() is an old function and should maybe be-revisited to improve it. We created RefreshForm() as part of DE8 development for the opposite reason of what you want. RefreshForm() is created to re-calculate the form without reading data from the data file. This is so changes in the form done by SetValue() or other similar functions can be re-computed without being interfered with by stored data.

So what you need to do is to trigger a change in the relational key so the subform is updated. How easy or hard that is, depends on how you execute your DQL (What type of DQL it is).

If it is ExecDQL it is easy, you can simply transfer the Key to the DQL via one of the Data-entry parameters and then use SetValue() to first blank and then re-set the relational key.

We did it directly on a button just to test where the key was ordernr.

SetVar("OrderNr",OrderNr)+SetValue("OrderNr","")+SetValue("OrderNr",GetVar("OrderNr"))

This one basically store the ordernr in a variable, clear ordernr and re-set it. This will trigger a re-read.

Just to illsutrate we also do it directly via an ExecDQL on a button.

ExecDQL("define /'retval/' text. retval :=SetValue(/'OrderNr/',/'/')+SetValue(/'OrderNr/',data-entry field1) .",OrderNr)

Obviously you need to do it as part of a bigger DQL (memo or label etc) but you should get the gist. The reason we use/' for " is that you are not allowed to use " in strings in Derivations so this is a new workaround in DE8. You obviously don't need to use this in MemoExecDQL or LabelExecDQL.

When you rework your DQL you simply do the SetValue() magic of the relational key at the end of the DQL (after all loops etc) so it is the last thing the DQL do before it finishes.

ExecDQL is part of the document from where you call it so you can do all kind of wizardry inside the form context with it. If you have used a Traditonal DQL you don't have this possibility as it has its own document context, then your best option is simply to close the form, open the procedure and then re-open the form with the correct record displayed. For this you need to use a virtual field, a couple of global Variables and the SelectionFilter() function.

This is a sample derivation in our form OrderHead to research the correct record:

if (GetVar("OrderSearch") not=blank, SelectionFilter(GetVar("OrderSearch"),"")+SetVar("OrderSearch",""),0)

This will only do something if there is a filter set in OrderSearch. It will then search up the record and never do anything again until next time this variable is set etc.

This is a much better way of opening "open related" than using Open Related too by the way as you can re-set the filter or clear it anytime you like inside the form. The problem with Open Related is that the relationship will always restrict the form.

Now you simply need to trigger it, we simply made a button from the form to do this, close the form and re-open it.

Setvar("OrderSearch",concat("OrderNr=",OrderNr))+DocumentClose()+DocumentOpen("OrderHead")

You obviously need to do your DQL magic in between ;-)

I am afraid that you are leaping ahead of me with several solutions none of which I can make work. There's a gulf between your level of understanding and that of the newbie developer in DE8. Let us start with the action button approach which should be the simplest but which still doesn't seem to work.

When the form opens I store the value of the unique key by the following OML statement (this is actually triggered by a virtual field / ValueLoaded event which I have found more reliable than an OpenForm event in previous incarnations of DE)

retval := SetVar("TransmittalNo",TN Ref) .

After the records have been written to the subform I try to refresh in accordance with your advice using the following button action:

SetValue("TN Ref","")+SetValue("TN Ref",GetVar("TransmittalNo"))

Apparently nothing happens, so I try the following enhanced button action which (a) checks that the SetVar value is still there (it is), and (b) adds a screen refresh in case that's the problem:

ExecDQL("message GetVar(/'TransmittalNo/') window .")+SetValue("TN Ref","")+SetValue("TN Ref",GetVar("TransmittalNo"))+RefreshScreen()

This still doesn't work. I am sorry that I am being so slow but I would appreciate assistance in getting to the bottom of this.

Bill Nicholson

There is a lot of possible sources for trouble here, so it is very difficult to spot it by simply getting the code.

1. Are you sure the object name of your fields are the same as the Field name? If you copy/change a field it doesn't change the Object Name. all set functions use the object name and that is also Case Sensitive.

2. Don't use OML. It is much better to simply use the Derivation of the virtual field to trigger action. you can simply use a derivation like SetVar("TransmittalNo",TN Ref) then it will be executed every time TN Ref change value.

3. RefreshScreen is irrelevant, to mix it into anything.

4. It is the change of the relational key for the Subform that is important that is why we change it to blank and back to the key it was originally. When that happens it re-read the subform.

Look at the sample I sent you for Multiple Returns on "open Related".

Download Sample

Many thanks for the time you have spent looking at this. I don't see any obvious errors on my part but will need to spend more time to get to the bottom of this. Roll on a new version of the RefreshScreen function which will circumvent this problem!

Bill Nicholson

We might be a little to stubborn in not "fixing" old functions. When we started this project one of the rules we made so we wouldn't get stuck in "fixing" DFW like it seems the team before us was for 15 years, we decided that DFW 7.2 worked "as is" and what we should focus on was to add the missing functionality.

We have however as things have progressed re-visited some old functions and improved them so I guess your suggestion that ScreenRefresh() could be fixed too is not a bad one. Not many useful forms in DFW doesn't have an element of subform so how this functions was designed this way in the first place is incomprehensible. One would almost think that the developers can't have tested their own creation... 

DataEase 8.5.0.2456 Released 11/08/16 have solved the problem with RefreshScreen().

All the hacks and workarounds are no longer necessary .

We are not completely sure when RefreshScreen() was introduced but most likely it has been around since the Dawn of DataDase for Windows (Express 1.0) and it has never worked.

RefreshScreen is a simple enough idea and when you think about the workarounds that have been "invented" by ingenious developers over the years one realise that this fix has been sorely missed and long awaited.

Now it is here and you can now - finally - refresh the data in your form without having to resort to witch craft.

Returning from a related form or from a pick list or whatever reason you have for refreshing the content of your form, now it is here.

Combine the Timer() with RefreshScreen() and you might be in position to deliver the next Arrivals/Departure screens for the Airports :-)