On 14 Feb 2019, at 10:18 pm, Arnaud de Montard via 4D_Tech
>> Le 10 févr. 2019 à 18:41, Kirk Brooks via 4D_Tech <firstname.lastname@example.org> a
>> écrit :
>> Just to add a little more to this.
> Me too, forgot to mention CALL FORM: has a message queue, can
> Le 10 févr. 2019 à 18:41, Kirk Brooks via 4D_Tech <email@example.com> a
> écrit :
> Just to add a little more to this.
Me too, forgot to mention CALL FORM: has a message queue, can receive
parameters, can call its own window, allows to execute almost any method in the
context of the
Just to add a little more to this. I suspect a number of readers already
realized a really simple solution to this specific case is to simply test
the read/write state in the On timer form event and NOT update if it's read
This turns out to be a better solution in my case because it's a
Aha. That hadn't even occurred to me. I think that's exactly what I was
looking for. Off the top of my head I think using the On Before Data Entry
for listboxes and On before keystroke for fields.
On Fri, Feb 8, 2019 at 10:18 AM Arnaud de Montard via 4D_Tech <
> Le 8 févr. 2019 à 17:48, Kirk Brooks via 4D_Tech <firstname.lastname@example.org> a
> écrit :
> [...] Is there a way to trap use actions like that so I can block the
> On timer code from running?
Each new SET TIMER "kills" the previously set one, so it allows to postpone or
cancel next 'On timer'.
You can create an independent process that is hidden to user which simply wakes
up, does the calculation, and then calls the process. It you use IP variables
you can have them auto-update based on the call to the process. We do this for
projects that require this type of updatingno
Mail list logo