[EMAIL PROTECTED] wrote: > Sorry it was a long time since I asked the question but I didn't have time.
With your ToolBook background i think you'll find it rewarding to download the demo... > I didn't try Revolution yet I just read the site. What are the best points of > revolution which can be found or not in Toolbook. - Self-contained EXEs (no DLLs strewn al over the user's hard drive) - Runs on nearly every major desktop OS - Somewhat simpler syntax (no data type declarations, simply "on" instead of "to handle") > If you know Tollbook very well (I have been an expert with this product by > being a consultant for Asymetrix and forming developpers but I gave up this > product because Asymetrix has been a disaster commercially in France) : > > - it doesn't seem to support Activex whereas Toolbook does (Toolbook is not > multiplatform) > then are components limited to revolution's ones ? For example I didn't see > any tree component so how would you show for example a xml-type structure ? > advanced GUI: support of thin caption and always on top window Rev's groups can be nested. In cunjunction with centralized code in libraries, this can make for very powerful complex objects that can be custom-built. There are a few tree controls and othr widgets and tools available at: <http://www.RunRev.com/Revolution1/developercentral/usercontributions.html> Rev also supports an interface for compiled code written in C. While the externals themselves would of course need to be compiled for each platform, the API is the same on all supported OSes. > - equivalent of Toolbook's script in groups and if possible sharescript > (script shared between several groups) ? The message path is almost identical to ToolBook's, and like ToolBook there are ways to insert scripts of other objects into the message path. Rev has frontscripts, which catch all messages before the natural target gets them. This could be useful for logging for example: when inserted you could log all events to a file and then just pass the message to resume normal handling; to turn off logging you just remove the logging script from the frontscripts queue. A corollary to frontscripts are backscripts, which as the name implies reside in the very back of the message path. Any object's script can be inserted into the frontscripts and backscripts. You can have up to 10 frontscripts and 10 backscripts at runtime; there is no practical limit when running in a licenced development environment. In addition to frontscripts and backscripts Rev has libraries, stack scripts inserted into the back of the message path with the "start using <stackName>" command. Libraries are behaviorally distinct from backscripts by the additoin of messages sent to the object being libraried providing notification of when it's brought into use and when it's removed from use. You can have up to 50 libraries at runtime, with no practical limit when in a licenced IDE. Rev supports just about all of the syntax for all forms of shared scripts in HyperCard, SuperCard, and OMO, but not all of ToolBook's: If memory serves (my last major ToolBook project was delivered in '98), ToolBook has one nice feature not currently supported natively: the ability to a specific script as the parent to specified objects. This is part of an ongoing discussion of proposed language features features on another list, and at this time it in uncertain when such a feature will find its way into the engine and what form it mnight take. In the meantime, if this functionality is important to you there are a couple different ways to implement parent scripts using native Transcript, with the limitation that it can only re-route system messages. For example, you could have all "mouseUp" events for a certain objects handled by one shared script and for other objects a different shared script. If you need it, I have a very modest example I threw together some time ago called "libD'oh!" (the poor man's OOPS) I could send you. > - equivalent of design (author) mode which can be scripted like runtime > (reader) mode Absolutely. One of the strengths of most xTalks (Rev, MetaCard, SuperCard, OMO, Gain Momentum, and of course ToolBook) is that the IDE itself is scripted, making it easy to extend and modify. Inevitably a project will have unique challenges that could benefit from production support tools to full automation; Rev can deliver both and just about everything in between. The Rev tutorials are a good example: When I wrote the first several drafts, I wanted to be able to focus on the instructional flow and not get bogged down in object layout. I knew we'd be going through several revisions, so I invested a couple hours up front making a tool that reads a text file marked up with simple tags and uses that to construct the tutorials from a template stack. This allowed for much easier editing and review, and completely separates UI from content so either could be changed without affecting the other. The licensing of the runtime engine is unusually liberal, allowing nearly all tasks except serious script to be performed from a standalone. This allows you to build custom content management systems, layout tools, etc. for team members while you get back to coding. Within the IDE itself, Rev provides easy extensibility with the Development->Plugins menu. Just make a utitity stack and drop it in the Plugins folder, and next time you boot Rev it's in the menu. I don't think there's another tool as close to ToolBook as Rev. And if by chance you find yourself doing contract work for the Munich government, you'd have to use a tool that can deploy on Linux ;) <http://news.com.com/2100-1016-1010740.html> -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: 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
