Page 2 of 2

Re: Controls linkage

Posted: Thu Dec 29, 2016 7:45 pm
by DGDanforth
Josef Templ wrote:If the dereferenced pointer is changed, this means that the
control must re-evaluate its link, which it is not doing.
This may be subject to improvement. I don't know how complicated it is, though.

In order to force a re-evaluation of all links you can call "Controls.Relink".

- Josef
Thank you very much. Controls.Relink does the job.
-Doug

Re: Controls linkage

Posted: Fri Dec 30, 2016 1:39 pm
by Zinn
I followed the discussion and I run Doug's example.
I observe no difference behaviour about using focus.x or focus^.x in the form.
Using Controls.Relink; works also without calling Dialog.UpdateReal(x); Dialog.UpdateReal(focus.x);
Should we mention in the documentation that Controls.Relink can be used for Dialog.Update?
- Helmut

Re: Controls linkage

Posted: Sat Dec 31, 2016 9:58 am
by Josef Templ
Right, Helmut, Controls.LookupPath treats the ^ as optional.

@Controls.Relink:
Isn't the need to call Controls.Relink a workaround for a limitation
imposed by a missing Dialog.UpdateXXX procedure.
Ideally, it should not be required in such a case.

The limitation is:
If the variable designator starts with (or contains) a pointer, e.g. TestForms.focus,
then it is not possible to notify an update of that pointer by means of calling something like
Dialog.UpdatePtr(TestForms.focus).
A corresponding Dialog.UpdateXXX is available for all basic types but not for pointers.

The question is if it is possible to introduce such a procedure.
I mean, without changing too much of the inner working of controls.
We have to look if Controls.LookupPath and/or Controls.HandleViewMsg
need to be adapted.

The Dialog.UpdatePtr Procedure would look like this:

Code: Select all

PROCEDURE UpdatePtr* (VAR x: SYSTEM.PTR);
  VAR adr: INTEGER;
BEGIN
  adr := SYSTEM.ADR(x);
  Notify(adr, adr + SIZE(SYSTEM.PTR), {update, guardCheck})
END UpdatePtr;
- Josef