wait 0 with messages

[FourthWorld]

...... waiting 0 with messages does add time to how long a handle takes, so for whatever reason its not really waiting 0.

Now help me please.

Until now I understood this as follows.
The "0" is the waiting time for executing the handle, the additional time you speak of is used elsewhere, for example for screen updates one wishes to have during the loop.
Certainly, if one wishes to have such updates, one has to wait some time more, in sum of small parts, until it's all done.

As far as I can see you wish now to make the windowing process responsive *all* the time during *all* handlers.
My humble computations say that this would sum up to a giant slow down of the whole engine.

What do I overlook with this point of view?

The quoted text is from makeshyft, but I can at least explain my own understanding of the situation:

Traditionally, things happening in an xTalk program are evident on screen, and when the developer wants to stop screen updates temporarily (such as for performance gain) we use "lock screen".

This was the convention with all xTalks for many years until LiveCode was ported to OS X, where apparently the Carbon APIs made it difficult to maintain this. The "wait 0" trick was arrived at as a workaround for that Mac problem, and apparently may be needed due to recent changes in the Win APIs as well.

The Mac issue was addressed in Bug Report #10333 - Mark Waddingham's notes there clarify his view, and on OS X we no longer need to use the "wait 0" workaround in v6.7 or 7.0, which use the Cocoa APIs:
http://quality.runrev.com/show_bug.cgi?id=10333

I've added myself as a CC to the report makeshyft submitted, and will be interested to see how the core dev team responds to this Win variant.

On Linux, things I do in my scripts are visible on screen until I explicitly request the screen be locked with "lock screen".

[[-hh]]

..........

[SparkOut]

The "wait 0" trick was arrived at as a workaround for that Mac problem, and apparently may be needed due to recent changes in the Win APIs as well.

I learnt very early on with RunRev on Windows (2.8 and XP onwards) that a wait with messages was required in a tight loop in order to avoid locking into an unresponsive application, so that the engine could redraw some element, or allow keyboard polling. This is what we are talking about here, isn't it? In the history of my experience it has never been a Mac only scenario. Or am I missing the point?

[FourthWorld]

SparkOut, do you see UI elements (like counters in loops) that don't update, or just the OS reporting that the app is unresponsive?

[SparkOut]

It's both as I recall, I don't have old versions (RunRev/Windows) to try on now. A test with LC 5.5.5 on Windows 7 just now shows a field and a scrollbar. Looping with i = 1 to 100000 and updating the field and thumposition of the scrollbar shows regular screen updates until approx. 8000, then the screen locks up, keyboard becomes unresponsive to ctrl+C and the spinning timer shows until the loop ends, where the field and thumpos both jump from the lockup point and update to 100000. It's become so ingrained to include a wait with messages in a loop I never thought to try without. It looks like I'm going to need to keep doing it.

[FourthWorld]

Thanks for the details, SparkOut. Definitely sounds like a bug to me, esp. considering how inconsistent the behavior is.

It may be helpful to add your notes to makeshyft's bug report:
http://quality.runrev.com/show_bug.cgi?id=13142

[makeshyft]

Its true, it becomes a bottleneck to try and maintain responsiveness, thats why I wanted to address it and find out if there is another way of ensuring that users don't try to close the non-responsive window. Its not good for a user's experience when the window goes non-responsive. (and says "not responding" in the title bar)

So my workaround is to have "turbo mode" where all screen updates are locked and th engine goes as fast as it can.

Also, luckily the loops are not as tight in the actual application ...... I ma about to run a test in a day or two ...... 100,000 user array. I will post some performance observations at some point. plan to do some performance testing of the engine using this process. until now i was just preparing my fake user list and had to run the tight loops that produce the problem. Now i'm rambling on.

Cheers,

Tom

[makeshyft]

The "wait 0" trick was arrived at as a workaround for that Mac problem, and apparently may be needed due to recent changes in the Win APIs as well.

I learnt very early on with RunRev on Windows (2.8 and XP onwards) that a wait with messages was required in a tight loop in order to avoid locking into an unresponsive application, so that the engine could redraw some element, or allow keyboard polling. This is what we are talking about here, isn't it? In the history of my experience it has never been a Mac only scenario. Or am I missing the point?

EXACTLY my experience too.