This is an old webpage that makes available for download primers and plugins that can be used by LiveCode developers. These modules were created when LiveCode was called Revolution. The text and links are as they have been for years, but this page might change greatly or disappear in the near future.
May, 2012: I have to amend that statement. It seems that some folks have shown an interest in these. I'll check out some of them and even make some current. Look for my added comments below (in this style).
Revolution is a multi-platform development environment from Runtime Revolution Ltd. Because Revolution is multi-platform, these modules can be used almost anywhere. Also, these modules are very small. To aid in compatibility determination, listed with each module below is the most recent version of Revolution used in the creation of that module.
|A Simple Primer Primer 1.0|
July 25, 2003
Below is the first of a series of primers. They cover topics such as making primers, message mechanics (using the send command), the box library (rich lisp-like packaging), sockets (TCP/IP) programming and so on.
A Simple Primer Primer. This module (stack file) is a primer on how to build a primer by using itself as the basis. It is just a simple booklet with some hypertext. It can be handy for making primers, as well as journals and other workbooks. Both the stack script and the card script on new pages are available for your scripts. It is implemented as a single stack with most of the work in a single background. It features hypertext, navigation aids, context-reminding backtracking, uniform layout, text and active example areas, and script callouts. I recommend you get the latest when you actually start on a primer. It is Free!
|A Primer on Message Mechanics 1.0|
|August 18, 2003 Revolution 2.0.1 pmm10.rev.zip 80K|
A Primer on Message Mechanics. This module (stack file) is a primer on using send, cancel, pendingMessages and callbacks. Those are the basic Revolution components needed to get your stacks to do several things at the same time. The primer starts from the basics and builds on those, providing examples and details along the way. It is 88 tiny pages long and if that is not long enough for you, note that it is set up so you can add your own pages. It is fun and... It is Free!
|A Primer on Message Mechanics 1.2.1|
|May 24, 2012 LiveCode 4.6.4 pmm121.zip 80K|
May 16, 2012: I brought this up to date both in fixing some things that no longer worked in the primer stack and in pages on LiveCode quirks and bugs. Modem examples and callback discussion are a little dated, but overall this still applies very well. I added an encouragement for folks to use this as a basis for a booklet, if they want. I checked out the stack and the ideas in several LiveCode versions on many platforms.
Here are some free plugins for Revolution. Just drop the ones you need into the plugins folder that is in your Revolution folder. May 10, 2012: Today, one might use a personal "Plugins" folder in a folder named "My LiveCode" usually in the documents folder.
|Tiny Loupe 1.0|
Sept 30, 2003
Tiny Loupe. A loupe is a small magnifying glass used by watchmakers and jewelers. It is typically used hands-free. Similarly, this Revolution plugin is a tiny window that shows a magnification of the region around the mouse pointer. You don't have to turn it on or grab a special tool; simply glance over to the magnification view in your normal work. (The region is 20X20 pixels. The magnification is X8. These can be easily changed in the stack script.)
May 10, 2012: I tried Tiny Loupe 1.0 in LiveCode using LiveCode 5.0.2 (and often 4.6) on Windows XP, Windows 7, OS X 10.6 (Intel) and OS X 10.5 (PPC). I just dropped it into into the "My LiveCode/Plugins" folder within my documents folder. It worked; even with the .rev extension. (I did see some flickering when an IDE window got stuck under the toolbar in Windows 7, but it did not distract me.)
August 9, 2006
darzTimer. This microsecond-resolution performance timing plugin allows you to insert or remove a tiny timing API. The API can be inserted as a front script or as stack library. Though the long seconds can be used to access a high performance clock on OS X, such a clock is not available in Revolution for Windows, and even the high performance clock provided by Windows has reliability issues. The plugin provides a high-precision timer for those developing in Revolution with enhanced reliability and greatly improved jitter. The API is available only in the IDE.
This was made with Revolution 2.6.1, but might work for earlier versions. It was tested on 2.7.2. This has been tested on XP and OS X (both PowerPC and Intel). It should work on any platform, but is optimized for high resolution timing on Windows and OS X.
Simply call darzTimerStart to start the timing and darzTimerStop to stop the timing. Call darzTimerDisplay to display the results in the plugin if it is open. Non significant digits will be gray to give you an idea of the quality of the measurement. However, since operating systems tend to have a lot going on, a random amount of OS work adds to some timings. You can also get the results with darzTimerSeconds() and you can calibrate for call overhead.
To enable the API, open the plugin from the Development menu. There is an option menu to select the API mode, "Front Script", "Stack Library" or "Removed". There is a display of the most recent timing set by darzTimerDisplay. There is also a scripting reminder. You can close the plugin and the API will remain. If you subsequently want to remove it, simply open the plugin again and select "Removed" for the location.
Please let me know if the resolution does not seem to be that which is indicated. Also let me know if the text of the displayed time changes to a color other than black; that means the timer has to drop back to a fallback mode and the resolution is adjusted accordingly.
The package contains the plugin and a demo stack. Simply drop the plugin into the plugins folder of the Revolution installation. Play with the demo to get a feel for using the plugin. You don't have to worry about where to put libraries or externals; they are embedded.