> From: [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > Date: Fri, 23 Nov 2001 12:01:12 -0500 > To: [EMAIL PROTECTED] > Subject: improve-revolution digest, Vol 1 #3 - 12 msgs > > Send improve-revolution mailing list submissions to > [EMAIL PROTECTED] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.runrev.com/mailman/listinfo/improve-revolution > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of improve-revolution digest..." > > > > This is the Improve Revolution mailing list. Use it to report bugs and make > feature requests to improve Revolution. Please do not send general use or > "how-to" questions to this list. > > > Today's Topics: > > 1. Re: (no subject) (Ken Ray) > 2. Re: (no subject) (Geoff Canyon) > 3. Re: (no subject) (Ben Rubinstein) > 4. Re: Transcript request: loopcounter (Scott Raney) > 5. Visual Effects and QuickTime Extension (Ted) > 6. Re: "new" button (Curry Kenworthy) > 7. Re: "new" button (Curry Kenworthy) > 8. Documentation errata (Troy Rollins) > 9. Re: hidden items (Jeanne A. E. DeVoto) > 10. RE: Digest improve-revolution.v001.n102 (Jeanne A. E. DeVoto) > 11. Re: Documentation wish item (Jeanne A. E. DeVoto) > 12. Rev 1.1: Groups not showing up (Ben Rubinstein) > > --__--__-- > > Message: 1 > From: "Ken Ray" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Re: (no subject) > Date: Thu, 22 Nov 2001 11:00:12 -0600 > Reply-To: [EMAIL PROTECTED] > > Actually, Kees, it's a lot easier than that. You merely need to state: > > if there is a file <pathName> then > -- do something > end if > > Ain't Revolution grand? :-) > > Ken Ray > Sons of Thunder Software > Email: [EMAIL PROTECTED] > Website: http://www.sonsothunder.com/ > > ----- Original Message ----- > From: "Kees van Eekelen" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, November 22, 2001 4:50 AM > Subject: (no subject) > > >> L.S. >> >> if one wants to check if a file is present in some distant (system) >> folder, one has to use a construction like: >> >> put the directory into tDirectory -- >> remember where I an now >> set the directory to specialFolderPath(Extension) -- >> move to the target folder >> if "my Target File" is not in the files then -- >> check if it's there >> -- do something >> set the directory to tDirectory -- >> and go back to where we came from >> >> Now wouldn't it be nice if the 'files()' function used an argument >> for the target directory (none is current dir.), so that we can write: >> >> if "my Target File" is not in >> files(specialFolderPath(Extension)) then -- check if it's there >> -- do something >> >> One can always use files() (no argument) for the current dir, and be >> backward compatible as well :-) >> >> Shouldn't be too difficult, should it ? >> >> >> Greetings, Kees >> -- >> Drs. C.W.J.M. van Eekelen >> Head of ICT dept. >> Faculty of Social Sciences >> University of Nijmegen >> Thomas van Aquinostraat 4.00.49 >> PO Box 9104 >> NL-6500 HE Nijmegen >> The Netherlands >> Voice : +31 24 36 11814 >> Email : [EMAIL PROTECTED] >> _______________________________________________ >> improve-revolution mailing list >> [EMAIL PROTECTED] >> http://lists.runrev.com/mailman/listinfo/improve-revolution >> > > > --__--__-- > > Message: 2 > Date: Thu, 22 Nov 2001 09:07:03 -0800 > To: [EMAIL PROTECTED] > From: Geoff Canyon <[EMAIL PROTECTED]> > Subject: Re: (no subject) > Reply-To: [EMAIL PROTECTED] > > At 11:50 AM +0100 11/22/01, Kees van Eekelen wrote: >> if one wants to check if a file is present in some distant (system) folder, >> one has to use a construction like: > > Check the entry for "There is" It has a construction like: > > there is a {object | window | file filePath | folder folderPath} > > regards, > > Geoff > > --__--__-- > > Message: 3 > Date: Thu, 22 Nov 2001 18:11:40 +0000 > Subject: Re: (no subject) > From: Ben Rubinstein <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > > on 22/11/01 5:00 PM, Ken Ray at [EMAIL PROTECTED] wrote: > >> Actually, Kees, it's a lot easier than that. You merely need to state: >> >> if there is a file <pathName> then >> -- do something >> end if >> >> Ain't Revolution grand? :-) >> > > Yes it is - but the original suggestion (that it should be possible to pass > a path directly to "the files", rather than saving the value of 'the > defaultFolder', setting it to the path one is interested in, then setting it > back) is still valid! > > Of course it's trivial to write the function that does this, but it does get > tiresome to keep writing the same seven-line function in virtually any stack > that needs to examine local drives. > > Ben Rubinstein | Email: [EMAIL PROTECTED] > Cognitive Applications Ltd | Phone: +44 (0)1273-821600 > http://www.cogapp.com | Fax : +44 (0)1273-728866 > > > > --__--__-- > > Message: 4 > Date: Thu, 22 Nov 2001 12:01:50 -0700 (MST) > From: Scott Raney <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Transcript request: loopcounter > Reply-To: [EMAIL PROTECTED] > > On Wed, 21 Nov 2001 Ben Rubinstein <[EMAIL PROTECTED]> wrote: > >> The "repeat for each chunk x in y" form is a great advantage over other >> xtalks, not least because it is much faster if y is great. However, I still >> find I am sometimes writing >> repeat with i from 1 to number of chunks in y >> put chunk i of y into x >> .... >> end repeat > > I wouldn't recommend this approach in general: it's slow compared with > "repeat for each <chunk>". > >> Or even: >> >> put 0 into i >> repeat for each chunk x in y >> add 1 to i >> ... >> end repeat > > This, however, is just fine. > >> because then I can use <i> to report progress through the loop. If there >> was a function/property "loopcounter", or "repeatindex" or whatever it was >> called, we'd have the best of both worlds. > > Seems to me you've already got that with your second example. The > engine doesn't even keep a counter for this case internally, and it > would slow it down nearly as much to add one as the way you've done it > (worse, it would slow it down for the 95% of the cases where you > *don't* need a loop counter). I'm also not keen on adding implicit > variables like this. They're complicated (e.g., How do you handle > nested repeats?), and very confusing to new users. Perl is filled > with these little beasties and I consider that to be the single > biggest shortcoming of the language. > Regards, > Scott > >> Ben Rubinstein | Email: [EMAIL PROTECTED] >> Cognitive Applications Ltd | Phone: +44 (0)1273-821600 >> http://www.cogapp.com | Fax : +44 (0)1273-728866 > > ******************************************************** > Scott Raney [EMAIL PROTECTED] http://www.metacard.com > MetaCard: You know, there's an easier way to do that... > > > --__--__-- > > Message: 5 > From: "Ted" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: Visual Effects and QuickTime Extension > Date: Thu, 22 Nov 2001 14:37:31 -0500 > Reply-To: [EMAIL PROTECTED] > > Visual Effects and QuickTime Extension > > In an earlier posting to this list, I wrote in part: > >> In Rev 1.0, the above effect is as smooth as silk. In 1.1B1, the >> leading edge of the effect paints very unevenly and jerkily. >> It appears to be painting in about 20-pixel chunks. > > Kevin replied: > >> I'm not getting this here. Is it possible that you have some other process >> open that is taking up the CPU? Internet Explorer is really bad at this. >> The effect seems to take about the correct amount of time here too now. > > > Each time that I did this test, a single version of Revolution was the only > open program. > > Since the above report, I did more testing to compare the visual effects in > 1.0 and 1.1. I made a single stack with a single wipe effect and built > standalones from it in both versions. I used this updated recipe: > > Create a 640 x 480 stack with two cards. Place a 600 x 400 dark blue square on > the second card. Place a button on each card with this script: > > on mouseUp > set the effectRate to 4000 --so that the effect is easily seen > lock screen > go next card > unlock screen with visual wipe left very slow > end mouseUp > > > I went to computer labs and tried the 1.0 and 1.1 standalones on different > Macs running different OS versions, and I made sure that the conditions were > as equal as possible for the testing of the versions (no other open programs). > In each case, on the same computer under the same conditions, the effects in > Revolution 1.1 were quite inferior to those in 1.0. > > By inferior, I mean that the effects have a moving stair-step appearance along > the leading edge as they paint. This has a ragged, jumpy look. In comparison, > the effects in Rev 1.0 are quite smooth. > > When an effect is painting in Rev 1.0, the leading edge of the effect is very > even--at the most, it "stair-steps" in about 1-pixel increments, and this > appears very smooth. However, when an effect is painting in Rev 1.1, the > leading edge stair-steps in approximately 20-pixel increments, and this is > very noticeable. > > In one test, I checked the Revolution 1.0 stack on an approximately > ten-year-old Mac. As expected, it did take a longer time for each card > transition to start, but once it did, the visual effects were smooth. In fact, > Revolution 1.0 on a 25 MHz Mac had smoother visual effects than Revolution 1.1 > running on a 233 MHz iMac (running OS 9.0) or Rev 1.1 running on a 350 MHz G3 > (running OS 9.1). > > Because version 1.0's effects ran so smoothly on such a slow computer, > insufficient megahertz did not appear to be a factor. And because I had no > other open programs in any of these tests, there was no interference there. > > That led me to look at the extensions. I found that with all extensions off, > the visual effects in 1.1 were very close to those in 1.0. After some > extension troubleshooting, it all narrowed down to the QuickTime extension. > With the QuickTime extension off, Revolution 1.1's effects are smooth and > nearly identical to those in 1.0. On my programming computer, I reloaded with > the latest version of QuickTime to ensure that my copy wasn't corrupt, and the > results were the same. > > In short, Rev 1.1 may be having some sort of adverse interaction with the > QuickTime extension that impacts the visual effects--an interaction that does > not occur with Rev version 1.0. With 1.0, the QuickTime extension can be on or > off, and the effects are smooth. > > This problem first showed up in 1.1B1. Pre-1.0 betas and 1.0 itself were fine. > > Kevin, you mentioned that you were not seeing this at your end. I cannot > explain this... I have been able to get repeatable results on different Macs. > Offhand, I have only two ideas: > > 1. Might I have been using computers of less speed than yours--ones that more > readily show these differences? I did these tests on Macs only up to 350 MHz, > which constitutes the majority of my current target market. On these > computers, the difference in effects between Rev 1.0 and 1.1 shows up very > handily. I thought that I had ruled out megahertz as a factor, when, as I > mentioned, I noted that Rev 1.0's effects ran smoothly on a 25 MHz Mac, while > 1.1 looked inferior on a computer more than 10 times that fast. But I don't > know how these tests would compare at today's cutting edge on, say, a dual 800 > MHz G4. > > 2. Since I found that the QuickTime extension is definitely a factor at my > end, could it be that my tests involved different versions of QuickTime from > yours? In the early stages of testing, I was not keeping track of QuickTime > versions, because I didn't yet suspect it. But in later tests during which I > disabled the QuickTime extension and determined that it was involved, either > version 4.0.3 or 5.0.2 was active. > > If neither of these was a factor at your end, and you are still not able to > reproduce this, then a piece of the puzzle is still missing. > > After the Mac tests, I then built 1.0 and 1.1 standalones for Windows (on a > Mac). I tested on a single Windows 98 computer. The Rev 1.0 standalone worked > fine, but the 1.1 standalone would not display visual effects at all. For > example, when using a four-second effectRate, four seconds would pass with no > action, and then the screen would suddenly unlock with a straight transition-- > no effect at all. > > To find out if any part of this was related to the Mac authoring environment, > I built a 1.0 stack and a 1.1 stack, each in its respective Windows Revolution > environment. With Revolution open and running in Windows 98 (these were not > standalones), the 1.0 stack would display visual effects, but the 1.1 stack > would not. > > Ted > > > > > > --__--__-- > > Message: 6 > Date: Thu, 22 Nov 2001 15:17:38 -0600 > Subject: Re: "new" button > From: Curry Kenworthy <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > > Geoff Canyon wrote: > >>> This is a small detail indeed, but I noticed that with tool tips on and a >>> stack open to be edited, the "New" button in Rev's main toolbar says "New >>> card" for its tool tip, but produces a new stack instead. >> >> Funny -- for me (Mac OS 9, Rev 1.1) it creates a new card (if there is a >> stack >> to create one in). > > I'll check again and make sure it's consistent. I have Rev 1.1, Mac 8.6. > (Didn't think something like that would be different for different versions > of the OS.) > > Curry > > > > --__--__-- > > Message: 7 > Date: Thu, 22 Nov 2001 16:19:51 -0600 > Subject: Re: "new" button > From: Curry Kenworthy <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > >>> This is a small detail indeed, but I noticed that with tool tips on and a >>> stack open to be edited, the "New" button in Rev's main toolbar says "New >>> card" for its tool tip, but produces a new stack instead. >> >> Funny -- for me (Mac OS 9, Rev 1.1) it creates a new card (if there is a >> stack >> to create one in). > > Still the same on my system. Recipe: > > Start Revolution, open Preferences to turn on tool tips, close Preferences > Press "New" button once--tool tip "New mainstack", a stack is created > Press "New" button again--tool tip "New card", but another stack is created > However, Command-N makes a new card > > Even in situations such as having created a field on a card and editing the > text of the field, or having already used menu or Command-N to add another > card first, the button still creates a new stack. > > Since the key combination always produces a new card, having the button > always produce a new stack actually makes it very convenient to access > either one quicky; I would have thought it was a feature if not for the > tooltip. > > Curry > > > > --__--__-- > > Message: 8 > Date: Thu, 22 Nov 2001 23:31:10 -0500 > Subject: Documentation errata > From: Troy Rollins <[EMAIL PROTECTED]> > To: Revolution <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > > I was wondering why "resetAll" did not have a documentation entry, and found > that it does - it shows up as the first entry (out of 2) for "answer color". > > -- > Troy > RPSystems > www.rpsystems.net > > > --__--__-- > > Message: 9 > Date: Thu, 22 Nov 2001 17:22:43 -0800 > To: [EMAIL PROTECTED] > From: "Jeanne A. E. DeVoto" <[EMAIL PROTECTED]> > Subject: Re: hidden items > Reply-To: [EMAIL PROTECTED] > > At 2:47 PM -0800 11/21/2001, Curry Kenworthy wrote: >> When hidden items are shown in the user's project, they are also shown in >> the Transcript Dictionary, and it becomes a bit weird because of them. Maybe >> those extra items could be moved offscreen on the Dictionary stack? Then the >> experience would be perfect with hidden objects shown or not in the user's >> settings. > > Good point. I shall make it so. > > -- > Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] > http://www.runrev.com/ > Runtime Revolution Limited - Power to the Developer! > > > > --__--__-- > > Message: 10 > Date: Thu, 22 Nov 2001 19:49:25 -0800 > To: [EMAIL PROTECTED] > From: "Jeanne A. E. DeVoto" <[EMAIL PROTECTED]> > Subject: RE: Digest improve-revolution.v001.n102 > Reply-To: [EMAIL PROTECTED] > > At 11:25 PM -0800 11/21/2001, Gary Aitcheson wrote: >> I found two more small bugs while running Rev on Win 2000 >> >> (1) On R1.1 the TroubleShooting list only allows me to select the first 2 >> lines - all the others are inoperative > > This is because of the character-set problem I wrote about previously, I'm > pretty sure. (I'll bet that if you try a line that doesn't contain an > apostrophe, it will work.) > > -- > Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] > http://www.runrev.com/ > Runtime Revolution Limited - Power to the Developer! > > > > --__--__-- > > Message: 11 > Date: Thu, 22 Nov 2001 19:50:54 -0800 > To: [EMAIL PROTECTED] > From: "Jeanne A. E. DeVoto" <[EMAIL PROTECTED]> > Subject: Re: Documentation wish item > Reply-To: [EMAIL PROTECTED] > > At 4:37 PM -0800 11/20/2001, Troy Rollins wrote: >> The helpful little icons that say "no" or "yes" for each platform - it would >> be great if you could click them and get a filtered set of docs that match - >> in other words, click the "not under Linux" icon to see a list of ALL >> commands which don't function under Linux... And so on. > > Hmm, good idea. There will be a way to select "just Unix compatible", "just > changed since 1.0", "commands only", "messages sent to buttons", etc. in > the Transcript Dictionary listing in the main documentation window - but I > hadn't thought of making the platform icons "live". Will put it on the list. > > -- > Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] > http://www.runrev.com/ > Runtime Revolution Limited - Power to the Developer! > > > > --__--__-- > > Message: 12 > Date: Fri, 23 Nov 2001 11:07:58 +0000 > Subject: Rev 1.1: Groups not showing up > From: Ben Rubinstein <[EMAIL PROTECTED]> > To: "[EMAIL PROTECTED]" > <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > > In a stack I've been working on in Rev 1.1 (made new in 1.1); grouped three > objects on card 1. Made a new card, tried to place the group. "Place > Group" menu item greyed out. Went to the App Overview; showed the group > among the controls of card 1. Clicked card 2; the 'Place Grp' button was > enabled. Clicked the 'Place Grp' button, got an error: > > � There was an Execution Error at 10:56:42 AM > Error description: place: can't find group > Revolution User Interface Error: Object: button id 1157 of group id 1059 > of group id 1103 of card id 1051 of stack "/Hopper/Applications (Mac OS > 9)/Revolution/Revolution 1.1 > Classic/components/tools/revapplicationoverview.rev" > -------------------- > if the cREVMode of this stack is "Controls" then > -------------------- > Value: mouseUp > > Opened the 'Groups' disclosure triangle in the left pane of the App > Overview; it's empty. Made another group; still empty. Quit Rev 1.1, > relaunched, opened the stack again - all behaviour exactly the same. > > Made a new mainstack, dropped two buttons on it, grouped them. App Overview > shows the group in the controls for that card (in the right hand pane), but > doesn't show anything under 'groups' (in the left hand pane). Made a new > card; as before, "Place Group >" is greyed out in menus, but enabled in App > Overview. Clicked "Place Grp" in App Overview, got error: > > � There was an Execution Error at 11:01:27 AM > Error description: Chunk: can't find background > Revolution User Interface Error: Object: button id 1157 of group id 1059 > of group id 1103 of card id 1051 of stack "/Hopper/Applications (Mac OS > 9)/Revolution/Revolution 1.1 > Classic/components/tools/revapplicationoverview.rev" > -------------------- > place bg id tGroupID of stack gREVStackName onto tBrowseCardLongID > -------------------- > Value: mouseUp > > > Went back to card 1. Ungrouped the two buttons. Now clicking the second > card in the App Overview does not enable the "Place Grp" button. > > So some bits of Revolution are correctly spotting groups - some not. > > Finally, went to card 2. In the message box, executed > place group id 1005 onto this card > > got result: > Message execution error: > Error description: Chunk: can't find background > > > Ben Rubinstein | Email: [EMAIL PROTECTED] > Cognitive Applications Ltd | Phone: +44 (0)1273-821600 > http://www.cogapp.com | Fax : +44 (0)1273-728866 > > > > > --__--__-- > > _______________________________________________ > improve-revolution mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/improve-revolution > > > End of improve-revolution Digest > _______________________________________________ improve-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/improve-revolution
