At 2:33 PM -0700 7/21/2004, Richard Gaskin wrote:
Run this test in the message box:
1. put the width of the templateGraphic
-- return 128
2. set the width of the templateGraphic to 500
3. put the width of the templateGraphic
-- return 500
Because any property changes are persistent throughout
On 20/7/04 10:55 pm, "Wouter" <[EMAIL PROTECTED]> wrote:
> Then in other words, RR itself is going down this slippery slope
> (looking at the script in the revmenubar and other rev stacks :-)
> Or the slope is not that slippery.
I think this is a valid concern. Its important that we make the IDE
Recently, "Richard Gaskin" wrote:
>>> < The properties of the templateGraphic are reset to their defaults
>>> when all running handlers finish executing. >
>>>
>>> which is obviously not the case (and I should have checked this).
>>
>>
>> No, the docs are correct on this point.
>
> Run this t
Jeanne A. E. DeVoto wrote:
At 8:37 PM +0200 7/21/2004, Wouter wrote:
But then there is an inconsistency in the transcript library where is
stated:
< The properties of the templateGraphic are reset to their defaults
when all running handlers finish executing. >
which is obviously not the case (a
At 8:37 PM +0200 7/21/2004, Wouter wrote:
But then there is an inconsistency in the transcript library where is stated:
< The properties of the templateGraphic are reset to their defaults
when all running handlers finish executing. >
which is obviously not the case (and I should have checked this
Wouter wrote:
Remember that long before your scripts become active the Rev IDE does
its initialization. While I haven't read the code for Rev's boot
sequence the evidence suggests that their IDE alters some properties
of the template graphic so that by the time your script comes into
play the
Re: alwaysBuffer not set...
•From: Richard Gaskin
• Subject: Re: alwaysBuffer not set...
• Date: Wed, 21 Jul 2004 10:16:19 -0700
-- snip
Remember that long before your scripts become active the Rev IDE does
its initialization. While I haven't
At 6:39 PM +0200 7/21/2004, Wouter wrote:
I agree that they are handled or used by the engine.
But the question still remains: where are those default template objects
physically (it's data) stored?
In the binary of the engine or in the binary of one or more stacks?
Template objects are never store
Wouter wrote:
Template objects are never stored per se; they live only in memory. The
property settings which define them are, in my understanding, hard-wired
into the code of the engine, and not in any stack file.
This is exactly the puzzling part.
If they are hardwired in the code of the engine
On 21 Jul 2004, at 18:00, [EMAIL PROTECTED] wrote:
Message: 3
Date: Wed, 21 Jul 2004 08:37:17 -0700
From: Richard Gaskin <[EMAIL PROTECTED]>
Subject: Re: alwaysBuffer not set...
To: Discussions on Metacard <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/
Wouter wrote:
The engine has no "face" of its own; that is, it has no windows or other
visible UI components of its own. It has only the Transcript
interpreter and a handful of data resources the interpeter needs (such
as the list of color names, month names, etc.).
Any visible element, such as a
Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 19:55:43 EDT 2004
* Previous message: alwaysBuffer not set...
* Next message: alwaysBuffer not set...
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Alain Farmer wrote:
> Wouter wrote:
>> I look at MC and RR as st
Hi Richard et al...
I agree with Richard, in fact, his often well-thought expression of
MetaCard's strict compliance to the vanilla is the primary reason why
I'm 'attempting' to switch to MC (I'm sure a first, going back to MC
from one who has started with RR:-)
I believe the alwaysBuffer shoul
Alain Farmer wrote:
Wouter wrote:
I look at MC and RR as stacks interacting with
an engine ... but the impression is growing that
what is called the engine, is something composed
of stacks and the engine. Where are the borders
between the IDE, stacks and the engine?
Very *VERY* good point, Wouter.
--- Wouter
> I look at MC and RR as stacks interacting with
> an engine ... but the impression is growing that
> what is called the engine, is something composed
> of stacks and the engine. Where are the borders
> between the IDE, stacks and the engine?
Very *VERY* good point, Wouter.
Where is
alwaysBuffer not set...
Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 16:13:47 EDT 2004
* Previous message: alwaysBuffer not set...
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wouter wrote:
--big snip
> If this is at engine level then the engine itself is maki
Wouter wrote:
Re-reading Chipp's post more carefully, he's referring only to IDE
stacks, and yes, the IDE stacks should have their alwaysBuffer set to
true.
Can anyone think of a reason not to? Unless someone tells me not to I'm
inclined to do it for the next release.
As for doing that for all new
alwaysBuffer not set...
Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 14:46:17 EDT 2004
-- snip
Re-reading Chipp's post more carefully, he's referring only to IDE
stacks, and yes, the IDE stacks should have their alwaysBuffer set to
true.
Can anyone think of a reason not to? Unless some
Wouter wrote:
> I noticed in the latest DL of MetaCard, the alwaysBuffer of most IDE
> stacks is not set. While this was not necessary in previous versions of
> the engine, it is now used to disable the 'flashing' effect around
> windowsXP look and feel.
>
> I recommend setting the alwaysBuffer of
alwaysBuffer not set...
Richard Gaskin ambassador at fourthworld.com
Tue Jul 20 12:27:24 EDT 2004
* Previous message: alwaysBuffer not set...
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Chipp Walters wrote:
> I noticed in the latest DL of MetaCard, the alwaysBuffer of m
Chipp Walters wrote:
I noticed in the latest DL of MetaCard, the alwaysBuffer of most IDE
stacks is not set. While this was not necessary in previous versions of
the engine, it is now used to disable the 'flashing' effect around
windowsXP look and feel.
I recommend setting the alwaysBuffer of a
21 matches
Mail list logo