Wait command weirdness

[acidjazz]

What's wrong with this code?

Code: Select all

on mouseUp
   put empty into field "results"
   repeat with i = 1 to 3
      repeat with j = 1 to 4
         put i && j && CR after field "results"
         wait for .1 second
      end repeat
   end repeat
end mouseUp

When I run it, the button stays blue for a couple of seconds, and then all the numbers pop up at once.

- Mark

[sefrojones]

I just tried this in LC 6.6.2/ Win7 64bit and It seems to be working here......
the result is

1 1
1 2
1 3
1 4
2 1
2 2
2 3
2 4
3 1
3 2
3 3
3 4

this is entered into the field 1 at a time....


--Sefro

[acidjazz]

I'm also using 6.6.2 but with Mac OSX 10.90.3

[Klaus]

Hi Mark,

you need to give the engine time to update the screen like this:
...
wait for .1 second WITH messages
...


Best

Klaus

[acidjazz]

You know what? It STILL doesn't work.

Here's the code, just as you suggested, Klaus, including the "with messages" suffix to the wait command:

Code: Select all

on mouseUp
   put empty into field "results"
   repeat with i = 1 to 3
      repeat with j = 1 to 4
         put i && j && CR after field "results"
         wait for .1 second with messages
      end repeat
   end repeat
end mouseUp

[bn]

Hi Mark,

try this:

Code: Select all

on mouseUp
   put empty into field "results"
   repeat with i = 1 to 3
      repeat with j = 1 to 4
         put i && j && CR after field "results"
         unlock screen
         wait for 30 milliseconds with messages
      end repeat
   end repeat
end mouseUp

This works for me on a Mac OSX 10.6.8 LC 6.6.2

Kind regards
Bernd

[acidjazz]

Bernd (and Klaus)

This does work, thank you! But why?

It would seem to indicate that the screen is locked by default. But, even if that's true, I would still think that I could place the unlock screen command at the top of the handler (before the repeat loop). But it doesn't. It's still "jumpy" when I place the command outside of the repeat loop. Thus, I can only conclude that the screen locks itself back up every iteration of the loop. I doubt this is true, but you can hopefully see how confused I am.

Thanks,
Mark

[bn]

Hi Mark,

from what I recall it has to do with Mac screen update. On the Windows side there seems to be no problem. But on a Mac it has to be made explicit.

It used to be like Klaus said: just a short wait with messages was enough for screen update.(just tested up to 6.6.1) But now (6.6.2) one has to explicitely add an unlock screen.

The technical reasons escape me.

Kind regards
Bernd

[acidjazz]

Interesting. Wouldn't this qualify as a bug?

Mark

[bn]

Wouldn't this qualify as a bug?

Well, it probably would. But which one, that unlock screen did not work in previous versions? Unlock screen would seem to be the most intuitive in this circumstance. But you always had to wait with messages to get the screen update. Unlock screen did not refresh the screen in a tight repeat loop.

Now you have to "wait with messages" and "unlock screen". Not at all intuitive.

But then I don't see many use cases for unfolding the filling of a field before the user in a repeat loop.

I am too undecided to file a bug report. Maybe someone else has a stronger opinon on this.

Kind regards
Bernd

[FourthWorld]

Any behaviors specific to OS X should probably be tested in v6.7, given the scope of the Cocoa changes.

[bn]

Hi Richard,

in 6.7 dp4 successive lines from a repeat loop display line by line without "wait with messages" or "unlock screen".

If I remember correctly you had an enhancement request/bug report regarding this behavior which had to be taken out of the built because of side effects in pre 6.7 versions.

So maybe we wait for the final release of 6.7 and live with the behavior pre 6.7.

Kind regards

Bernd

[FourthWorld]

So maybe we wait for the final release of 6.7 and live with the behavior pre 6.7.

On the contrary, the only way to make sure the final version of 6.7 no longer has funky Mac-specific workarounds is to begin working with the test version of 6.7 now.

After release, it'll be too late to fix things in time for release.

[acidjazz]

I'm afraid this conversation has surpassed my cognitive abilities, but I very much appreciate the (hopefully temporary) workaround, and hope that Mac OSx weirdness is not permanent.

Thanks,
Mark

[FourthWorld]

I'm afraid this conversation has surpassed my cognitive abilities, but I very much appreciate the (hopefully temporary) workaround, and hope that Mac OSx weirdness is not permanent.

There's a lot of history here with Carbon and such, but the bottom line is that if you work with v6.7, with the understanding that it's still in development, you'll be in a great position to identify and report any odd behaviors we don't want to see in the final release.