Easy to Create, Easy to Change - Easy to use!


DataEase 8.5 - Wait():Function and Timer():Event Where and When?

Started by DataEase
You will need to Sign In to be able to comment on the Blog!

DataEase 8.5 - Wait():Function and Timer():Event Where and When?

DataEase 8.x is an evolutionary developed project where we feed into our development model the experiences learnt earlier in the project.

The project obviously started with DataEase 7.x which in many if not all ways was a failed product.

Our approach to 8 was to fill in the gaps and cover all the bases so you could at least build a working application.

With a product like 7.x you could even analyse it to death, or simply get started and address the problems as they become clear.

We decided the latter, and it seems to have worked...

However, things will happen "incrementally" so not everything looks logical in hindsight.

One problem that was a nightmare in 7.x was the order of things.

When you fired a chain of actions on a button like. RecordSave()+DocumentClose()+DocumentOpen("NewForm)

You were never sure that they would happen in order.

You might end up in a situation that DocumentClosed() before it had saved Which either meant that you would get the "Do you want to save before closing" message box appeared or even worse GPF.

Or you might experience that the New document Opened before the old one had closed which in the world of WIndows Message Que means that you send the send the Close Signal to the new form...

I think you get the drift. A mess.

The reason for this is that Windows (and DataEase for WIndows) works on message ques, where one object post messages on the Que and then the recipient read it off the Que, but not in any particular order. The process that is first ready will take control.

So we got the "brilliant" idea to make a wait function that would hold everything off and give the processes time to be action-ed in the correct order.

so Wait() joined us.

WAIT() : Function

Wait has an argument in seconds Wait(1) will wait 1 second etc.

But it had a big flaw...

Wait (0.1) would mean not wait at all as the function didn't wait less than a second....

But again...

We had gotten it all wrong.

DataEase Wait for nobody, so by executing Wait() you basically just exacerbated the problem.

Wait woudln't stop DataEase to allow the function to finish, it would just stop and wait and things would happen around it and give the right toxic combination you would get the exact situation you had tried to avoid... GPF.

But just a last time.

It worked.

Like so many "revolutionary" inventions it did't work because we got it right but because we did it at all.

RecordSave()+wait(0.1)+DocumentClose()+wait(0.1)+DocumentOpen("NewForm)

Does not work because the function wait 1 tenth of a second before it fired the next blindly hoping that the first one had finished first with the head start it had been given. No. It worked because we now got EXACTLY what we had wanted from the start.

A designated FIRING ORDER.

So the delay in wait is insignificant. You could most likely use 0 since what happens is.

Firing function one. Function one finsihed. Wait (x) firing function two Function two finished. Wait(x).

Timer():Event

So what about Timing?

Obviously in an Multitasking OS you just cant tell everything to wait and then fire something after 5 minuted or 5 hours. You need to have a process that run its own course and then at execute at the given "trigger".

So our solution to this is to add a Timer() Event to the Form Object.

Each Form now has a Timer() that you can use as you please. It is called 10 times a second and you can do whatever you like on it, but obviously be a little "frugal".... You don't want to call something 10 times a second that take more than a 1/10 of a second to complete etc...

Also remember that each time it is triggered it is "fresh" so it don't remember or share any information with the previous triggered event. they are all unique.

So if you want to count or carry things over you need to use Setvar()/Getvar() not think that it remembers the value from last it was triggered.

Even though each form as its own Timer() event the timer runs independently of the form being visible/active/on top etc.

Also remember that all GUI function communicate with active window so if you do feedback to the form you need to use SetCurrent("ActiveForm","YourForm") before you start interacting.

The Timer() event is much much more than a simple timer. This is your control centre. From here you can control the entire application, run checks/supervise/close/open...do anything you want independent of what the user is currently doing.


Written by DataEase 10/08/16 at 09:44:20 Dataease [{8}]FIVE