Re: The RR programming model
Hi Judy, My name is Gerard Cote. I'm from Quebec City in Canada. Since I'm also a newcomer to RunRev and plans to learn and test it soon as a tool for my own teaching (college level), I'll be glad to help you test your instructional modules, if you want me to do so. So you'll get one more feedback voice before letting your work go in the hands of other RunRev newbies, especially a K-12 audience. Don't hesitate to contact me too if you're interested by my offer. Regards, Gerard - Original Message - From: Judy Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 10:33 PM Subject: Re: The RR programming model Rod, I don't know if I told you this previously, but I have entered a second master's degree program in instructional design and technology.. Anyway, they've approved as a final project for me to design a series of tools/tutorials to help acclimate new users to Rev -- particularly non-technical types such as new public school teachers. My first project is a stack which aims to teach the concept of mouse events; it is due early December. Would you be interested in offering any feedback? These things could perhaps be of use in attracting the K-12 market... Cheers, Judy ___ 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: The RR programming model
On Freitag, November 15, 2002, at 04:33 Uhr, Judy Perry wrote: I don't know if I told you this previously, but I have entered a second master's degree program in instructional design and technology.. Anyway, they've approved as a final project for me to design a series of tools/tutorials to help acclimate new users to Rev -- particularly non-technical types such as new public school teachers. My first project is a stack which aims to teach the concept of mouse events; it is due early December. Would you be interested in offering any feedback? These things could perhaps be of use in attracting the K-12 market... W*ho*o*o*w!!! Where can I See that??? regards Wolfgang M. Bereuter Learn easy with trainingsmaps© INTERNETTRAINER Wolfgang M. Bereuter Edelhofg. 17/11, A-1180 Wien, Austria ... http://www.internettrainer.com, [EMAIL PROTECTED] ... Tel: ++43/1/ 961 0418, Fax: ++43/1/ 479 2539 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
Going back to the original question about the programming model, I tend to think of Rev as an object oriented language with preset objects. To talk in C++ speak for a moment, you can instantiate a button, give it data (name, size, color, custom properties etc), and give it methods (mouseUp, mouseDown, doMyStuff). Purists would probably say that it While it's easy to create an interface using Revolution's built-in objects, the big weakness is that you can't make your own custom objects. I actually was impressed enough with Revolution to implement this myself using Transcript. I decided that stacks/cards can represent classes/objects. Class methods are functions stored in the script of a stack while stack and card custom properties store the object and class attributes. I implemented inheritance by giving classes a custom property that indicates their parent stack. I also provided object aggregation in a similar way. The end result was that I could use the following syntax: show age of Student of School James Culnan ...where Student and School are individual stacks, James Culnan is a card in the School stack, age is a custom property on cards in the Student stack, and show is a function in the stack Class that Student inherits from. Also, the School stack acts as a container for Student. (Student really means Students in this context). This actually works reasonably well, but the code I wrote is kind of cumbersome. I also recently tried RealBASIC and realized that this type of workaround is unnecessary there. Cheers, Mat ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
The RR programming model
Hi I've vaguely flirted with Revolution and gone through a couple of tutorials but I've never played with HyperCard or other stack based systems - and I don't understand the programming model which they follow. What is a stack? How do they fit in with more traditional programming languages? Yorkshire accent When I were a lad, we sat down in front of green terminals bashing out endless lines of C. None of your fancy object orientated rubbish, just nice, clean hand crafted code. We had to trudge through the snow in bare feet... /Yorkshire accent Seriously, can someone put the whole stack thing into some sort of perspective wrt more traditional programming languages - or point me to a resource which does this? I think it'd help me quite a lot. TIA Simon Forster ___ LDML Ltd, Office One, 16 Canham Road, London, W3 7SR, UK tel int=+44 70 9230 5244 uk=070 9230 5244 fax int=+44 70 9230 5247 uk=070 9230 5247 mailto:simon;ldml.com ___ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
Hi Simon, At 10:19 14/11/2002 +, you wrote: Hi I've vaguely flirted with Revolution and gone through a couple of tutorials but I've never played with HyperCard or other stack based systems - and I don't understand the programming model which they follow. What is a stack? How do they fit in with more traditional programming languages? Sorry if you've already figured this out and it seems like I am talking down to you Also this is a brief overview and may miss out certain things, however it should get you started. If not please email me off list at [EMAIL PROTECTED] At the most basic level possible a program consists of a main stack. A main stack is simply a collection of cards (or windows) and as with nearly every other developer tool you can place objects (such as buttons) onto the cards. You can also write lines of code (known as scripts) which can be attached to stacks, cards or objects. Each card (or window) in the stack is in a specific order and you can navigate between them using either the card name or commands such as next or previous. The metaphor is similar to having a deck of playing cards, i.e. you can pick specific cards or simply move through the deck of cards one at a time going back or forward. You can also have substacks which are linked off the main stack, these are essentially just groups of related cards (or windows) which fulfill a specific purpose. For example say your program was an accounting package. You may have a mainstack which lets you access all the options (e.g. payments, receipts, invoices etc, etc). This mainstack could contain substacks which handled specific items. For example one substack may contain only the options for invoicing (e.g. windows/cards, objects and scripts). Now the next phase is messages. Essentially messages (e.g. an event when a button is pressed) are passed up via a hierarchy. For example say I have a mainstack which contains one card and a button. If I press the button Revolution first checks if I have written the appropriate handler (e.g. mouseup) inside the script for the button, if not then it checks to see whether that handler is in the script for the card, if it is not in the card then it checks to see whether the handler is in the script for the mainstack. Yorkshire accent When I were a lad, we sat down in front of green terminals bashing out endless lines of C. None of your fancy object orientated rubbish, just nice, clean hand crafted code. We had to trudge through the snow in bare feet... /Yorkshire accent You had it far too easy my boy! In my day we used binary and oscilloscopes for programming on monochrome NCR terminals powered by bicycles. If we were lucky we got to use assembler. However we were quite state of the art and some were still using punched card. Programmers today have never had it so good :-) Seriously, can someone put the whole stack thing into some sort of perspective wrt more traditional programming languages - or point me to a resource which does this? I think it'd help me quite a lot. Revolution has quite a different metaphor in comparison to most other languages I've come across but I hope you've managed to get something out of the description earlier. Here is a very brief summary: MainStack = your program (contains substacks, cards, and objects). Card = A window and is part of a stack. Substack = a group of related cards. Cheers, Rod Rod McCall www.runrev.com Runtime Revolution Ltd Revolution - The Solution for Software Development tel: +44 (0) 870 747 1165 fax: +44 (0) 131 718 4334 All email subject to spam and virus checks. This may delay a response. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re:The RR programming model
Stacks and Messages paths --and yet that doesn't seem clear enough to me. Looking at the discussion on the list, it is frequently stressed if you want speed, you keep the data out of the stack-card-field paradym and put the information in a variable or an array. Another words if I was designing an address database: with my stack hat on I think I should create a stack with multiple cards each dedicated to the information of one individual. But this does not seem to be what I should doing. I should really be keeping things out of stacks-cards-fields except for display purposes and then I'm back a not dis-similar method of programing than any other?. Fred ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
On Thursday, November 14, 2002, at 03:19 AM, Simon Forster wrote: I've vaguely flirted with Revolution and gone through a couple of tutorials but I've never played with HyperCard or other stack based systems - and I don't understand the programming model which they follow. What is a stack? How do they fit in with more traditional programming languages? You have already answers from experts. Here is an alternate view that might help. In short, this view involves index cards. Suppose you are fond of novels by Martian authors. Over the years you have written a little report or reminder to yourself about each novel you read on a 6X4 index card. You have accumulated a stack of cards. Later you added a stack of 5X3 cards to your collection that contains author information. At the back of your novel stack you have put a special card (light blue) that provides some general reminders on how to use the stack. Most of what you do is natural. You thumb through cards. You look up novels. You look up the author of a particular novel. You find novels by an author. Over the years you have stuck on stickers and flags that mean something to you. You have made notes such as See _Twelve Sand Eyes_ by Au GBeeen Rarrououo or Do not confuse with _19,123 Toes_. On the back you have written notes such as When looking up this author use first name since this author is Ag and not Au as most literate Martians are and To calculate the respected age from the true chronological age for this author, do not count the years zhe was off planet. You decide to add some notes on writing authors names in Martian script. You consider adding a special card to the end of the author stack, but decide to simply write out the notes on 8X7 paper. You fold these up and put these and the two stacks (each bound, say, by rubber bands) into the Martian navel shoe box. Your daughter made a flip-card animation of a dancing Martian and you put that into the shoe box, too, and make a reference to it on the cards for _233 Leaning Dancers_, _Two Left Feet_ and _951 Right-Drifting Dancers_. Now, with that in mind, make a powerful, general programming environment. You now have Revolution. Dar Scott ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
I've vaguely flirted with Revolution and gone through a couple of
tutorials but I've never played with HyperCard or other stack based
systems - and I don't understand the programming model which they
follow. What is a stack? How do they fit in with more traditional
programming languages?
Hi Simon,
Stacks are very difficult to categorize, except to say a stack can be
almost anything you want it to be, including:
* An application
* A document
* A document that can create other documents
* A library of runtime routines, images, sounds, and/or other resources
* A database
* A dialog box
* A palette
I would say in its traditional form (eg: your address stack with one
card per address) a stack is a database that includes the interface
code to access and display the data it contains.
I find the metaphor that works best for me is to think of a stack as
a database and each card as a record. So think of go to card 1
[card id 99; card Card Name] as something like get record number
1 {record key 99) (alternate record key Card Name), only the
command not only loads the record into a buffer but also opens the
user interface to display/manipulate the data.
--
Rob Cozens
CCW, Serendipity Software Company
http://www.oenolog.com/who.htm
And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee.
from The Triple Foole by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re:The RR programming model
--- [EMAIL PROTECTED] wrote: Stacks and Messages paths --and yet that doesn't seem clear enough to me. Looking at the discussion on the list, it is frequently stressed if you want speed, you keep the data out of the stack-card-field paradym and put the information in a variable or an array. Another words if I was designing an address database: with my stack hat on I think I should create a stack with multiple cards each dedicated to the information of one individual. But this does not seem to be what I should doing. I should really be keeping things out of stacks-cards-fields except for display purposes and then I'm back a not dis-similar method of programing than any other?. Fred Hi Fred, Speed is a very 'relative' thing. As long as you don't have a huge amount of cards and/or don't have to do complicated sorting all of the time, the stack+card paradigm works just fine. Besides, sometimes we're talking about seconds instead of a minute. If you have a minute to spare, you don't need to invest extra time to make it as speedy as possible. Because it takes time to switch data from one format to another, and quite a bit of time in both thinking and programming to make all these switches happen. One of the differences between HyperCard and MetaCard/RunRev is that HC used a disk-based scheme, whereas MC/RR uses a ram-based scheme. This means that MC/RR have to load the _entire_ stack into memory, whereas HC would just read what it needed and swap to disk whenever it needed the memory. Consequence of this difference: MC/RR is faster, but large stacks slow it down considerably. At any rate, for a home-grown application, the stack+cards approach works just fine. For a commercial application, you'll probably want to look at a database back-end anyway. And then, RunRev is an excellent candidate for the front-end. Just my 2 euro-cents, Jan Schenkel. = As we grow older, we grow both wiser and more foolish at the same time. (La Rochefoucauld) __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
I've vaguely flirted with Revolution and gone through a couple of tutorials but I've never played with HyperCard or other stack based systems - and I don't understand the programming model which they follow. What is a stack? How do they fit in with more traditional programming languages? You can think of a stack as the contents of a window, with a card being one of a nearly unlimited number of screens in that window. Each stack has one card when it's created, and you can create more cards with the create card command or make a duplicate of an existing card with the clone card command. You could think of a card as being similar in some respects to a VB form. A card is where you put controls (buttons, field, images, etc). Like VB, Visual C++, and others, controls are placed on the card by drawing them interactively using the appropriate tool. Unlike VB, C++, and the rest, these tool modes are also available to you in scripting -- you can have a browse (normal) mode for interacting with controls, or a pointer tool mode for selecting, moving, and resizing objects. And there are other tools for creating each object type, so you could have a user create their own fields, for example, using the field tool. If you've programmed GUIs without a framework, you know how much code is devoted to handling the event loop: querying the OS for things like mouse and keyboard activity, determining which control is affected, and then calling a function to handle that event. With the xTalk family of languages (of which Revolution is one of several flavors, including ToolBook) the event loop is handled for you: controls are sent messages that you can intercept by name -- on mouseUp put hello world! into field 1 end mouseUp Similar to truly object-oriented systems, messages are sent along a hierarchy, such that if the first object in the chain doesn't handle it the message will pass to the second, third, etc. For example, the mouseUp message is sent to the control the user clicked on, but rather than write code into every button you could put your mouseUp handler in the card to handle all clicks on the card, or in the stack to handle all clicks on all cards in the stack. This message hierarchy is also extensible and malleable to some degree, using frontscripts, backscripts, libraries, and the send and call commands. Another big bonus for Revolution: nearly all memory issues (allocation and deallocation) are handled for you. Keeping track of object size and managing associated memory accounts for a huge portion of code in C and other lower-level languages, but Rev handles all that for you so you can concentrate on your program logc and user interface. Once you get the hang of it I suspect you'll find yourself cranking out applications in a fraction of the time it would take in C, or even Java. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.0: 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: The RR programming model
On 11/14/02 2:44 PM, Richard Gaskin [EMAIL PROTECTED] wrote: You can think of a stack as the contents of a window, with a card being one of a nearly unlimited number of screens in that window. Each stack has one card when it's created, and you can create more cards with the create card command or make a duplicate of an existing card with the clone card command. You could think of a card as being similar in some respects to a VB form. A card is where you put controls (buttons, field, images, etc). Like VB, Visual C++, and others, controls are placed on the card by drawing them interactively using the appropriate tool. I agree with the card assessment, and would further the one on stacks to say - you can think of the stack as the window itself, and not just the contents. Generally, the stack is like a smart window, and the cards are the contents. Then again - I also rather liked Dar's version (paraphrased) Fill up a shoebox with stuff, get visited by aliens, and there ya go... Revolution!! Or something like that. ;-) -- Troy RPSystems, Ltd. www.rpsystems.net ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
Rod, I don't know if I told you this previously, but I have entered a second master's degree program in instructional design and technology.. Anyway, they've approved as a final project for me to design a series of tools/tutorials to help acclimate new users to Rev -- particularly non-technical types such as new public school teachers. My first project is a stack which aims to teach the concept of mouse events; it is due early December. Would you be interested in offering any feedback? These things could perhaps be of use in attracting the K-12 market... Cheers, Judy ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
Okay, I am apparently just too stupid to live. The previous message was intended for Rod. Please ignore me in my vast stupidity. :( Judy ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: The RR programming model
No worries, Judy. I just did the same thing a few days ago on the MetaCard list... Doh! :-) Ken Ray Sons of Thunder Software Email: [EMAIL PROTECTED] Web Site: http://www.sonsothunder.com/ - Original Message - From: Judy Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 9:37 PM Subject: Re: The RR programming model Okay, I am apparently just too stupid to live. The previous message was intended for Rod. Please ignore me in my vast stupidity. :( Judy ___ 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: The RR programming model
Stacks and Messages paths --and yet that doesn't seem clear enough to me. Looking at the discussion on the list, it is frequently stressed if you want speed, you keep the data out of the stack-card-field paradym and put the information in a variable or an array. This is a good point but I think it needs to come second. Firstly, consider that all these xCard development tools started off using the rolodex metaphor i.e. a stack of cards but with easier navigation, searching etc. Then they became more general programming tools so the rolodex metaphor is no longer so relevant but it is still there. As someone else said, unless your database is massive (probably under 1000 cards would be fine) then using the card system will work well. So you might have your address book stack with one card per person. Added to that you might have other stacks which act more like dialog boxes than stacks. They would be one card stacks offering print options, search options, preferences, splash screen, whatever... Moving on from this concept, you might decide that you have too many addresses for a stack of cards, so you decide to store your addresses in some other way and have the addresses stack as a one card stack to allow easy viewing editing. This might be faster but it isn't as easy to implement first off, so I would recommend trying the rolodex method and altering it later if you aren't sure. Going back to the original question about the programming model, I tend to think of Rev as an object oriented language with preset objects. To talk in C++ speak for a moment, you can instantiate a button, give it data (name, size, color, custom properties etc), and give it methods (mouseUp, mouseDown, doMyStuff). Purists would probably say that it isn't properly object oriented since any other object can read write it's data directly, instead of sending it a message. Your button also becomes part of a hierarchy that allows messages to be sent up the chain higher higher until they are handled or finally ignored. If you want to make yourself a custom object, start with an existing object, edit one copy the way you want it, then use this is a template to clone other copies. Because each object is visible on your screen, it is very easy to edit it's properties and it's scripts. This makes a language like Rev not only quick easy to use, but amazingly easy to debug, even after a long time. If your program crashes when you click a button, then the problem is nearly always right there in the button itself. Cheers, Sarah On Friday, November 15, 2002, at 03:27 am, [EMAIL PROTECTED] wrote: Another words if I was designing an address database: with my stack hat on I think I should create a stack with multiple cards each dedicated to the information of one individual. But this does not seem to be what I should doing. I should really be keeping things out of stacks-cards-fields except for display purposes and then I'm back a not dis-similar method of programing than any other?. Fred ___ 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: The RR programming model
Just to say thanks to everyone who responded - I have far better mental image of the RR paradigm. Not perfect you understand but far better, ATB Simon Forster ___ LDML Ltd, Office One, 16 Canham Road, London, W3 7SR, UK tel int=+44 70 9230 5244 uk=070 9230 5244 fax int=+44 70 9230 5247 uk=070 9230 5247 mailto:simon;ldml.com ___ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
