On 21/9/06 22:37, "Richard Gaskin" <[EMAIL PROTECTED]> wrote:
>> I believe the revGeneral library is always included. There is no option >> to turn it off, which is usually okay, since the majority of Rev users >> need at least some part of that library. > > What a strange design decision. > > I've helped more than a few people diagnose errors in standalones that > weren't evident in the IDE because of the additional objects being added > to their first card. Such errors are particularly hard to pin down > because the objects don't exist in the IDE, which is the only > environment that can run a debugger. > > I can see having an "Include revGeneral" option turned on by default, > but preventing people from doing anything else seems really odd. > > One more reason to improve MC IDE for the masses: it's the only way to > make truly native Rev apps. :) To suggest that a standalone is not a truly native Revolution application because it contains Revolution code libraries seems nonsensical. Does that mean that a standalone containing libURL is not a truly native Revolution application? There is no such library as "revGeneral". You may be thinking of the revCommon library. If this is the library you mean, it seems unlikely that this library would be responsible for a drop in performance given that the only system message it intercepts is mouseDoubleUp - sending a mouseUp to objects, in the same way the MetaCard IDE has done since the dawn of time. All the other message handlers in there are there to support those terms we define as part of the language definition and include in the dictionary. Basics such as revCopyFolder. Its quite a compact library. The bigger libraries are all optional. Whatever is causing the performance difference is unlikely to be that library. But if it is, well its like any other part of the product and could contain bugs along with the engine, the IDE, the OS, a database driver, etc. Errors introduced by including objects on the first card of a standalone are a pain, I fully agree. That original design decision historically stems from the need to deliver extensive functionality libraries (today in constant use in the vast majority of standalone applications out there), and not having control over the engine and therefore capability to create an official place to put them. Doing this better will come about as we improve the overall product architecture and create a place for this sort of thing. It won't come about by us hacking in a quick fix that will doubtless introduce its own quirkiness. Relative to the time you have already waited for this, it won't be much longer. In the mean time, rather than spending time being surprised that we would attempt to deliver feature libraries with useful functionality for our user base to include in standalones, we would as ever welcome constructive suggestions on how to continue progress on making what we have work better and more reliably. Kind regards, Kevin Kevin Miller ~ [EMAIL PROTECTED] ~ http://www.runrev.com/ Runtime Revolution - User-Centric Development Tools _______________________________________________ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard