Here there are the history from the old BlackBox mailing list:Josef Templ wrote:@Helmut: do you know any details about this issue and its history?
Fair background processing
From: Marco Ciot
Date: 12. May 2006 22:37
Hi everybody
Here the changes I have made so far.
As I see they are minimal. For convenience I'm attaching the entire Files.
Remarks:
* The ASSERT 99 in HostPorts.Rider.Input is important to detect Actions calling Input.
* In TextControllers I just removed a very useless dummy call to Input.
* Services actually didn't need any changes as ActionHook.Step already skips cascaded calls.
Main Problem:
So far a Loop on Input would allow a tracking procedure to obtain the required user interaction without worry about the state of the system being changed.
As Actions might very much change the state and typically also will change the state of views or even replace views these Tracking Functions suddenly have to face some reality like "Oh, the view I just had under the mouse pointer is suddenly a different one!"
This is why I earlier said that Input should not be available at all. Instead the Tracking Messages should be handled differently. I am not 100% sure if this is possible in all cases and how big the change will be. But I guess this will be the first change I'll make to BB.
Regards
Marco
Text/Mod/Controllers
Host/Mod/Ports
System/Mod/Services
From: Alexander Iliin
Date: 24. May 2006 03:29
Hello, Marco!
MC> Here the changes I have made so far.
MC> As I see they are minimal. For convenience I'm attaching the entire Files.
MC> Remarks:
MC> * The ASSERT 99 in HostPorts.Rider.Input is important to detect Actions calling Input.
MC> * In TextControllers I just removed a very useless dummy call to Input.
Very useless indeed.
MC> * Services actually didn't need any changes as ActionHook.Step already skips cascaded calls.
For my use I replaced ASSERT with simple IF like here:
IF ~Services.ActionRunning() THEN (* ASSERT was here *)
ticks := Services.Ticks();
Services.actionHook.Step; (* mc:060325 *)
KERNEL32.Sleep(SHORT(MAX(20 - (Services.Ticks() - ticks), 0)));
END;
I did this after I discovered an Action object using Input. It was CpcControlTips.Action polling mouse coordinates in the background. I see no harm in such activity, so I just disabled the recursive call to Services.actionHook.Step and removed KERNEL32.Sleep which is unnecessary when called from an Action. So, this way Action objects may use Input as before, and the main application loop takes advantage of the patch.
MC> Main Problem:
MC> So far a Loop on Input would allow a tracking procedure to obtain the
MC> required user interaction without worry about the state of the system being changed.
MC> As Actions might very much change the state and typically also will change
MC> the state of views or even replace views these Tracking Functions suddenly
MC> have to face some reality like "Oh, the view I just had under the mouse
MC> pointer is suddenly a different one!"
MC> This is why I earlier said that Input should not be available at all.
MC> Instead the Tracking Messages should be handled differently.
MC> I am not 100% sure if this is possible in all cases and how big the change will be.
MC> But I guess this will be the first change I'll make to BB.
The Main Problem you mentioned suggests that changes should be quite big. (I thought of it before you introduced the patch, but I am just not so familiar with the framework to try to fix it.) In fact, a tracking procedure must copy and remember all information about the state of the system being changed, and then verify and update that information after every bit of tracking event. If the state in question was changed from outside the tracking procedure (like from an Action) - a decision must be made if the tracking should be aborted. Maybe some sort of mouse tracker objects need to be incorporated into the framework? Or can it be done using available hooks?
---=====---
Alexander