allowInterrupts in version 2.7.2

[mvanhoudt]

Some of you have noticed that allowInterrupts has been set to true by default in the 2.7.2 IDE. This prevents you from interrupting scripts by pressing control-. (Windows) or command-. (Mac).

This is a bug and will be fixed shortly. In the mean time you can work around it by running:

Code: Select all

set the allowInterrupts to true

In the Message Box.

Tip: you can generally interrupt Revolution by sending it a signal (on Unix or Mac OS X), and this will allow you to interrupt even tight loops that don't accept an interruption from the keyboard (this can be useful with allowInterrupts both true and false).

Find out what process Revolution is by running top or by using ps with appropriate flags. Then run in a shell (eg the Terminal on Mac OS X),

kill -SIGHUP <pid>

Where <pid> is the ID of the Revolution process.

[FourthWorld]

Some of you have noticed that allowInterrupts has been set to true by default in the 2.7.2 IDE.

Actually the problem isn't in the IDE but in the engine, so this will affect all standalones and users of other Rev IDEs such as MetaCard, Galaxy, and others.

[mvanhoudt]

Any reason you say this is the case? The IDE currently has allowInterrupts set to false by default; setting it to true solves the problem. Whether or not you can always interrupt execution is an entirely different question.

[FourthWorld]

Any reason you say this is the case?

Yes: because it more accurately describes the scope of the problem.

There is a critical distinction between the IDE and the underlying engine, and confusing the two to be the same thing lies at the heart of a good many design, documentation, learnability, and technical issues.

In cases where a problem is limited to the IDE, the scope of the problem is relatively trivial: it may annoy the developer, but won't affect runtime behaviors of things the developer delivers to her clients and customers. Also, those who use other IDEs such as MetaCard or Galaxy are immune to IDE-specific anomalies.

In contrast, issues in the engine affect everyone, and for that reason are much more broader in scope and warrant higher priority. Engine issues affect all who rely on the engine in any form, including all developers using any IDE and -- much more significantly -- all end-users running applications made with Rev.

The allowInterrupts property is built into the engine. So while it affects the IDE, it's more accurately described as an engine issue than an IDE issue, because it affects runtime behaviors outside of the IDE.

[mvanhoudt]

I am aware of the difference between the IDE and the engine.

More specifically, the problem is in the IDE engine - where allowInterrupts is set to false on exit from the licensing code (this is a bug that has yet to be fixed).

The standalone engines have never been affected by this problem where allowInterrupts defaults to true as it always has.