check box buttons

[Stgecft]

when I  doMenu "New Card", All of my fields (Groups)that have background 
behavior set to true copy fine  --The check box buttons also copy over but I 
want them to work independntly on each page.  They currently all check when 1 
is checked.  What is the trick to have grouped check box buttons placed so 
they work independently from previous pages.

Randy Kent
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: check box buttons

[Klaus Major]

Hi Randy,

> when I  doMenu "New Card", All of my fields (Groups)that have background
> behavior set to true copy fine  --The check box buttons also copy over 
> but I
> want them to work independntly on each page.  They currently all check 
> when 1
> is checked.  What is the trick to have grouped check box buttons placed 
> so
> they work independently from previous pages.

Well, actually it's a secret formula, which has to be spoken at midnight 
on
an old pet-cemetary... (No, i am just kidding :-D

> Randy Kent

in the property-palette -> button uncheck "Share Hilite on Each Card" for
each button in your group.

That should do the trick...


Regards


Klaus Major
[EMAIL PROTECTED]

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Window positions

[Richard D. Miller]

In the runtime mode (i.e. when starting up and running with a standalone
stack and associated stacks), will Rev automatically update and save the
topleft position of stacks under Windows, or must this be updated by script?
I thought saving was automatic.

We have users telling us they believe they are moving stacks to certain
positions on the screen, shutting them down, then re-opening them, only to
find they are not re-opening to the last location where they had left them.
I'd like to hear feedback on this behavior.

Thanks.

-- 
Richard Miller
The Wood Exchange.info
http://www.thewoodexchange.info
802-238-5355
802-951-2534 fax

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problem with Launch Command

[Ian Summerfield]

On 21/2/02 9:40 am, "Peter Reid" <[EMAIL PROTECTED]> scribed:

> Whilst Ben's idea looks good, it only provides a Mac solution, not a
> Windows one, so I put this to one side for now until I've exhausted
> any dual platform solutions.  Also, I have a slight concern about
> using AppleScript as to whether I can absolutely rely on the Mac
> users' system having the full AppleScript support installed?

The concern is only the same as having to wonder whether Quicktime is
installed before playing a movie.  But to check it is easy:

Open preopenstack
  if "AppleScript" is not in the alternateLanguages then
beep
answer "Applescript needs to be installed for this program to function."
quit
  end if
End preopenstack

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

controlkeydown

[Pierre Delain]

Finally I found two efficient structures :

on controlKeyDown LaClef
if LaClef = "T" then
  MuThemes
else if LaClef = "F" then
  beep
else if LaClef = "Y" then
  beep
  beep
else
  pass controlkeydown
end if
end controlKeyDown

and :

on controlKeyDown LaClef
  switch LaClef
  case T
MuThemes
break
  case F
beep
break
  case Y
beep
beep
break
  default
pass controlKeyDown
  end switch
end controlKeyDown


Thank you everybody

Pierre

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Problem with Launch Command

[Peter Reid]

>On 21/2/02 9:40 am, "Peter Reid" <[EMAIL PROTECTED]> scribed:
>
>>  Whilst Ben's idea looks good, it only provides a Mac solution, not a
>>  Windows one, so I put this to one side for now until I've exhausted
>>  any dual platform solutions.  Also, I have a slight concern about
>>  using AppleScript as to whether I can absolutely rely on the Mac
>>  users' system having the full AppleScript support installed?
>
>The concern is only the same as having to wonder whether Quicktime is
>installed before playing a movie.  But to check it is easy:
>
>Open preopenstack
>   if "AppleScript" is not in the alternateLanguages then
> beep
> answer "Applescript needs to be installed for this program to function."
> quit
>   end if
>End preopenstack

OK Ian, I agree the AppleScript worry is not a big issue!  However, 
it still leaves Windows!!

The ext_appsOpen() function in the current Externals collection for 
Mac OS Classic & X lists all open programs.  So it should be possible 
to detect whether some form of Acrobat viewer is already open on the 
Mac.  Once again, this leaves Windows to be solved!

Cheers

Peter
-- 
Peter Reid
Reid-IT Limited, Loughborough, Leics., UK
Tel: +44 (0)1509 268843 Fax: +44 (0)870 052 7576
E-mail: [EMAIL PROTECTED]
Web: http://www.reidit.co.uk
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Cross-platform Open Default Acrobat Viewer

[Peter Reid]

Thanks to advice from others on this list, I now have a 
cross-platform (Mac OS Classic, Mac OS X, Windows) solution to 
opening the default Acrobat viewer application such that it can stay 
open in the background and open successive Acrobat files by the use 
of the "launch sample.pdf with acrobatViewer" command.

The following is the stack script of my mini app that launches the 
default Acrobat viewer and then quits leaving the viewer running:

constant \
 cSamplePDF = "sample.pdf", \
 cXexternalsStack = "xExternals.rev", \
 cClassicExternalsStack = "ClassicExternals.rev"

on preOpenStack
   global gAcrobatViewer, gProgPath
   -- find current program folder:
   put the fileName of this stack into gProgPath
   set itemDelimiter to "/"
   delete last item of gProgPath
   put "/" after gProgPath

   if "Win" is in the platform then
 -- find default Win Acrobat viewer:
 put word 1 to -2 of \
 
queryRegistry("HKEY_CLASSES_ROOT\AcroExch.Document\shell\open\command\") 
\
 into gAcrobatViewer
   else
 -- find default Mac Acrobat viewer:
 -- activate appropriate Externals:
 put the systemVersion into sysVers
 set itemDelimiter to "."
 if item 1 of sysVers >= 10 then
   start using stack (gProgPath & cXexternalsStack)
 else
   start using stack (gProgPath & cClassicExternalsStack)
 end if
 -- get path of Mac Acrobat viewer:
 set itemDelimiter to gModuleListSep
 put gProgPath & cSamplePDF into samplePDF
 put ext_doctoapp(samplePDF) into gAcrobatViewer
   end if

   -- open default Acrobat viewer & quit:
   if the environment is not "development" then
 launch gAcrobatViewer
 quit
   end if
end preOpenStack

This uses the Externals that can be downloaded from the RunRev web site at:

 
http://www.runrev.com/revolution/developers/developerdownloads/externalscollection.html

The two stacks named in the "constants" section ("xExternals.rev" and 
"ClassicExternals.rev") are empty except that they have had the 
relevant version of the Mac Externals installed into them.  Note that 
you MUST be running Mac OS Classic when installing the Classic 
Externals and running Mac OS X when installing the X Externals.  If 
you attempt to open the wrong Externals for the current OS, Rev will 
crash out!

For Windows, the mini app simply interrogates the registry to get the 
details of the default Acrobat viewer app.  For the Mac, the above 
"starts using ..." the externals stack which is appropriate for the 
currently running version of Mac OS and then uses the 
"ext_docToApp()" function to get the name of the default Acrobat 
viewer.  For this to work you need to supply the name of an existing 
Acrobat file - "sample.pdf".

So, I have the following files in the same folder:

AcrobatLauncher.exe - Win standalone Acrobat Launcher (1.6Mb)

AcrobatLauncherClassic  - Mac OS Classic standalone Acrobat Launcher (3.9Mb)

AcrobatLauncherX- Mac OS X standalone Acrobat Launcher (2.4Mb)

ClassicExternals.rev- Rev stack containing Mac OS Classic 
Externals (52Kb)

xExternals.rev  - Rev stack containing Mac OS X Externals (52Kb)

Sample.pdf  - tiny Acrobat file, content is irrelevant (72Kb)

My main app uses similar code to the above to determine the path of 
the default Acrobat viewer app for use with the "launch" command.

Note that using the "ext_appsOpen()" function in the Mac Externals, 
it's possible to check whether an Acrobat viewer app is already 
running prior to running AcrobatLauncher.  Unfortunately, I still 
don't know how to do the same thing for Windows as yet.

Thanks to everyone who's contributed to this, I hope the above is of 
help to anyone else trying to do the same thing (or something similar 
with "launching" of apps).

Cheers

Peter
-- 
Peter Reid
Reid-IT Limited, Loughborough, Leics., UK
Tel: +44 (0)1509 268843 Fax: +44 (0)870 052 7576
E-mail: [EMAIL PROTECTED]
Web: http://www.reidit.co.uk
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: answer/ask

[Robert Presender]

Sarah wrote on 21 Feb 2002 (snip)
> Problem 1:
> The answer dialog box appears to be off screen (v1.1 and 1.1.1B1). Screen res
> 640x480 Mac OS 9.2.2,PB G3.  Don't know how to reference 'answer dialog box'
> so that  it can be used in the msg box to set the location say to 200,200. Ex:
> set the loc of '?' to 200,200.  Is this a bug?  Ask dialog box appears ok.
You can read the loc using
put the loc of stack "Answer Dialog"
but unlike in HyperCard, it doesn't seem possible to change it. The script
gives no error but setting the loc doesn't stick.

Thanks for the info Sarah.  Found what the problem was. The answer stack property
was set to 'always buffer'. Reset it to 'destroy window' (the same as 'Ask'). The
answer dialog box now appears ok.  The loc was aways correct but the box didn't show.

Wonder if this is a bug.  This is the first time that I looked at the stack properties 
of answer and ask.

Regards ... Bob

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Do's and Dont's

[JohnRule]

Thank you Scott for the 'stuff to avoid' list:

>Yes.  The full list of functions to avoid because they are deprecated is:
>the mouse
>the mouseClick
>the mouseH
>the mouseV
>the mouseLoc
>the optionKey
>the commandKey
>the controlKey

Could you please provide a list of what to use instead'?
And as a side note, I have been successfully using:

if the controlKey is down then
-- do this
end if

if the altKey is down then
-- do that
end if

I am not checking any combinations of keys, but I am checking this condition 
within a mouseDown and mouseUp handler. Is this bad? What do I use instead?

Thanks,
JR
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

imageData

[Matt Denton]

Dear Jeanne

imageData is missing out of the Transcript index, apologies if you have 
this one noted.

Cheers,

M@

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Polling the mouse

[Jim Hurley]

Title: Polling the mouse


Jim Hurley wrote:


> I regularly use "repeat until the mouseClick" without
the same
> problems I experience with the mouse function. My question is:
Does
> the advice to stay away from polling the mouse extend to the
> mouseClick function as well? Scott has warned that the
mouse()
> function may/will be discontinued. How about mouseClick()? Is it
also
> in jeopardy?


Scott Rainey wrote:

Yes.  The full list of functions to
avoid because they are deprecated is:
the mouse
the mouseClick
the mouseH
the mouseV
the mouseLoc
the optionKey
the commandKey
the controlKey

And the very worst thing to do with any of these is "repeat
until
", which will condemn you to the fires of eternal
damnation
in multiuser hell ;-)

The last 3 can be safely acquired with "the keysDown", but
be careful
to not sit in a repeat loop calling that or you may hang your app
or
at the very least have the gods of multiuser development strike
you
down.

And while we're on the subject of bad technique that will cause
you
grief at some point, also avoid using the following
messages:
mouseStillDown
mouseWithin
idle

That's it.  Not a long list, and in all cases it's very easy (I
would
even in most cases say trivial) to do it the right way.  A small
price
to pay for shrugging off the last of the circa 1984 single-user
single-tasking design of MacOS and HyperCard.
  Regards,
    Scott

After 35 years as a professor of physics,
it has been my experience that trivial is in the mind of the
beholder.

Scott is quite right is pressing *developers* not to anger the
"gods of multi-user development." But there is also another
class of user, one to which Run Rev is trying to appeal, and that is
the *student* who is using HyperTalk as a computer language--perhaps
as young as eighth grade. And this user would be programming in the
development environment and would be unconcerned with tying up the
CPU.

For some time I have been using HC, MC
and/or RR to build Turtle Graphics into HyperTalk and allow grade
school students to use the package to program their own solutions to
problems in mathematics and physics. There are two areas in this work
in which HyperCard is quite superior to MC or RR. (And there are many
others, of course, in which MC and RR are infinitely superior to HC.)
The most serious problem is the glacial speed with which MC draws
images (in many cases this problem is lethal) and the second, and much
less important, is the problems students have in polling the
mouse.

There appears to be no remedy in the offing
to the speed problem. However, regarding mouse-polling, my earlier
question dealt with the reliability and continued viability of the
mouseClick function.

As an example, students create a button
which, when clicked, sends a satellite on its way into orbit around
the earth--leaving a line in its wake to show the trajectory. (The
student has programmed the turtle to obey the laws of Newtonian
gravity.) When the student is satisfied with the length of the
trajectory, he or she clicks again (anywhere on the screen) to stop
the process. This is accomplished with a "repeat until the
mouseClick" or "if the mouseClick then exit
repeat."

So my question is three-fold:

1. Is this a reliable operation given the current state of the MC
engine? That is, is there a bug similar to that in "repeat until
the mouse is down?"
2. We know that we may lose the mouse() function in the future. Is
mouseClick vulnerable as well?
3. If mouseClick will not be an option, what is the work-around so
that the student may click anywhere on the screen to exit a repeat
loop, and hopefully one which is simple enough for an eighth grader to
discover? (Since the student clicked the button to start the process,
it is more natural to click again to stop the process. It would be
awkward to have to move to the keyboard.)

Jim Hurley

-- 
Jim Hurley

Re: Missing hidden characters and htmlText

[Matt Denton]

On Wednesday, February 20, 2002, at 06:50  PM, "Jeanne A. E. DeVoto" 
<[EMAIL PROTECTED]> wrote:

> At 12:18 AM -0800 2/19/2002, Matt Denton wrote:
>> I can't find a way to keep the 'hidden' character of a field that has
>> the imageSource set for it.
>
> I think you'll find this is fixed in 1.1.1b1. (The hidden character, in 
> the
> htmlText, is replaced by a tag of the form .)

Thanks for your help but...

Do you mean the 1.1.1b1 I'm running now?  The problem still exists, any 
operations performed on the  htmlText of a field destroy the character 
behind the imageSource.

Try this:

Create a field, put "This is some text" into it

Type:

set the imageSource of char 1 of fld 1 to "arrow" -- or some id 
that exists

...we now have "his is some text" with the hidden letter 'T' 'holding' 
the image, correct?

Create a 2nd field to display some results in.

We can get the full text by typing:

put the text of fld 1 into fld "results"

... the result is 'This is some text' and we are happy.  For the moment.

Also try:

put the htmlText of fld 1 into fld  "results"

... and we get:

his is some text

PROBLEM occurs when we do something like:

put the htmlText of fld 1 into lNewText -- pull the html text out 
for manipulation
put lNewText &return& lNewText into lNewText -- manipulate the 
formatted text
set the htmlText of fld 1 to lNewText -- restore the field after 
manipulation

If we then try:

put the text of fld 1 into fld  "results"

we get:

his is some text
his is some text

and the 'T' is gone FOREVER.  I've tried every variation I can think of 
to try and 'keep' the hidden 'graphic' character when manipulating 
formatted HTML text in and out of a field.  No luck.  In theory using a 
repeat loop could gobble up every char in your field.

Anyone know how I can solve this problem?

SUGGESTION: perhaps the htmlText could have an additional 'alt text' 
tag, similar to HTML holding the 'hidden' character that would be 
persistent when restoring the character after performing manipulations 
on the htmlText property.

Otherwise I'm at a loss.

Thanks for any and all suggestions,

Cheers,


M@
Matt Denton







___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse state

[Jacqueline Landman Gay]

> At 4:37 AM + 2/21/02, Ian Summerfield wrote:

>> Using the mousemove is no good.   I want to suspect all the messages from
>> happening while I'm dragging a pin around on my timer plug.  With 
>> mousemove
>> I'm effectively dropping back to an "idle" state between each call,  I 
>> need
>> to stay in the handler,  to do that I'm back to checking myself whether 
>> the
>> mouse is still down or not.

Doesn't "grab" do what you want? I think it suspends other messages while 
the user is dragging and automatically exits when the user lets go of the 
mouse button.

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Unique Macintosh Identification

[Ken Ray]

This is slightly off-topic, but does anyone know how to uniquely identify a 
Mac? We're trying to set up a specific install that works on a set number of 
machines by getting a unique ID for the machine and using it to verify that the 
machine is "licensed". This doesn't have to specifically be through MetaCard (it 
could be AppleScript, XCMD, gestalt selector, etc.).
 
Thanks!
 
Ken RaySons of Thunder SoftwareEmail: [EMAIL PROTECTED]Web Site: http://www.sonsothunder.com/

Re: Unique Macintosh Identification

[Roger . E . Eller]

> This is slightly off-topic, but does anyone know how to uniquely identify
a  Mac?
>  We're trying to set up a specific install that works on a set number of
machines
> by getting a unique ID for the machine and using it to verify that the
machine is
> "licensed". This doesn't have to specifically be through MetaCard (it
could be
> AppleScript, XCMD, gestalt selector, etc.).

The following information is not from me. This was a previous topic of
discussion here, and I saved it for my own future reference. It appears to
address what you want to do.

~Roger Eller  <[EMAIL PROTECTED]>


>>>I'd appreciate hearing any thoughts on ways to build in serial number
>>>protection...at least into one main opening stack.
>>
>> Hi Richard,
>>
>> Before I describe my approach, let me point out its limitations:
>>
>> 1.  It is Mac-specific.
>>
>> 2.  It only works on hardware/OS combos where the Apple System Profiler
>> returns the computer serial number.
>>
>> 3.  It works for me because my product is designed and priced for a
limited
>> marketplace.
>>
>> That being said, the AppleScript script:
>>
>> on getSerial()
>>   tell application "Apple System Profiler"
>>launch
>>copy SerialNumber to myNumber
>>quit application "Apple System Profiler"
>>   end tell
>>   return myNumber
>> end getSerial
>>
>> will return the Mac's serial #.  (BTW, Apple System Profiler does NOT
quit;
>> but that's another issue.)
>>
>> When a winemaker orders, or subscribes to, OenoLog, the license is
specific
>> to the her/his Mac by serial number...which he/she retrieves using the
>> System Profiler and includes on the order form.  I burn a CD for that
>> specific installation with the serial # encrypted in the stack.
>>
>> As I look to the future, I must determine which of the Mac-specific
>> features in OenoLog can be reprogramed to be platform independent, and
>> which must be given up if I am to achieve cross-platform compatability.
It
>> would be nice if Revolution had a built-in method of uniquely
identifying
>> the computer it's running on.  Some people have suggested the Ethernet
>> address as a possibility; but for my purposes the serial # is more
easily
>> retrieved by the user.
>>
>> I'd be happy to participate in any effort address the issue by RunRev or
>> MetaCard staff and/or users.  I'd also be interested in hearing from
anyone
>> who knows what toolbox call ASP uses to retrieve the serial # (some
>> argument to gestalt(??)).  If I knew that, I could ditch AppleScript;
but
>> I'm too cheap to pay Apple $200 so I can ask them directly.
>>
>> Rob Cozens
>> CCW, Serendipity Software Company


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Window positions

[Scott Rossi]

On Thursday, February 21, 2002, at 03:46  AM, Richard D. Miller wrote:

> In the runtime mode (i.e. when starting up and running with a standalone
> stack and associated stacks), will Rev automatically update and save the
> topleft position of stacks under Windows, or must this be updated by 
> script?
> I thought saving was automatic.
>
> We have users telling us they believe they are moving stacks to certain
> positions on the screen, shutting them down, then re-opening them, only 
> to
> find they are not re-opening to the last location where they had left 
> them.
> I'd like to hear feedback on this behavior.

Stacks need to be saved in order to have window positioned saved.  
Window positions cannot be saved in standalones but you can set windows 
positions in a preOpenStack handler.

Regards,

Scott Rossi
Creative Director, Tactile Media
[EMAIL PROTECTED]
http://www.tactilemedia.com

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse

[Roger . E . Eller]

I must voice my opinion:

The "gods" of programming may say it is a bad practice to program in a
certain way, using certain functions under certain circumstances.
This may be true.   *BUT*
There also may be legitimate uses for the "bad practices" for which there
may be no alternative.
I would rather see the functions remain viable for use at THE DEVELOPERS
DISCRETION.
Otherwise, it is kind of like saying everyone HAS TO USE Microsoft
products.
oops! I forgot...  That one *IS* already being enforced.
That's my 2 cents worth... Let the games (or flames) begin.

~Roger Eller  <[EMAIL PROTECTED]>

> Scott Rainey wrote:
>
> Yes.  The full list of functions to avoid because they are deprecated is:
> the mouse
> the mouseClick
> the mouseH
> the mouseV
> the mouseLoc
> the optionKey
> the commandKey
> the controlKey


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Applescript that sends mail.. (urgent)?

[Almesjö]

Sorry if this is a bit offtopic, but I need an Applescript that sends an
e-mail using Outlook Express (or other common, preferably free mailprogram
on Mac). Anyone knows how to do it? It's for an article and the deadline
is just about now..
thanks,
/Niklas Almesjö

__
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse

[Klaus Major]

Hi Roger,

> I must voice my opinion:
>
> The "gods" of programming may say it is a bad practice to program in a
> certain way, using certain functions under certain circumstances.
> This may be true.   *BUT*
> There also may be legitimate uses for the "bad practices" for which 
> there
> may be no alternative.
> I would rather see the functions remain viable for use at THE DEVELOPERS
> DISCRETION.
> Otherwise, it is kind of like saying everyone HAS TO USE Microsoft
> products.
> oops! I forgot...  That one *IS* already being enforced.
> That's my 2 cents worth... Let the games (or flames) begin.
>
> ~Roger Eller  <[EMAIL PROTECTED]>
>
>> Scott Rainey wrote:
>>
>> Yes.  The full list of functions to avoid because they are deprecated 
>> is:
>> the mouse
>> the mouseClick
>> the mouseH
>> the mouseV
>> the mouseLoc
>> the optionKey
>> the commandKey
>> the controlKey

this is an advice and not a dogma ;-)

C'mon, don't we all consciously and happily kill several
million brain-cells from time to time, somehow ?

(That was a metaphore :-)


Regards from germany

Klaus Major
[EMAIL PROTECTED]

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Missing hidden characters and htmlText

[Howard Bornstein]

Apparently the conversion to htmltext kills the reference to the "hidden" 
character.

For example, put this in a button:

on mouseup
  put "This is some text" into fld 1
  set the imageSource of char 1 of fld 1 to "arrow"

  put the htmlText of fld 1 into lNewText 

  set the htmlText of fld "results" to lNewText
  
  set the imageSource of char 1 of fld 1 to empty
  
  set the imageSource of char 1 of fld "results" to empty
  
end mouseup

The T is restored in fld 1 but is not restored in fld "results". It looks 
like you'll have to keep track of the hidden character yourself and 
restore it manually after an html conversion.

:-(

Howard Bornstein

D E S I G N  E Q
www.designeq.com


>Try this:
>
>Create a field, put "This is some text" into it
>
>Type:
>
>   set the imageSource of char 1 of fld 1 to "arrow" -- or some id 
>that exists
>
>...we now have "his is some text" with the hidden letter 'T' 'holding' 
>the image, correct?
>
>Create a 2nd field to display some results in.
>
>We can get the full text by typing:
>
>   put the text of fld 1 into fld "results"
>
>... the result is 'This is some text' and we are happy.  For the moment.
>
>Also try:
>
>   put the htmlText of fld 1 into fld  "results"
>
>... and we get:
>
>his is some text
>
>PROBLEM occurs when we do something like:
>
>   put the htmlText of fld 1 into lNewText -- pull the html text out 
>for manipulation
>   put lNewText &return& lNewText into lNewText -- manipulate the 
>formatted text
>   set the htmlText of fld 1 to lNewText -- restore the field after 
>manipulation
>
>If we then try:
>
>   put the text of fld 1 into fld  "results"
>
>we get:
>
>his is some text
>his is some text
>
>and the 'T' is gone FOREVER.
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Unique Macintosh Identification

[Ken Ray]

Thanks, Roger. Unfortunately it means I'd need to launch another app and
then make it quit just to get the serial number. Perhaps there's a gestalt
reference out there? Then I could use a gestalt XCMD or equivalent...

Ken Ray
Sons of Thunder Software
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 21, 2002 11:43 AM
Subject: Re: Unique Macintosh Identification


>
> > This is slightly off-topic, but does anyone know how to uniquely
identify
> a  Mac?
> >  We're trying to set up a specific install that works on a set number of
> machines
> > by getting a unique ID for the machine and using it to verify that the
> machine is
> > "licensed". This doesn't have to specifically be through MetaCard (it
> could be
> > AppleScript, XCMD, gestalt selector, etc.).
>
> The following information is not from me. This was a previous topic of
> discussion here, and I saved it for my own future reference. It appears to
> address what you want to do.
>
> ~Roger Eller  <[EMAIL PROTECTED]>
>
> --
--
> >>>I'd appreciate hearing any thoughts on ways to build in serial number
> >>>protection...at least into one main opening stack.
> >>
> >> Hi Richard,
> >>
> >> Before I describe my approach, let me point out its limitations:
> >>
> >> 1.  It is Mac-specific.
> >>
> >> 2.  It only works on hardware/OS combos where the Apple System Profiler
> >> returns the computer serial number.
> >>
> >> 3.  It works for me because my product is designed and priced for a
> limited
> >> marketplace.
> >>
> >> That being said, the AppleScript script:
> >>
> >> on getSerial()
> >>   tell application "Apple System Profiler"
> >>launch
> >>copy SerialNumber to myNumber
> >>quit application "Apple System Profiler"
> >>   end tell
> >>   return myNumber
> >> end getSerial
> >>
> >> will return the Mac's serial #.  (BTW, Apple System Profiler does NOT
> quit;
> >> but that's another issue.)
> >>
> >> When a winemaker orders, or subscribes to, OenoLog, the license is
> specific
> >> to the her/his Mac by serial number...which he/she retrieves using the
> >> System Profiler and includes on the order form.  I burn a CD for that
> >> specific installation with the serial # encrypted in the stack.
> >>
> >> As I look to the future, I must determine which of the Mac-specific
> >> features in OenoLog can be reprogramed to be platform independent, and
> >> which must be given up if I am to achieve cross-platform compatability.
> It
> >> would be nice if Revolution had a built-in method of uniquely
> identifying
> >> the computer it's running on.  Some people have suggested the Ethernet
> >> address as a possibility; but for my purposes the serial # is more
> easily
> >> retrieved by the user.
> >>
> >> I'd be happy to participate in any effort address the issue by RunRev
or
> >> MetaCard staff and/or users.  I'd also be interested in hearing from
> anyone
> >> who knows what toolbox call ASP uses to retrieve the serial # (some
> >> argument to gestalt(??)).  If I knew that, I could ditch AppleScript;
> but
> >> I'm too cheap to pay Apple $200 so I can ask them directly.
> >>
> >> Rob Cozens
> >> CCW, Serendipity Software Company
>
>
> ___
> use-revolution mailing list
> [EMAIL PROTECTED]
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Applescript that sends mail.. (urgent)?

[sims]

--OUTLOOK EXPRESS

tell application "Finder"

--   
--Type your message between the following inverted commas. ¬
--Remember to leave a line between the first inverted commas¬
--and the start of your message    

set myVar3 to ¬
"
Your message goes in here
Your message goes in here
Your message goes in here
Your message goes in here
Your message goes in here

Yours faithfully

FirstName Surname"

set myVar1 to "Dear "




repeat

tell application "Finder"
activate
with timeout of 300 seconds
display dialog "Include a person's 
first name?" buttons {"Yes", "No", "Quit"}
end timeout

if button returned of result = "Yes" then

display dialog "Type in the first 
name" default answer ""
set myVar2 to (text returned of 
result as text) & "
  "
set myVar4 to myVar1 & myVar2 & myVar3

else if button returned of result = "No" then
set myVar4 to myVar3


--When there's no-one's first name
else if button returned of result = "Quit" then
exit repeat
end if




with timeout of 180 seconds
display dialog "Type in email 
address" default answer "" buttons {"Quit", "OK"} default button "OK"
end timeout
set DialogResult to result
set myVar to text returned of DialogResult as 
text --sets myVar to email address you type in
set myButton to button returned of DialogResult
if myButton = "Quit" then
exit repeat
end if
if myButton = "OK" then
set myVar to text returned of 
DialogResult as text
end if





--    
-- Next is a bit of script that, apart 
from other things,  puts
-- your subject in the subject field. Type in 
your subject ¬
-- between the inverted commas after the word 
'subject' ¬
-- below inside the curly brackets

tell application "Outlook Express"
activate
make new draft window with properties ¬
{subject:"Your subject goes 
in here", content:myVar4, to recipients:myVar} ¬

end tell





end tell

end repeat




end tell




--FOR AOL  (heavily commented...but you said 'urgent')


set tAttach to ¬
alias "Macintosh HD:Desktop Folder:AllSimsAllTheTime:130202sims.sit"
--(choose file with prompt "Select file")


tell application "America Online"

--set toList to {"AOLUser"}

--set ccList to {"[EMAIL PROTECTED]", "[EMAIL PROTECTED]"}

--set bccList to {}

--set mailSubject to "Widgets"

--set mailMessage to "Dear AOLUser:" & return & return & 
"Hope you're having fun." & return & return & "Love, AppleScript 
Editor"

--set att to alias "SYS:test file"

set documentRef to make new document with properties {kind:mail}

--set mailref to mailer of documentRef

--set text of documentRef to mailMessage

--set subject of mailer of documentRef to mailSubject

--repeat with mailRecipient in toList

--make new addressee at end of mailref with properties 
{kind:regular, name:mailRecipient}

--end repeat

--repeat with mailRecipient in ccList

--make new addressee at end of mailref with properties 
{kind:cc, name:mailRecipient}

--end repeat

--repeat with mailRecipient in bccList

--make new addressee at end of mailref with properties 
{kind:bcc, name:mailRecipient}

--end repeat

--make new attachment at end of docref with properties {local file:att}

make new attachment at end of documentRef with properties 
{local file:tAttach}

-- SendLetter documentRef

--close documentRef saving no
end tell





>Sorry if this is a bit offtopic, but I need an Applescript that sends an
>e-mail using Outlook Express (or other common, preferably free mailprogram
>on Mac). Anyone knows how to do it? It's for an article and the deadline
>is just about now..
>thanks,
>/Niklas Almesj–

___

http://www.EZPZapps.com [EMAIL PROTECTED]
  

Re: Polling the mouse

[Scott Raney]

On Thu, 21 Feb 2002 Jim Hurley <[EMAIL PROTECTED]> wrote:

> >Yes.  The full list of functions to avoid because they are deprecated is:
> >the mouse
> >the mouseClick
> >the mouseH
> >the mouseV
> >the mouseLoc
> >the optionKey
> >the commandKey
> >the controlKey
> >
> >And the very worst thing to do with any of these is "repeat until
> >", which will condemn you to the fires of eternal damnation
> >in multiuser hell ;-)
> >
> >The last 3 can be safely acquired with "the keysDown", but be careful
> >to not sit in a repeat loop calling that or you may hang your app or
> >at the very least have the gods of multiuser development strike you
> >down.

One more note on this: as of engine version 2.4.2, the last three are
also now done asynchronously and so won't be a problem anymore.  And
they've always been safe to use a single time in a "mouseDown" or
"mouseUp" handler.  It's getting them in a repeat loop that will
potentially cause problems.

(snip)

> For some time I have been using HC, MC and/or RR to build Turtle 
> Graphics into HyperTalk and allow grade school students to use the 
> package to program their own solutions to problems in mathematics and 
> physics. There are two areas in this work in which HyperCard is quite 
> superior to MC or RR. (And there are many others, of course, in which 
> MC and RR are infinitely superior to HC.) The most serious problem is 
> the glacial speed with which MC draws images (in many cases this 
> problem is lethal) and the second, and much less important, is the 
> problems students have in polling the mouse.
> > There appears to be no remedy in the offing to the speed problem. 

Actually the current release is pretty close to HC in performance,
the primary remaining difference being due to running in color vs
black and white (anywhere from 8 to 32 times as much data to move
around, you know).

> However, regarding mouse-polling, my earlier question dealt with the 
> reliability and continued viability of the mouseClick function.
> 
> As an example, students create a button which, when clicked, sends a 
> satellite on its way into orbit around the earth--leaving a line in 
> its wake to show the trajectory. (The student has programmed the 
> turtle to obey the laws of Newtonian gravity.) When the student is 
> satisfied with the length of the trajectory, he or she clicks again 
> (anywhere on the screen) to stop the process. This is accomplished 
> with a "repeat until the mouseClick" or "if the mouseClick then exit 
> repeat."
> 
> So my question is three-fold:
> 
> 1. Is this a reliable operation given the current state of the MC 
> engine? That is, is there a bug similar to that in "repeat until the 
> mouse is down?"
> 2. We know that we may lose the mouse() function in the future. Is 
> mouseClick vulnerable as well?
> 3. If mouseClick will not be an option, what is the work-around so 
> that the student may click anywhere on the screen to exit a repeat 
> loop, and hopefully one which is simple enough for an eighth grader 
> to discover? (Since the student clicked the button to start the 
> process, it is more natural to click again to stop the process. It 
> would be awkward to have to move to the keyboard.)

The short answer to your question is, don't use a repeat loop, use
"send .. in" to draw the segments instead, and cancel the message if
you get a mouseDown.

The long answer, and probably much more than you want to know, is that
"the mouseClick" is really the problem here, not "the mouse".  "the
mouse" could in theory be done asynchronously.  If this were changed
you'd still have the performance issue to deal with (i.e., "repeat
until" would never be as smooth as using mouseMove messages and would
eventually cause the OS to start penalizing your app), but reliability
wouldn't because this information can be queried directly from the OS
on all platforms.  You'd also be subject to the normal behavior of
async functions (e.g., in HC, "the mouse" returns "down" if the user
clicked down anytime between when the handler started running and when
the function is called, whereas an async implementation would only
return "down" if it was actually down when you made the call).

The problem with "the mouseClick" is that of state management and
event order: it has to wait for the mouse to go down and then back up.
Worse, at least for HC compatibility, is that if you do something in a
script that takes a few seconds and click twice in that interval, "the
mouseClick" will return true *twice*.  This means that it's necessary
to maintain a queue of these mouse events and check the whole queue
each time the function is called to see if there is both a mouseDown
and a mouseUp message in it, and pull them out as a pair if so.  And
of course you can't just leave the rest of the events in the queue
either, because some of them (like socket events and redraws) need to
be handled independently of what the currently running handler is
doing.  Doing this cross-platform is horre

Re: Do's and Dont's

[Ian Summerfield]

On 21/2/02 2:10 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> scribed:

>> Yes.  The full list of functions to avoid because they are deprecated is:
>> the mouse
>> the mouseClick
>> the mouseH
>> the mouseV
>> the mouseLoc
>> the optionKey
>> the commandKey
>> the controlKey


Is this official or just what users are finding temperamental?  If they are
deprecated then under what circumstances?  I may have to write one extremely
simple and 100% reliable piece of C code to test the state of the mouse
button for my code and compile it as an external, I think I'll call it
"themouse"!  After all, in the world of C it's quite straight forward, one
line I expect.

I thought HyperTalk was originally devised from Hypercard by Bill Atkinson?
These functions were in HyperTalk, so either Revolution speaks the language
or it doesn't?  I'm fast being put off a 4GL that redefines the standard
whenever things get complicated.


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

groups question

[Steve Messimer]

Hi,

When using v 1.1 when I create a group and copy it and paste it into another
stack the group sometimes looses its group identity.  ie when I click on it
only the component object I click on is hilited NOT the entire grp.

I want to create groups in one stack and use them as templtes in other
stacks.  This seems as if it should be possible but doesn't work.  Is this a
bug or am I doing something wrong?

Steve

Stephen R. Messimer
Messimer Computing, Inc
2501 14th Ave South
Escanaba, MI 49829
www.messimercomputing.com


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse state

[Ian Summerfield]

On 21/2/02 4:24 pm, "Jacqueline Landman Gay" <[EMAIL PROTECTED]> scribed:

> 
> Doesn't "grab" do what you want? I think it suspends other messages while
> the user is dragging and automatically exits when the user lets go of the
> mouse button.

No, drag doesn't let me check whether the object has been dragged into the
bounds of another while the dragging is still going on.

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Unique Macintosh Identification

[Ian Summerfield]

I don't know the answer but I do not that few things are unique in the Mac,
the serial number hasn't been in ROM for long,  it's not in my B&W 450Mhz.
So I would suggest you investigate getting the Ethernet address,  that is
unique and Mac's have had Ethernet built in since the 1950's!

-i-

On 21/2/02 6:58 pm, "Ken Ray" <[EMAIL PROTECTED]> scribed:

> Thanks, Roger. Unfortunately it means I'd need to launch another app and
> then make it quit just to get the serial number. Perhaps there's a gestalt
> reference out there? Then I could use a gestalt XCMD or equivalent...
> 
> Ken Ray
> Sons of Thunder Software
> Email: [EMAIL PROTECTED]
> Web Site: http://www.sonsothunder.com/
> 
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, February 21, 2002 11:43 AM
> Subject: Re: Unique Macintosh Identification
> 

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse state

[Richard Gaskin]

Jacqueline Landman Gay writes:

> Doesn't "grab" do what you want? I think it suspends other messages while
> the user is dragging and automatically exits when the user lets go of the
> mouse button.

The grab command could give me everything I need for 90% of the times I need
such a thing, if only I could specify bounds for the dragging operation (I
usually need to restrict it to either axis, or within a given rect).

Any syntax sugestions for such an addition?

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 Developer of WebMerge 1.9: Publish any Database on Any Site
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
 Tel: 323-225-3717   AIM: FourthWorldInc

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse

[Richard Gaskin]

> The short answer to your question is, don't use a repeat loop, use
> "send .. in" to draw the segments instead, and cancel the message if
> you get a mouseDown.
> 
> The long answer, and probably much more than you want to know, is that
> "the mouseClick" is really the problem here, not "the mouse".  "the
> mouse" could in theory be done asynchronously.  If this were changed
> you'd still have the performance issue to deal with (i.e., "repeat
> until" would never be as smooth as using mouseMove messages and would
> eventually cause the OS to start penalizing your app), but reliability
> wouldn't because this information can be queried directly from the OS
> on all platforms.  You'd also be subject to the normal behavior of
> async functions (e.g., in HC, "the mouse" returns "down" if the user
> clicked down anytime between when the handler started running and when
> the function is called, whereas an async implementation would only
> return "down" if it was actually down when you made the call).
> 
> The problem with "the mouseClick" is that of state management and
> event order: it has to wait for the mouse to go down and then back up.
> Worse, at least for HC compatibility, is that if you do something in a
> script that takes a few seconds and click twice in that interval, "the
> mouseClick" will return true *twice*.  This means that it's necessary
> to maintain a queue of these mouse events and check the whole queue
> each time the function is called to see if there is both a mouseDown
> and a mouseUp message in it, and pull them out as a pair if so.  And
> of course you can't just leave the rest of the events in the queue
> either, because some of them (like socket events and redraws) need to
> be handled independently of what the currently running handler is
> doing.  Doing this cross-platform is horrendously complicated, and
> results in compromized reliability for *everything*, not just the
> mouseClick function.  Which is why we want to (and plan to) remove
> this functionality, or at least substantially modify it to remove this
> queueing aspect (e.g., the mouseClick would return true only if you
> clicked down and up any time between the start of the handler and when
> you made the call, and once it returned true *all* state information
> would be tossed out so it wouldn't return true again until the user
> clicked again after the function returned true, even if they clicked
> multiple times before the first call).

This is the best explanation yet, and I've saved it to explain to clients
why so much of their code needs to be rewritten when moving stuff from
another xTalk.  They hate paying for it, but attempting to check the mouse
during a repeat loop is not reliable in MC, even though it works well in
other xTalks, and I try to tell them it's just a small tradeoff for gaining
the other 97.5% of the market (is the Mac really down to 2.5% as MediaMetric
reported two weeks ago?).

However, something that would be even more useful than this explanation are
a couple of good examples in the docs of how one would approach converting
such a handler.   The mental flip-flops needed to do this took me a fair
amount of trial and error to get down, and the time lost is something either
a client pays for or I absorb here, but regardless who's writing the check
it still feels like a loss when the same handler worked perfectly before
conversion.  

Given the background you provided I support the move, but anything that
could be done to reduce conversion costs would be very helpful.  As it is,
with complex projects it's sometimes easier to write something over from
scratch than pick your way through differences in syntax and object model.
There are many benefits to a complete rewrite (and with OS X and XP, most
projects need a UI overhaul anyway), but it's a hard sell for new clients
who don't understand how something can be "compatible" and "incompatible" at
the same time. :)

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 Developer of WebMerge 1.9: Publish any Database on Any Site
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com
 Tel: 323-225-3717   AIM: FourthWorldInc

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

check box Buttons

[Stgecft]

When I  doMenu "New Card" or create new card, All of my fields (Groups) that 
have background behavior set to true, copy fine  --The check box buttons also 
copy over but I want them to work independently on each page.  They currently 
all check when 1 is checked.  What is the trick to have grouped check box 
buttons placed so they work independently from previous pages?

Randy Kent
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse

[J. Scott Saults]

Thu, 21 Feb 2002 12:58:57 -0700 (MST)
Scott Raney <[EMAIL PROTECTED]> wrote
>You'd also be subject to the normal behavior of
>async functions (e.g., in HC, "the mouse" returns "down" if the user
>clicked down anytime between when the handler started running and when
>the function is called, whereas an async implementation would only
>return "down" if it was actually down when you made the call).

Just for the sake of accuracy,  in HC & SuperCard , the mouse function does 
NOT necessarily reutun "down"  if the user clicked anytime between when the 
handler started and when the function is called. Both SuperCard and 
HyperCard return the actual state of the mouse, up or down, whenever the 
mouse function is called within a handler, at least under Mac OS 9. Perhaps 
it works differently in OS X.


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Close stack

[paolo mazza]

I am using Rev 1.1.1.B1 in a PC with  Window 98
I have a problem
>From a stad-alone program (run-time) tha I created with Revolution I open a
stack as palette.
In this stack I have a button   sending the command "close Stack".
When I click this button... the stack closes but it opens a window from the
finder. 
If I open that stack again, and I click the same button, it closes the stack
and nothing happen
. somebody can understand this strange behaviour?
Thanks,, Paolo

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Deprecated mouse functions

[David Vaughan]

Scott Raney wrote:

Yes.  The full list of functions to avoid because they are deprecated is:
the mouse
the mouseClick
the mouseH
the mouseV
the mouseLoc
the optionKey
the commandKey
the controlKey

... as of engine version 2.4.2, the last three are also now done asynchronously and so won't be a problem anymore.  And they've always been safe to use a single time in a "mouseDown" or "mouseUp" handler.  It's getting them in a repeat loop that will potentially cause problems.

and Sivakatirswami wrote:

For the untutored, an addition to documentation with the "not so long list
of deprecated" commands with the corresponding "right way to do it." would
be a wonderful addition.

It is good to receive Scott's list which I have not seen published before, even including the newly un-deprecated (precated? apprecated?) key functions, but I also strongly support Siva's view. I think it an important part of the documentation that deprecated functions be mentioned as such in the Transcript Dictionary, and a reference given to possible alternatives. At present, the "See also" in the Dictionary entry for the deprecated mouseLoc makes no reference at all to the preferred mouseMove, nor does that for mouseH refer to mousemoveH, so how is anyone not already familiar with the language supposed to find the preferred functions, especially if they come from xTalk and are already comfortable with the wrong ways?

Jeanne...

regards
David

Re: Do's and Dont's

[Geoff Canyon]

At 8:02 PM + 2/21/02, Ian Summerfield wrote:
>On 21/2/02 2:10 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> scribed:
>
>>> Yes.  The full list of functions to avoid because they are deprecated is:
>>> the mouse
>>> the mouseClick
>>> the mouseH
>>> the mouseV
>>> the mouseLoc
>>> the optionKey
>>> the commandKey
>>> the controlKey
>
>
>Is this official or just what users are finding temperamental?  If they are
>deprecated then under what circumstances?  I may have to write one extremely
>simple and 100% reliable piece of C code to test the state of the mouse
>button for my code and compile it as an external, I think I'll call it
>"themouse"!  After all, in the world of C it's quite straight forward, one
>line I expect.

That list was originally posted by Scott Raney. It doesn't get any more "official" 
than that.

>I thought HyperTalk was originally devised from Hypercard by Bill Atkinson?
>These functions were in HyperTalk, so either Revolution speaks the language
>or it doesn't?  I'm fast being put off a 4GL that redefines the standard
>whenever things get complicated.

The two languages are not completely compatible. In addition, there are some things 
that were possible in HyperCard, designed for a black and white, single-user, 
non-re-entrant, co-operative multi-tasking system, that simply aren't practical, or 
even possible, on the systems of today. The trade-off is a system that is much more 
powerful in many ways, and works on (far) more computers, including the ones Apple is 
shipping right now.

regards,

Geoff

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Revoluionn hangs on the splash screen

[Russell Campbell]

I am using a new instalation of Red Hat 7.2 and have followed the 
instructions, have downloaded both files (revolutionenvironment.tgz & 
Linux.gz) Twice just to make sure that they were not corrupted. Any 
sugestions?

Thanx in advance Russell

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: check box Buttons

[Howard Bornstein]

>When I  doMenu "New Card" or create new card, All of my fields (Groups) that 
>have background behavior set to true, copy fine  --The check box buttons 
>also 
>copy over but I want them to work independently on each page.  They 
>currently 
>all check when 1 is checked.  What is the trick to have grouped check box 
>buttons placed so they work independently from previous pages?

Look at the button tab on the properties palette for each button. Make 
sure the "Share hilite on each card" is unchecked. Now they'll operate 
independently.

Howard Bornstein

D E S I G N  E Q
www.designeq.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: groups question

[Howard Bornstein]

>When using v 1.1 when I create a group and copy it and paste it into another
>stack the group sometimes looses its group identity.  ie when I click on it
>only the component object I click on is hilited NOT the entire grp.

There's a setting in the Edit menu called "Selected Group Controls". When 
this is checked, you can select individual items in a group. When this is 
unchecked, selecting any item in a group will select the entire group. 
Very useful for quick editing. However, it you don't know about it, it'll 
drive you crazy.

Make sure the menu item is not selected and you should have no trouble 
selecting the group.

Howard Bornstein

D E S I G N  E Q
www.designeq.com
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse state

[Ken Norris (dialup)]

on 2/21/02 12:10 PM, Ian Summerfield at [EMAIL PROTECTED] wrote:

> On 21/2/02 4:24 pm, "Jacqueline Landman Gay" <[EMAIL PROTECTED]> scribed:
> 
>> 
>> Doesn't "grab" do what you want? I think it suspends other messages while
>> the user is dragging and automatically exits when the user lets go of the
>> mouse button.
> 
> No, drag doesn't let me check whether the object has been dragged into the
> bounds of another while the dragging is still going on.
--
I need to do the exact same thing in an eduware game stack. I'll be watching
for the solutions while trying my own.

Best regards,
Ken N.

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse state

[Scott Rossi]

On Thursday, February 21, 2002, at 03:27  PM, Ken Norris (dialup) wrote:

>>> Doesn't "grab" do what you want? I think it suspends other messages 
>>> while
>>> the user is dragging and automatically exits when the user lets go of 
>>> the
>>> mouse button.
>>
>> No, drag doesn't let me check whether the object has been dragged into 
>> the
>> bounds of another while the dragging is still going on.
> --
> I need to do the exact same thing in an eduware game stack. I'll be 
> watching
> for the solutions while trying my own.

Is this what you folks are trying to do?

http://www.tactilemedia.com/download/

Regards,

Scott Rossi
Creative Director, Tactile Media
[EMAIL PROTECTED]
http://www.tactilemedia.com

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Polling the mouse state

[Campbell Alistair]

Wow,

What a web site. Very, very nice!

You didn't do that using Revolution did you?

Alistair Campbell
Senior Clinical Psychologist
Manager, CAMHS(N): "Oakrise"
3 Kelham St, Launceston, Tas, 7250
Ph: (03) 6336 2867
Fax:(03) 6336 2886
Email:  



-Original Message-
From: Scott Rossi [mailto:[EMAIL PROTECTED]]
Sent: Friday, 22 February 2002 11:07 AM
To: [EMAIL PROTECTED]
Subject: Re: Polling the mouse state



On Thursday, February 21, 2002, at 03:27  PM, Ken Norris (dialup) wrote:

>>> Doesn't "grab" do what you want? I think it suspends other messages 
>>> while
>>> the user is dragging and automatically exits when the user lets go of 
>>> the
>>> mouse button.
>>
>> No, drag doesn't let me check whether the object has been dragged into 
>> the
>> bounds of another while the dragging is still going on.
> --
> I need to do the exact same thing in an eduware game stack. I'll be 
> watching
> for the solutions while trying my own.

Is this what you folks are trying to do?

http://www.tactilemedia.com/download/

Regards,

Scott Rossi
Creative Director, Tactile Media
[EMAIL PROTECTED]
http://www.tactilemedia.com

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse

[Curry]

Scott Raney wrote:

> Yes.  The full list of functions to avoid because they are deprecated is:
> the mouse
> the mouseClick
> the mouseH
> the mouseV
> the mouseLoc
> the optionKey
> the commandKey
> the controlKey
> 
> And the very worst thing to do with any of these is "repeat until
> ", which will condemn you to the fires of eternal damnation
> in multiuser hell ;-)

Scott, I understand the problems of the OS penalty due to hogging the
computer with polling of mouse functions during a repeat, but there are
different kinds of software; in some cases, we may want to make software
that is supposed to be the only main application running on a computer, for
example, a game, a presentation, or an educational application with a lot of
animation.

Often, the documentation may even advise users of these types of programs to
not run other applications unnecessarily at the same time for better
performance. With these types of applications, often you would be
ill-advised to run other major software at the same time anyway, not just
because of its effect on the other software, but also because of other
software's effect on it.

For example, in one game project, I started off with the mouseMove message,
and then had to switch to send..in plus the mouseLoc (once per handler),
because mouseMove was not nearly responsive enough. (The object was always
moving toward the mouse, but at its own speed, not directly tied to the
mouse.) This was much more responsive.

There are comparable situations with the other functions. I have no problem
with the mouseClick going out. It's an obvious case. But I think it would be
terrible to remove the others functions which were mentioned. As Scott said,
it's using them with repeats that causes the problems.

So, first, can we be assured that these functions will still remain, at
least asynchronously, in the future? Otherwise, if the corresponding
messages don't work well enough for a certain task, we will be in a jam
someday.

Secondly, using these functions synchronously allows much more convenient
scripting for testing, personal projects, students (as someone mentioned),
etc. Why not keep the functions synchronous, with the exception of
mouseClick which could be turned asynchronous or simply trashed, and leave
the responsibility of using them correctly up to the scripter?

If a function is only called once per handler, it still won't hurt the
system if called synchronously. For those making utilities and well-behaved
games or educational apps that aren't full-screen or intensive, that would
allow them to have a way to check once or twice within a handler and be
assured of an accurate result.

For those making full-screen or intensive apps, or testing or making
projects for personal use, they could choose to poll these functions and
take the consequences. If used wrongly, like anything else if life, they
could cause problems, but that's what life is all about--using things the
right way according to the situation. Any professional developer would avoid
them where necessary. I think that avoiding these functions shouldn't have
to be forced on all users in all situations just because it would be unwise
some users in some situations.

Ever since switching to Revolution, I've marvelled at how it is really such
"an easier way to do that". I love everything about it. But I hope you will
listen to all the users about this type of feature, since all of us are
paying the subscription price, not just those who will definitely not miss
these features because of the type of projects they do. Since it isn't
absolutely necessary to remove all the features (the mouseClick is the main
problem) and it isn't absolutely necessary to make the functions
asynchronous as long as the scripter can be trusted to use them correctly
according to the situation, I suggest that these changes not be forced on
everyone.

People really *can* choose to do the right thing. And any professional
developers, or users in the appropriate situations, *will*. So on behalf of
all those who want to make scripting choices, please keep the old power in
there--we only need an FAQ, not a nanny! There's no reason to take away
useful scripting features everyone writing scripts as a student, for
personal use or testing, or making special types of software just because it
can hurt someone else if used incorrectly. We all must be responsible for
ourselves. If someone hogs the wrong CPU and it penalizes them, they may not
care if they are working on a personal project for their own use. If not,
they will fix it.

That's my two cents--maybe it's three cents. I think this is a pretty
important issue. It's not just about sentimentality--although those
functions, used with and without repeat--are a very important part of
scripting up to now in history. Going forward is good, but cutting out old
ways altogether is not always good. It's easy for one group of people to
decide that we must be resolute and the old way should be discarded, but
som

Re: Polling the mouse

[Scott Raney]

On Thu, 21 Feb 2002 "J. Scott Saults" <[EMAIL PROTECTED]> wrote:

> Thu, 21 Feb 2002 12:58:57 -0700 (MST)
> Scott Raney <[EMAIL PROTECTED]> wrote
> >You'd also be subject to the normal behavior of
> >async functions (e.g., in HC, "the mouse" returns "down" if the user
> >clicked down anytime between when the handler started running and when
> >the function is called, whereas an async implementation would only
> >return "down" if it was actually down when you made the call).
> 
> Just for the sake of accuracy,  in HC & SuperCard , the mouse function does 
> NOT necessarily reutun "down"  if the user clicked anytime between when the 
> handler started and when the function is called. Both SuperCard and 
> HyperCard return the actual state of the mouse, up or down, whenever the 
> mouse function is called within a handler, at least under Mac OS 9. Perhaps 
> it works differently in OS X.

I didn't check SC, but HC definitely does not work the way you say.  Try it
yourself and see.  Put the following script in a button, then click to
run it and click again before the repeats finish (you may need to
adjust the count depending on the speed of your system):
on mouseUp
  get 0
  repeat for 1 times
add 1 to it
  end repeat
  put the mouse
end mouseUp

It's compatibility at that level that's hard to do, convenient as it
might be for some things.
  Regards,
Scott


Scott Raney  [EMAIL PROTECTED]  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Polling the mouse

[Scott Raney]

On Thu, 21 Feb 2002 Curry <[EMAIL PROTECTED]> wrote:
> 
> Scott Raney wrote:
> 
> > Yes.  The full list of functions to avoid because they are deprecated is:
> > the mouse
> > the mouseClick
> > the mouseH
> > the mouseV
> > the mouseLoc
> > the optionKey
> > the commandKey
> > the controlKey
> > 
> > And the very worst thing to do with any of these is "repeat until
> > ", which will condemn you to the fires of eternal damnation
> > in multiuser hell ;-)

I noticed you CCed the MetaCard list, which is a good thing, I guess,
though they're getting dumped into the middle of the discussion.
Here's the key part of my previous message, just to bring them up to
speed:

  The long answer, and probably much more than you want to know, is
  that "the mouseClick" is really the problem here, not "the mouse".
  "the mouse" could in theory be done asynchronously.  If this were
  changed you'd still have the performance issue to deal with (i.e.,
  "repeat until" would never be as smooth as using mouseMove messages
  and would eventually cause the OS to start penalizing your app), but
  reliability wouldn't because this information can be queried
  directly from the OS on all platforms.  You'd also be subject to the
  normal behavior of async functions (e.g., in HC, "the mouse" returns
  "down" if the user clicked down anytime between when the handler
  started running and when the function is called, whereas an async
  implementation would only return "down" if it was actually down when
  you made the call).

  The problem with "the mouseClick" is that of state management and
  event order: it has to wait for the mouse to go down and then back
  up.  Worse, at least for HC compatibility, is that if you do
  something in a script that takes a few seconds and click twice in
  that interval, "the mouseClick" will return true *twice*.  This
  means that it's necessary to maintain a queue of these mouse events
  and check the whole queue each time the function is called to see if
  there is both a mouseDown and a mouseUp message in it, and pull them
  out as a pair if so.  And of course you can't just leave the rest of
  the events in the queue either, because some of them (like socket
  events and redraws) need to be handled independently of what the
  currently running handler is doing.  Doing this cross-platform is
  horrendously complicated, and results in compromized reliability for
  *everything*, not just the mouseClick function.  Which is why we
  want to (and plan to) remove this functionality, or at least
  substantially modify it to remove this queueing aspect (e.g., the
  mouseClick would return true only if you clicked down and up any
  time between the start of the handler and when you made the call,
  and once it returned true *all* state information would be tossed
  out so it wouldn't return true again until the user clicked again
  after the function returned true, even if they clicked multiple
  times before the first call).

It'd also be good to discuss the topic of sync/async polling on the HC
and SC mailing lists to get a sense of how aware people are of this
issue (I just responded to one poster on the use-revolution list who
wasn't aware of this behavior of the mouse function, though lord knows
we got enough bug reports about this back when MetaCard did a simple
async report).

> Scott, I understand the problems of the OS penalty due to hogging the
> computer with polling of mouse functions during a repeat, but there are
> different kinds of software; in some cases, we may want to make software
> that is supposed to be the only main application running on a computer, for
> example, a game, a presentation, or an educational application with a lot of
> animation.
> 
> Often, the documentation may even advise users of these types of programs to
> not run other applications unnecessarily at the same time for better
> performance. With these types of applications, often you would be
> ill-advised to run other major software at the same time anyway, not just
> because of its effect on the other software, but also because of other
> software's effect on it.

Understood, and that's why we added the keysDown function, which is a
much better way to do this kind of thing than using keyDown messages
and the optionKey/commandKey/shiftKey functions.  I guess all that
remains is a async mouse polling function, but we never considered
this necessary because using message is always possible (and always
preferred) in this case.

> For example, in one game project, I started off with the mouseMove message,
> and then had to switch to send..in plus the mouseLoc (once per handler),
> because mouseMove was not nearly responsive enough. (The object was always
> moving toward the mouse, but at its own speed, not directly tied to the
> mouse.) This was much more responsive.

I can't see why this would be the case unless you're running on a very
slow system, moving very large objects or a large number of objects,
or maybe doi