Re: Proposed stack name changes for the MC IDE
On 30.06.2011 at 8:33 Uhr -0500 Ken Ray apparently wrote: For the next build of the IDE, I'd like to change the IDE stack names to have an mc prefix (like mcPreferences), but since this affects anything that runs as a plugin, etc., I wanted to bring it up for discussion first. What are your thoughts on this? Good idea? Bad idea? ...? +1 Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Statements from Kevin in 2003
On 11.04.11 at 13:54 +0100 Kevin Miller apparently wrote: My offer was to continue to support your capability to keep your IDE up to date by making it possible to continue to integrate engines and new features if you chose to do so. To that end we provided complete details of what is required to update your standalone builder to the keeper of your IDE when last requested a long, long time ago (over a year at least). Kevin, Klaus has just clarified the delay issue. However, I believe that the deeper issue is related to new standalone builder being completely (as opposed to partially) locked, which has created an obstacle for contributions from other MC developers, aside its official keeper. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Remove the password protection of a stack Application browser
On 16.12.2010 at 15:08 Uhr -0600 J. Landman Gay apparently wrote: Well, you do have to know what the password is to unlock the stack. The point being that you, as a developer, can get in but others can't. With the exception of http://quality.runrev.com/qacenter/show_bug.cgi?id=546 However, there was some changes somewhere in engine 4 that changed some of the behavior. I recall a discussion on the rev-use list but forget the details. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE 4
Hi Klaus, I hope that your health issues are resolved or at least under control and you have enough means and energy to last you until you find new employment, whatever that can and will be. Is working on MC a sort of self-therapy? Best greetings... Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MetaCard Setup 1.0.3
On 27.03.10 at 21:33 -0500 J. Landman Gay apparently wrote: Robert Brenstein wrote: I just created MetaCard 3.5. Everything seems to be working fine except that when it opens, the buttons of the home stack have no icons, just names. Clicking any button makes the icon show up. I wonder what gives. That's a really old bug. I think the fix is this mod to the Home stack that specifically puts the tools stack in use: on startup if the version =2.7 then start using stack mctools.mc if the platform MacOS then open stack mctools.mc end if set the defaultStack to Home reset cursors end if pass startup end startup I have added this not as startup handler but per Ken's instructions in the preopen handler of cd 1 script of the Home stack. Without this script inserted, the launch hangs up as I mentioned before. With the script, MetaCard launches and all works except that the home stack buttons have no icons until clicked. BTW, the setup stack works nicely. It does not, however, check whether the script of the home stack's card is modified. Without the mod (as described in the instructions posted in yahoo group), MetaCard hangs when launching. Right. It doesn't check for any scripts, it just moves the stacks from the download site. If you've made changes to your Home stack or other tools, use the option that adds the engine to an existing set of MC stacks (or move your Home stack into the new folder after setup finishes.) It could be cool if the setup script checked whether the above script fragment is added and pop a warning if it is not. Nothing more. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MetaCard Setup 1.0.3
On 28.03.2010 at 14:29 Uhr -0500 J. Landman Gay apparently wrote: I have added this not as startup handler but per Ken's instructions in the preopen handler of cd 1 script of the Home stack. Without this script inserted, the launch hangs up as I mentioned before. With the script, MetaCard launches and all works except that the home stack buttons have no icons until clicked. I have the handler in the first card of the Home stack too, but it is a startup handler, not a preOpenCard handler. Try changing your handler to startup; that was Mark Waddingham's suggestion. I think the tools stack needs to load very early in the process. Yap, things are as expected with startup handler... I gather the verbose instructions should be updated... Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MetaCard Setup 1.0.3
On 03.04.09 at 19:48 -0500 J. Landman Gay apparently wrote: Thanks to Tariel for finding the Rev library bug. There's a revised MC Setup stack online now with the bug fix, version 1.0.3: http://www.hyperactivesw.com/revnet/metacard_setup103.zip -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com I just created MetaCard 3.5. Everything seems to be working fine except that when it opens, the buttons of the home stack have no icons, just names. Clicking any button makes the icon show up. I wonder what gives. BTW, the setup stack works nicely. It does not, however, check whether the script of the home stack's card is modified. Without the mod (as described in the instructions posted in yahoo group), MetaCard hangs when launching. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Questons to IDE 4
On 03.01.2010 at 16:31 Uhr +0100 Klaus on-rev apparently wrote: Hi friends, I am currently working on the new MC IDE 4 and while I am at this, there are some questions concerning the output of the new standalone building process. OS X: Would you like to output a: ppc, fat AND intel apps at the same time like Rev does? This would require to create subfolder(s) in the target directory! b: ppc OR fat OR intel apps = only one app at a time? Know what I mean? I build standalones quite seldom and each time is a different situation. Would option c, a list of checkboxes which standalones to build, be possible? It would put us, the users, in control. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
RE: ask/answer annoyance
On 10.03.09 at 20:11 + Hugh Senior apparently wrote: Since it's modal, the window is blocking and has to close before anything can be done at all outside the modal. The only thing that springs to mind is you trap cmd.period in the modal itself. 2p /H Modifying the dialog to trap cmd-. is doable. However, the problem is how to pass that cmd-. further -- as Richard explained, the exit to top does not work as expected, that is the script exists to top within the dialog stack while the calling script continues. I wonder whether it is possibly to send cmd-. (in time) while closing the dialog. It should either carry over to the loop below or auto-cancel the next dialog popping up. A workabout I use is to have a cancel button in such a dialog and check for cancel in the looping script. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Use Valentina with MetaCard 2.5 ?
On 22/12/08 at 15:31 -0600 Ken Ray apparently wrote: Actually, I'm not completely in the yay-Valentina! camp. ;-) As Ken says, support is a big forte of Valentina. On the other hand, the documentation has been always somewhat deficient. At least, there is now a decent set of examples for V4REV. Each version of Valentina has its own quirks, just like Revolution. The development process is not branched, so one has to keep upgrading to get bug fixes, just like Revolution again. Overall, IMHO, I think it beats pants off of competition for desktop applications, particularly in terms of performance, although it became somewhat bulky as software (good that this is mostly not so important nowadays). I haven't used the server version yet, so no opinion there, but I haven't heard anything really negative, either. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Use Valentina with MetaCard 2.5 ?
On 19/12/08 at 12:51 -0800 Alain Farmer apparently wrote: Hello y'all, Is it possible to use Valentina with MetaCard 2.5 ? Or does it necessarily *require* Runtime Revolution ? N.B.: *not* even 2.6 .. it *has* to be for 2.5 .. because version 2.5 is what I got *and* I don't want to upgrade unless it's strictly necessary. Thanks y'all, Alain Yes. I started using Valentina with HyperCard and then switched to MetaCard. Revolution came along but I continue with MetaCard and Valentina. Which version of Valentina is optimal for your MetaCard is to be checked. I presume that by MetaCard 2.5 you mean Rev engine 2.5 with MC IDE. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: strange error in MC IDE script editor
Hi Ray, Greetings, This has been going on with m copy of 2.7.4 for several years. I hit the enter key, I get an error report that there's something wrong with the script, I look for the error, can't find it, hit the enter key again, and she closes just fine. As far as I can tell it has something to do with editing how the script was typed in. It seems the engine is still seeing text you've typed and deleted. I've grown used to it, but if anybody can provide a fix it sure would be nice. If this is really an engine issue (what I suspect) then it is almost impossible to provide a fix :-/ And since there is no recipe for this error, it is unlikely that the scots will investigate further. Was it ever determined that it is engine error? Is anyone seeing this error in Rev IDE? I use Rev IDE only sporadically and have never seen that error there. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: strange error in MC IDE script editor
This is the error: missing '' after literal Line: 0 Column: 0 ? What difference might the engine see in the first time hitting ENTER and the second time I hit the ENTER key? Anyone seen this, too? Any hints are very appreciated, this drives me crazy :-) Klaus, this is a really old problem. Search the archives of the list. I seem to start seeing it when a given project reaches certain size/complexity and scripts get longer. But even then shows up irregularly. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Automated setup file uploaded
2) What should be the trigger to read external file ? (preOpenStack in McTools.mc and home stacks? home sounds good, since this will be loaded first anyway. shouldn't this be handled by prefs handler? Or may be somebody has better idea where to save such info? In to the platform-specific prefs folders of course! Richard and I are planning to save everything that MC needs to save into an external file, so no stack will have to be saved in the future. Mabe in some kind of XML format. I wonder whether the overhead of XML (as small as it is) is truly needed for an internal data file. A simple token-based file would do the job and can also be versioned. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Automated setup file uploaded
Did not know that there is a special kind of script called pref handler ;-) There is a stack with preferences. I forget how those are put in effect but if all preferences are kept in an external file (if I understood you correctly), then these have to be combined. Of course I meant to put whatever kind of hanlder in the preopenstack handler of the home stack! Do we really want to modify Home stack? I wonder whether the overhead of XML (as small as it is) is truly needed for an internal data file. A simple token-based file would do the job and can also be versioned. Noone would mind if YOU do the job :-) I know. Unfortunately, I am way overbooked next few months. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Automated setup file uploaded
But I suggest that we remove the Demo button, since we do not want to include the sin of Mr. KM's youth (and that does NOT stand for Klaus Major) a.k.a. MetaCard Demo in the distribution, do we?! :-D Wasn't demo replaced (or supposed to be replaced) with preferences at some point? Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Automated setup file uploaded
I've just uploaded my version of the MetaCard Setup stack to the MC_IDE area on Yahoo Groups: http://tech.groups.yahoo.com/group/MC_IDE/files/ This stack will automate setting up the MC IDE and installing the latest Revolution engine. There are several options available; for example, you can automatically download the latest IDE, use an existing IDE (handy if you've edited your IDE stacks) and choose the version of the engine to install. Fantastic! ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Automated setup file uploaded
If the Finder window is closed during the installation there's no problem. If anyone knows how to fix that, I'll implement it. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com Isn't it possible to close the Finder window through Applescript? Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Automated setup file uploaded
Hi Robert, But I suggest that we remove the Demo button, since we do not want to include the sin of Mr. KM's youth (and that does NOT stand for Klaus Major) a.k.a. MetaCard Demo in the distribution, do we?! :-D Wasn't demo replaced (or supposed to be replaced) with preferences at some point? Not that I knew, and I SHOULD know as MC Poobah ;-) I think we had that discussion quite a long time ago. May be there was no consensus met. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: IsAstack ( )
On 02/07/07, Brian Yennie mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote: Reading from a file should be perfectly safe even if it is in use - writing is the dangerous one. True - but I see no advantage over using the built in exists() function and removing the stack from memory afterwards - it is not subject to file format changes, detects if a stack is corrupt and I doubt is any slower? Unless it is a really big stack and/or has lots of substacks. ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: [ANN] automatic metacard IDE creation tool
Related to that: Would it be possible to mirror the IDE stack files somewhere, where a program can download them (maybe ask runrev for a bit of space on their server?)? Additionally, is it possible not to use zip files (because that needs the zip.dll)? I recommend plain stack files, maybe gz, because these can be used within rev/mc. I had exactly the same thoughts, and just wrote to Richard about it (he hasn't answered yet.) I also want to avoid the external if possible, so would like to see the stacks individually gzipped. Richard will be setting up a permanent URL for the IDE downloads, which my stack also implements. I guess you and I are on the same wavelength. What about getting a custom domain for this project? It can be hosted by the current pubaa or anyone else who volunteers, and moved around as needed. It can be set it up, for example, as an add-on domain on some existing service, thus incurring no service fees beyond dns registration. And, as a reminder of experience with Revzilla, the server address should be editable in preferences, just in case. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: The Aborted Plunge (Metacard to Revolution)
If I remember correctly, this is because the HC script editor is a self-contained external (a version 2.0 external - which has some capabilities that the MC/Rev interface lacks). Since the script editor in MC is a stack, it can't take advantage of this. (Darn.) -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com I wonder whether it could be possible to call the script editor as a modal window when doing the all-script search. This would essentially reproduce the HC functionality me thinks. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: The Aborted Plunge (Metacard to Revolution)
I have asked several times since using MC about searching all scripts, and never got a really good solution. I MISS the Hypercard ss function. That was awesome! It just took you to each instance, let you change it, then moved on to the next one. Was HC's script editor modal? I'd thought it wasn't. If not, how did ss suspend while the script was being edited? Just for curiosity, I just launched HC and checked it out. Script Editor is modeless. The search script handler has if the script of this stack contains pattern then edit script of this stack repeat with curBgnd = 1 to the number of backgrounds ... All objects are checked the same way, so apparently the script suspends while script editor is opened and continues after it is closed. I don't have MC here to check. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
IDE versions
What the versions in the file archive in Yahoo referring to? Engine or Revolution distro? I fetched MC IDE from folder labelled Older versions of the IDE for 2.6.x and tried using it with engine 2.6.1 but got several errors when simply opening the IDE, which makes be think that this IDE is for engine 2.5.x. ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: (Not) deleting identical substacks - continued
On 11/13/06 5:02 AM, Wilhelm Sanke [EMAIL PROTECTED] wrote: Question: Should we try to remove the ambiguity of the delete button in stack stack components or is the problem perhaps of such a special and rare kind that is not worth spending any effort to fix it? IMHO, if it is a quick fix, then go ahead and do it... otherwise I think it's not worth the effort. Just my 2 cents, Ken Ray Sons of Thunder Software, Inc. Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] Ditto. It is rare but nevertheless does occur as you have proven and a command, delete in particular, should not do more than expected. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE: Passing the Poohbah torch and more
I have to say, Richard agreed to be our grand poohbah for six months, and it has stretched out to something like several years. Thanks for all your efforts and the wonderful job you've done, Richard. We all appreciate it very much. And a big thanks to Klaus for taking over this job. I know you'll be every bit as conscientious as Richard. We owe you both a debt of gratitude. Indeed! Robert Brenstein ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Stack file version
Richard Gaskin wrote: J. Landman Gay wrote: Putting my money where my mouth is, how do you guys want to handle the stackfileversion property? My preference is to allow a permanent default preference, and an interface to change it. I'd also like the ability to set it on the fly while saving (or RE-saving, something Rev doesn't provide). Then we'd have to decide how to implement an interface for that. Hmmm...I like the preference idea, and am open to suggestions about how the UI for an on-the-fly property. I knew you would say that. :) Okay, I'll take a stab at it, as long as people don't hold their breath. It is very busy here right now, so it may be a while. Setting up an option in prefs isn't as big a challenge as deciding an on-the-fly behavior. Like you, I'm open to suggestions. Would holding down one of the meta keys be too obscure? -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com Hmm, this sounds like a followup to some earlier discussion. When was that? I checked MC archives but see nothing within last few months. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: CGI and DestroyStack property
How did you manage to get MC recognized as an application? I talked about this with Sentman (quite a while ago) after my failed attempts and he said it is not possible to point to apple's apps disguised as folders. According to him, it was Apache limitation. I am not sure now, it was 3 years ago on one of our MetaCard projects. The application wasn't even build with the Carbon engine, and running on OS X in the OS 9 emulation mode. Here is a note that I've written on configuring the ACGI Dispatcher [text in quote are the new one]: Ah, okay, that was the powerpcc app. That works as it is a real app not a bundle. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: CGI and DestroyStack property
You have a point, but here is the situation. Each quiz would have 50-100 students at a time (so stacks would have to be created and saved on the fly) and it would be several quizzes per year, again new users, so eventually it would be thousands of stacks to read from. Scalability problem on top of potential speed problem. For such a scenerio, I would use a database in the back of MC rather than files. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: ColorizeScript challenge
Robert, I found readability increased greatly once the background color was darkened. In the Rev editor the white background made the colors appear washed out. You could set that color via the MB and give it a try there. The Constellation method is useful because there is a rhyme and a reason to the colors. You can even adjust the colors if needed. Mark Talluto -- Yeah, I have Constellation but haven't got to use it much yet. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: ColorizeScript challenge
On Apr 27, 2006, at 10:31 AM, Richard Gaskin wrote: And I don't colorize my scripts. How pathetic are we? Make sure Richard buys you a nice meal. I don't colorize either. What a couple of saps. That makes three of us. :) four! t -- Tereza Snyder I raise it to 5 :) Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: CGI and DestroyStack property
We managed to run a full MetaCard in graphic mode, and install a acgi dispatcher (http://www.sentman.com/acgi/) to emulated AppleEvent from Apache back to MetaCard, just like the old OS 9 days - but that's very different animal mind you. How did you manage to get MC recognized as an application? I talked about this with Sentman (quite a while ago) after my failed attempts and he said it is not possible to point to apple's apps disguised as folders. According to him, it was Apache limitation. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Background Objects?
This is probably earth-shatteringly naive, but: Why have I never come across background objects (and even been anaware that they can exist in RR/MC) since I stopped HyperCarding (about 7 years ago)? Is there an unsuspected benefit to using background images (i.e. can they be spread across a set of cards a la HC)? What a slow learner! sincerely, Richmond Mathewson The benefits are pretty much the same as they were in Hypercard with the obvious difference that they are objects (groups) in RR/MC. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE v2.6.12
I meant to mention this for some time but it keeps escaping me and I haven't had time to verify whether this was adressed in the newest IDE. When plugin manager tries to open a stack via alias and the file the alias points to is missing, a crash may occur. There should be a check added. I think something like if there is a file (the aliasReference of file plguinfilepath) Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE v2.6b12
For copyright reasons we can't include Rev's handlers directly in the MC IDE distribution. We can, however, create a library importer. Currently one needs Rev anyway to get the engine, and with some of the changes in an upcoming release of Rev it may be beneficial to require a Rev install somewhere on the drive to draw parts from anyway. I would rather wait for the next Rev release before adding such a critter to MC, but in the meantime if someone wants to make a plugin for importing Rev libs I see no reason not to. May be, while waiting for new features of Rev, we can get around import by having a plugin which keeps a path to Rev's folder and starts using selected Rev stacks. Anyone having MC license has also Rev license, so this should be ok legally. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: chmod osx 777?
I am trying to figure out how to do cgis in metacard. I am using OS X with web sharing to serve the pages. I've set the file permissions to read/write (apple cmd key I, 3 popup buttons) Yet the server says no permissions What ought I do differently? Were I using an FTP client I would want to CHMOD 777. But on OS X? Thanks! (Any info on CGI in MC is appreciated, I'm going through the info on Monsieur X's web site) You need to not only change permissions (CHMOD 777) but also set the group to www (CHOWN :www) . Otherwise, Apache (OSX's web sharing) will refuse to serve those files. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: movies in metacard?
In metacard you have these things called players... interesting. You tell the player the location of the filename. Also nice. E.g. directory/directory/foo.mov ok. nice so far. Here is my question: How can I get metacard to know that the file I am referring to is right there in the same folder as metacard *without indicating the full directory structure (e.g. c:\programs\metacard\project\foo.mov)? Is my question clear? I want to avoid indicating the entire directory structure for obvious cross platform compatability on distribution. I'd rather not import all the movies. I want to be able to refer to them locally either as in the same directory as the MC standalone or in a subdirectory of the directory in which the MC standalone is found *regardless* of the higher levels of the directory above the standalone. Is that possible? How? Look at the filename property. You can use it to dynamically build the path to the movie file and pass that to your player. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Revolution debugger issues
I can't answer your question directly, however, one of the things you wrote struck a chord: Because I can't debug it, I can't figure out where the problem is. You may recall, I wrote to Rev Support a few weeks ago vaguely describing a problem where garbage characters were intermittently winding up in global variables (that would otherwise evaluate correctly in the message box and simple scripts). This did not involve the debugger specifically, but as in your case, it was something that took me days if not weeks to track down. And I still have no explanation for why it happens. This won't help solve Jacque's problem but I have a year-old bug entry in bugzilla for a bug which involves bizzaire misbehavior with variables. I wonder whether there is a relation. My error started occuring only when the script reached certain level of complexity (as I kept adding additional functionality) and exhibits itself by finding non-existing word in a variable. I debugged this by writing values to text file (not using debugger) getting something like found word 17 of 15 where 17 is returned by wordOffset() and 15 is the number of words. I have reproduced this behavior in a few different versions of the engine on two platforms, so it is quite persistent. Changing the script, though, shifts the error: it is reported for different database records (the records processed were always the same) which implies things being messed up in memory somehow. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: savingStandalone and standaloneSaved messages
There are two Rev IDE message which may be useful to add to the MC IDE: savingStandalone -- sent just before the build standaloneSaved -- sent just after In spite of the departure from convention, the absence of the rev prefix does NOT mean these are engine messages. This means that to support them we need to add them ourselves. It wouldn't be hard to do, and would allow folks to have an automatic trigger for things like StripAndShip handlers. Any objections to my adding these? -- Richard Gaskin Fourth World Media Corporation You mean that the standalone builder in Rev sends them and you want to add the same to standalone builder in MC IDE. If so, sounds good to me. No harm to having them and new possibilities to automate some stuff. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: mctools.mc v2.6b11 posted
I noticed that the Message Watcher is perhaps the only window in mctools.mc that has its backgroundColor set, and to a drab gray at that. Should this window remain colored, or should we clear the backgroundColor for consistency with other windows in the IDE? consistency rules for me :) ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: mctools.mc v2.6b10 posted
Once we confirm the IDs of the splitter cursors in Rev, should we update MC's to match those? I'm inclined to say yes to be done with it, even if the numbers are oddly out of sequence. Objections? -- Richard Gaskin Is there a way to somehow set references to the cursors at startup in order to keep compatibility with earlier engines? I mean a startup script checking the engine number and setting custom properties for example, which are then used elsewhere instead of id's directly? I may be totally of the wall with this since I have no time to dig into the source codes at this time. But such a dereference would make IDE more immune from any changes in this area that RR springs on us in the future. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: mctools.mc v2.6b10 posted
The general consensus has been that we should not be afraid to break with versions more than a year old, and at the time it seemed I was the only one who liked the idea of having MC IDE compatible with all versions of the engine since it went open source. But your suggestion sounds workable, and can be done with acceptable effort. Given that v2.6 is the first MC IDE with plugins support perhaps it's worth doing this for now, as long as we all acknowledge that at some point down the road it may become a good idea to just take the plunge and break with the past, keeping old versions available for use with older engines while moving the current version forward without saddling itself with that responsibility. If there are no objections I'll make that change once we confirm the cursor IDs for splitters in Rev to avoid further incompatibility issues. Yes, we should not be afraid to break with the past. But if compatibility can be preserved with little effort, then it should still be preferable. Besides, cursors issue is not quite a regular incompatibility and it is not 100% clear that the issues are settled. The only other change outstanding at the moment is the proposal to move the storage of pres out of the Home stack and into the Preferences folder on Mac, Application Data on Windows, and a mcPrefs.mc file in the program folder for UNIX/Linux. The benefit to doing this is that it begins to free us from being bound to the Home stack, which we know will need to be replaced at some point down the road, and allows options like FlipsIDE to retain prefs when flipping into MC from Rev. If this idea remains attractive to the community it might be nice to include it in v2.6 because at that point we have no firm enhancements planned, making it a more complete baseline build that we can stick with for a while. If there are no objections to doing this in this version I could incorporate that into B11 for your review. I concur that it might be a good time to move prefs out. It has to happen sooner or later. I haven't had time to check b9 but I thought this was one of the changes added already by Klaus. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Pasting images: purity or usability?
Ah yes, the cursor ID issue. I had held out hope for apparently too long that backward compatibility would ultimately become the higher priority, and that they'd adopt the principle of introducing new cursor images with new IDs in a quick bug-fix release. But it's been long enough that it seems perhaps time that we all consider updating all of our software to correct for that anomaly, and that would include the MC IDE. Should we update our cursor resource IDs to match the latest engine? Seems we're moving to a world in which is increasingly difficult to have a single IDE that works with multiple engines (consider libURL too), and thus far I think I've been the only one striving for that anyway. I don't mind updating those resources if the general mood here is that it's time to do it. Indeed it seems that RR is sitting this one out, so we can probably assume it ain't gonna change back. Otherwise, they would have corrected it right away. I just think they are hell bound to eliminate the hand cursor. The only problem I see with fixing this in MC will be backwards compatibility with earlier engines. Necessary is the only question. We can't determine how long this legacy bug with image pasting will remain in place, so if we want improved behavior it seems more productive to do what we can with what's in hand than wait for an unknowable possibility down the road. So do we really want this behavior? I'd find it useful, but I'm not sure if that's a universal desire; maybe some folks like the current behavior (can't imagine it, but HyperCarders sometimes have the strangest habits and this behavior seems to play into the only-one-bitmap HC paradigm). Would be it plausible for you as the head of the MC IDE group to inquire with Kevin directly about their policy/plans regarding such engine bugs? Possibly each one should be addressed individually. Then we can make an informed decision. I'm not clear on why so many engine issues are addressed only in their IDE scripts, but since I work on the MC IDE and neither the engine nor their IDE it wouldn't be productive for me to conjecture. My job is just to get the best results I can with what I have to work with at the moment, and leave the learnability of the Rev IDE to its keepers. It may be that they decided to pretty much freeze the engine and fix all that is possible only in IDE from now on. It probably simplifies their development cycle. I would not want to accuse them of malice and stabbing MC in its back yet, but it surely starts looking like they do little things that will lead to its slow death. It sure would be nice if some of the things were finalized and we get the next formal release of MC IDE out of the door. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Usage poll reminder
If you haven't voted in the MetaCard Usage Poll, please take a moment to do so: http://groups.yahoo.com/group/MC_IDE/surveys?id=11737473 There are currently 318 members in the MC IDE group, but fewer than 80 poll responses and only 45 of those indicate that the MC IDE is their primary work environment. That poll will help us better prioritize the level of effort to go into future versions. Thanks! -- Richard Gaskin Fourth World Media Corporation I wonder whether the usage of MC IDE changes once your FlipsIDE is released. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: casesensitive with cd name
Halo, my problem: given is a stack with 4 cds. There name is el, El, al, Al. in fld 1 of each of them is the name of this cd: el, El... put fld 1 of cd Al - the result is al also if you put set the casesensitive to true put fld 1 of cd Al - the result is al. The same result is with looking for El Also : go cd Al (or El) - you are brought to cd al (or al) How can I reach exactly that cd I wish? Thanks in advance. Christoph Is that problem solved in rev.? I doubt. As I recall, all object and variable names are case insensitive by definition. This is engine matter, so no difference between MC and Rev. You just need to come up with another naming scheme. If you really need to use things like 'el' and 'EL', you try encode or digest functions to convert them to unique strings. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Id numbers vs names
A long time ago I read where the safest way of referring to an object was to use its ID number, rather than the name or number. The reasoning against using the number was that it can change. I don't recall the reasoning behind the name, though I use names for most of my coding. Using long id is convenient and safe when dealing with dynamic objects or parallel stacks or cards that have objects with same names and an alternative to fully qualified control references. Otherwise, using names is usually better. In my experience at least. But object ids should not change by themselves. At least I do not recall such an instance. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: New prefs scheme for MC
Hi all, ... Makes sense... Maybe i could check the mcversion of stack mctools to differ between the different IDEs? Sorry, but this sounds like rubbish :-) Maybe i could use a combination of the version the buildnumber which should be unique, at least somehow ;-) Regards Klaus Major Klaus, I am afraid that any such a scheme is fallible. If I install a new build, suddenly my preferences will be gone, for example. What about having more options instead if the two discussed earlier - preference settings in the Home stack - preference settings as a file in 'Preferences' folder * - preference settings as a file in IDE's folder * - preference settings as a user-specified file *) wording must be adjusted to fit all systems In the last case, user specifies the location and name of the file. A simpler variant would allow only to set the name but use the preferences or IDE folder for location. This passes the buck to the user but allows us to easily share pref files or pick a specific file after upgrade or new install or when launching a new copy for some testing. It would also offer sharing options in multi-user environments me thinks. The issue then is where to store info about the custom location and whether it should be absolute or relative path. Well, just brainstorming :) Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: Bizarro behavior explained
Hi Richard and all, Robert Brenstein wrote: Though only for a short while: Klaus Major has devoted some of hius seemingly boundless energy to revising the preferences for the MC IDE so it will no longer rely on the Home stack but store them in Prefs (Mac) or Documents and Settings (Win) where they belong. So the upside is that in the future all your IDE copies will use the same prefs. The downside is that it won't help you identify issues like this one. :) -- Richard Gaskin Fourth World Media Corporation Does that mean that one won't be able to run multiple copies of MC each with different preferences? I sometimes run 2 or 3 copies at the same time. Hthat didn't come up when Klaus was discussing it here. Yo, surprise, surprise :-) Either I slept through it or I missed it somehow but I do not recall this being discussed :( How many v2.6 IDEs will you be running? Klaus -- feel like adding multiple support for multiple IDEs? Hm, yes, but may need some hints on how to differ between the multiple IDEs? Any suggestions? Maybe adding a checkbox to the prefs stack save prefs external? This way it is up to you to use the homestack instead... Yes, I think such a checkbox would be the simplest solution. May be better to have it reversed, though X - use preferences in home stack Making the externally stored the default. Use applies here to reading and writing. The only thing to consider is what to do when user changes this setting. Hmm, may be just ask user what to do (retain currently active prefs or reload from the newly selected location) Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
Re: FipsIDE (was: MC IDE problem)
Future enhancements --- The final version will work from modules residing in a subfolder of the Plugins folder, probably to be called something cryptic like FlipsIDE Modules. Each modile will be simply a stack file with a stack script containing two handlers: one for loading a specified IDE and one for purging it. It will ship with at least two prefab modules, one for MC and one for running with no IDE at all. It will be easy to write the load/purge handlers, so we could see modules for any third party set of tools that comprises a complete development environment. From the list of installed modules you'll be able to set one as a default, so that launching Rev with FlipsIDE installed will cause FlipsIDE to automatically flip into the specified IDE if desired. So in fact, we will need a separate module for each release of each IDE since the list of components may vary between releases (this applies only to Rev at this time). I wonder whether each IDE should not have a built-in function that returns a list of its components, so FlipsIDE (and any other utils) can get it dynamically. This would keep the number of prefab modules down on the long term. Rev's suspend development environment function must use such a list. Robert ___ metacard mailing list metacard@lists.runrev.com http://lists.runrev.com/mailman/listinfo/metacard
RE: Display of groups in Control Browser
If it's an engine bug, it's of interest to the keepers of the engine. Once we can pin down which line(s) in MC's Control Browser are at play we should be able to provide exactly what the need to do to address it. Moreoever, if it's truly an engine bug there's more at stake than just the MC IDE -- any script that uses a similar method to derive a list of controls will be similarly affected. I ran into this one when working on one of my new creations. It seems that something other than an integer is placed into the variable using the number of layers. Try this one: create a new stack with button: on mouseUp -- test 1 put the number of layers of this cd into test put Test 1crtestcr subtract 1 from item -1 of test put testcr after msg -- test 2 put the value of the number of layers of this cd into test put Test 2crtestcr after msg subtract 1 from item -1 of test put test after msg end mouseUp you should see: Test 1 1 1 Test 2 1 0 Odd hey! I've added this to the bug report. Cheers Monte Monte, excellent sleuthing! Have you tried chartonum on all chars returned? Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: moving stack
Upward shifted by approximately a titlebar's height. At what place in the opening sequence is the window reduced to hide the menubar? Or would it be better to get the loc and adjust it to account for the menubar before storing it? Shari I think it may be simpler to correct the loc before saving it since the situation is very clear at that point. Half of the height of the menugroup is probably about the same as height of titlebar. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: moving stack
Trouble I'm running into is that it remembers the wrong coordinates. When I save the coordinates for future reference, somehow Metacard is calculating the titlebar into it. When I save the loc of the stack, it saves the loc, but when I close/open the stack and reset it to the saved loc, it is opening at a location slightly higher than the location that was supposed to be saved. Just enough to assume the titlebar is the culprit. I can't find anything anywhere about the height of the titlebar to take it into account and open to the new location accordingly. set the loc of stack xyz to the savedLoc - the titlebar height That's what would fix it, but that doesn't exist. I did however discover that one of the cards seems to have gotten larger than the stack size. Don't know how and the card sizes never change. It opens at the proper stack size but when I get the rect of the card versus the rect of the stack, there is a HUGE difference. (More than the differential of the savedLocation issue.) Shari Would you happen to have a menubar in that stack? May be that is the cause of the shift. I can imagine that the loc returns the loc of the visible portion of the stack whereas you set it upon reopening before the window was reduced to hide the menubar group. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC 2.5 ramblings...
There's a proposal floating around in Bugzilla to put the Rev license scheme fully into the engine as it was with MetaCard. This would mean that the engine could be used with any combination of IDEs without risking licensing issues. I don't know when that will be implemented, but yes, there does seem to be an interest in moving in that direction. But what that means for now? Does MC IDE must add/support Rev's style license handling? May be this will get clarified in Malta (you guys are so lucky you can go there). PS: It's definitely FlipsIDE, as in Flips IDE, if for no other reason than to maintain the tradition of cutey-pie names begun with my UmbrellaMan plugin (which catches events like an umbrella). :) Flips-ay-dee-eeh seems too long for my battered brain, so I somehow shortened it, at least for myself, to read as flipsie but Ken's flip-side makes it more mnemonic indeed. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: libUrl documentation and download
Until the RunRev site has the libUrl documentation back up again, you can view it here: http://www.lacscentre.co.uk/liburl/ Excellent -- thank you! indeed But as always, I'm open to opinions. It won't affect Rev folks, and it seems few MC users use the same copy of mctools.mc across multiple engines, so it seems I may be the only one affected. Don't bother on my account. I need to build a libURL multi-loader for myself anyway, and I'll happily share it if we can find anyone else who would want it. I am more or less regularly using different engine/ide combos so I may be game for this. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: new libURL?
Anyone have a URL to the latest version of LibURL which is compatible with the latest engine? I can reconstruct one from dissecting Rev, but I'd rather use the one from the official download URL. That is, if there is an official download URL. :) -- Richard Gaskin Fourth World Media Corporation Wasn't the url for download just recently posted here by the author? Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: erroneous errors again?
On Sep 22, 2004, at 11:21 AM, Richard Gaskin wrote: Are you folks seeing blank or incorrect errors being reported with engine v2.6.1? Yep. I already bugzillaed one right here: http://support.runrev.com/bugdatabase/show_bug.cgi?id=2068 I get that error regularly. I just can't get a recipe to make it happen on command. -- Best regards, Mark Talluto It seems like a reincarnation of the error we discussed at length a while ago. I do not seem to be able to find it (the old one) in Bugzilla so may be it was never enterred there. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Protected stacks in 2.61 (was For goodness sake!)
It may be appropriate to bring up again the default setting of the destroy property for new stacks. Should it be made on or remain off? Made on by default - more often than not, you want it set to true, IMHO. In my own work it usually makes little difference. What are the benefits each way? -- Richard Gaskin The first thing I always do when creating new stacks is to set destroy on for the reasons that Ken outlined plus password protection. In fervor of testing the cloning, I forgot to set it and was surprised that password protection was not working. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Protected stacks in 2.61 (was For goodness sake!)
Good points. I'll add a preference for that in the MC IDE. Of maybe better: how about the ability to define a stack to be used as a template for new stacks? That way we can handle destroyStack, alwaysbuffer, rect, and anything else we want exactly as we want it. Worth pursing a change to the default behavior of the engine? I'd love to see the alwaysBuffer set to true as well Yes, yes, being able to define an alternative template stack would be great (aside from setting destroy on in the built-in one, and I'd vote for setting buffering on as well). Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Protected stacks in 2.61 (was For goodness sake!)
On 9/17/04 9:54 AM, Robert Brenstein wrote: Not instating password protection upon close is yet another issue and I will Bugzilla it as well. It is not new to 2.6.1 but it did not check how far back it goes. Not a bug, and it goes back to the beginning of time. Password protection takes place when the stack loads. If you have the destroystack set to true, closing and reopening will set password protection. If you have destroystack set to false (which is the IDE's default setting for new stacks) then reopening the stack simply displays the copy already in memory and does not reload it. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com Ah, yes, gotcha. It may be appropriate to bring up again the default setting of the destroy property for new stacks. Should it be made on or remain off? Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: hand cursor
On Sep 16, 2004, at 2:15 PM, Ken Ray wrote: Personally I think this is invasive and IMHO unnecessary. What was the problem with just setting the defaultCursor when the IDE starts up? Sorry, I just don't get it... The idea was to implement something that could transparently make the switch through the entire development process. setting the defaultCursor would have broken if anyone set the defaultCursor and then emptied it, expecting to get back to the arrow. It also would have required inserting code into the developer's project at build time, which is something I wanted to avoid completely. regards, Geoff Canyon [EMAIL PROTECTED] I don't care to dig into what is done right or wrong. When I use 2.6.1 engine with MC IDE, I seem to have the hand cursor in the browse mode in IDE as I would expect and get it back on idle after changing it in handlers. Great. However, when my handler says set the cursor to hand, I don't get a hand and that is obviously a bug that needs fixing. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Protected stacks in 2.61 (was For goodness sake!)
It is all rather worrying, Robert, and I can confirm that simply closing a stack no longer re-sets the protection. Bug 546 (http://support.runrev.com/bugdatabase/show_bug.cgi?id=546) requests the ability to re-set protection without closing the stack, but it only has 15 votes. If 'clone' is a different issue, perhaps someone should bugzilla it. However, since there is an increasing number of 'prohibited actions' in protected stacks including 'clone', I would humbly suggest that v2.61 could be considered 'broke' in this respect and in critical need of repair by addressing 546 urgently. Yip... Hugh still has a serious bee in his bonnet on this one! /H Yes, cloning is a totally separate issue. I am entering this in Bugzilla so RR people can sort it out. As far as I can see, this is an undocumented change of behavior. Not instating password protection upon close is yet another issue and I will Bugzilla it as well. It is not new to 2.6.1 but it did not check how far back it goes. If 546 was in place, we could have a workabout. As it is, there is nothing we can do AFAIK. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Protected stacks in 2.61 (was For goodness sake!)
Yes, cloning is a totally separate issue. I am entering this in Bugzilla so RR people can sort it out. As far as I can see, this is an undocumented change of behavior. Not instating password protection upon close is yet another issue and I will Bugzilla it as well. It is not new to 2.6.1 but it did not check how far back it goes. If 546 was in place, we could have a workabout. As it is, there is nothing we can do AFAIK. Robert Bugzilled and open for comments: http://support.runrev.com/bugdatabase/show_bug.cgi?id=2204 http://support.runrev.com/bugdatabase/show_bug.cgi?id=2205 Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: hand cursor
[EMAIL PROTECTED] wrote: was changed from 8 to 28 as requested by runrev. The MC IDE should be updated clone the hand and set it's id to 28. Thank you for chiming in on this. Always good to have feedback from the mother ship. I recognize that RunRev believes the current implementation is complete, but it appears they did not implement or perhaps misunderstood the spec that they'd worked on which would have also provided backward compatibility as well. ID 28 is used by the splitter. We could change that too, and the arrow cursor and its affected compliment along with them and other IDs in use for a decade before Rev was born, but before we slide down that slippery slope I'd prefer to ask that the team review the spec and decide if they're fully satisfied with the current implementation. Remember that the first solution was to yank the hand cursor altogether, until sufficient discussion warranted a re-think. I'm hoping things can remain as open-minded. I believe implemeting engine changes in ways that don't break the MC IDE is a relevant consideration. Given the implications for other legacy works it may be best for all to use the spec they'd defined for this. -- Richard Gaskin Fourth World Media Corporation I second that :) I think there was too much focus on the appearance of the new cursors and the whole concept of dropping the hand cursor that the technical implementation aspects were overlooked in the pre-release testing. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: For goodness sake!
This is now becoming crippling... After v2.5 - We cannot clone an object - We cannot copy an object - And we cannot set the script of an object if a stack is password protected (I'm using v2.6.1 build 9). All workarounds seem blocked. Okay, top marks for consistency but for goodness sake...! Aaaargh! /H I just tested this under OS9. Engine 2.5.1 and 2.6 drag-copy a button - works for password-protected stack clone a button - works for password-protected stack clone a stack - works for password-protected stack set the script of btn - error that stack is protected Engine 2.6.1 drag-copy a button - still works for password-protected stack clone a button - error msg that stack is password protected clone a stack - error msg that stack is password protected set the script of btn - error that stack is protected So there is definitely change in behavior of the clone command. I do not see anything related in Bugzilla or mentioned in Whats New. What I found worrisome is that when I create a new stack, password protect it, close it (close box or msg box command), then open it again, it is NOT password protected. If I quit MC to flush memory and relaunch, the password protection becomes active. Fortunately, this is likely an issue at development time only. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: ReSet passkey (was For xxx sake!)
So what's the next step? How easily/quickly can Tuv (?) close the loophole that has been created in 2.6.1 so clone (and other commands that have now been disabled) can be made to work again in a protected stack? I am assuming bribary is allowed? I guess vote for bug 546 :) As you can see from its number, it has been entered a long long time ago. If enough people vote on it, may be it will be addressed. Technically, does not seem much work for me since most of the code is already there. And what's the workaround to allow 2.6.1 users access the features in a protected stack with these requirements? I guess the only way is to close and reopen stack if that does not mess things up for you. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: 2.61 Hand Cursor
Looks like you have already reported, Robert. Thank you. Meanwhile, importing a 'hand' image and hard-coding the stack internally is a work-around. I just voted for it and added a comment. I meant earlier that you should bugzilla the clone/copy problem if it is indeed verified to be a problem. The hard drive on which my copy of MC was just gave up the ghost, so I can't check this out until tommorow at earliest. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Copy command in 2.61
We seem to have a related issue to the broken 'clone' command in password protected stacks in v2.61... 'Copy [obj] to [dest]' results in a 'Can't cut object [stack is locked]' error. Can anyone else confirm this? Similarly, we used to be able to 'get' and 'put' scripts in password protected stacks (for example on mouse enter; put line 1 of the script of me into fld feedback). This also broke under engine 2.5 I suspect a plot to disable any form of self-modification! /H Hmm, let me get this straight. You were able to change the scripts without setting passkey (unlocking the protection)? That should not be possible and it would be a bug if it was. If this happens after passkey is set, then it sounds like a bug to me (if there is no failure setting passkey). RunRev is indeed keeping the dynamic scripting (self-modification) under wraps so do speak. See Tuviah's comment under bug 546: http://support.runrev.com/bugdatabase/show_bug.cgi?id=546 Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: 2.61 Hand Cursor
What on earth has happened in this release? 'Set the cursor to hand' now results in a vertical splitter icon! Oh boy... This is not the robust and predictable environment to which I had become accustomed. It would help (or at least show willing) if such changes were flagged in the ReadMe notes. Do we have any other surprises in store, waiting to trip us up? Yap, RR decided that hand does not look professional, but setting it explicitely to hand was supposed to continue to work afaik. Richard may know better. I seem to recall someone complaining about this vertical icon. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: For goodness sake!
Hi Klaus, Not entirely true. v2.5 prohibited set/get script and copy [obj] in password protected stacks, but clone has always been available. My points: [1] I can appreciate protecting script and copying access to prevent circumventing protected stacks, but clone can do nothing except duplicate in the same environment. bugzilla this ! I am still not clear, though, if your errors occur in password-protected stacks that are locked or unlocked. May be I missed a post. I will need this to work soon, so I'd like to test it out. [2] If dynamic scripting in protected stacks is being 'phased out', we need to be able to unlock, do whatever, then *re-set* the protection. This last step is not available, and until 2.5 was not required. Not only should it now be available, but it has become a CRITICAL command. vote for bug 546 :) Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: 2.61 Hand Cursor
What on earth has happened in this release? 'Set the cursor to hand' now results in a vertical splitter icon! I found this in Bugzilla. See Bugs 2032, 2103, 1846, 1807. According to the last one, things should be working as you expect them, so you may request reopening that bug. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC usage poll: 47 votes
We got our 47th vote at the MC IDE usage poll today: http://groups.yahoo.com/group/MC_IDE/surveys?id=11737473 Whoohoo! With 175 members, we only have 128 more votes to gather. This is a very helpful poll, which helps determine the level of effort put into the MC IDE. Please take a moment to cast your vote there. Thanks. -- Richard Gaskin Fourth World Media Corporation May be you should post an invitation to vote also on the Rev list since not MC users are necesserily members of this list. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Version conflict
Do I need to worry that I get a Tools stack version (2.6) does not match engine version (2.6.1) message with the current mc.exe and IDE stacks? nop that dialog should have a checkbox do not show same warning again. This would require modifying the home stack unfortunately. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: IDE and libUrl
I'd propose that we do with libURL what we did with the Standalone Builder: have two versions included in the IDE, and use the version appropriate to the engine being used in that session. Can anyone think of a downside to that? For the sake of simplicity I like being able to use one IDE build across all versions of the engine from the time the IDE went open source going forward. There may be a time when that goal is no longer supportable, but as long as it is I think it's worth doing. Any downsides to the approach for libURL proposed here? -- Richard Gaskin I think it is a good idea to have two different versions of libURL available if that is needed to support larger range of engines. The only addition to consider is being able to query the version number of the currently used one. May be it is already supported. This actually could be a common feature of all components (mainstacks as well as substacks) of IDE. In my opinion, aside from the overall release number, each component should have its own version number. Rather than creating a function for this, we could agree on all stacks having a custom property, for example, mcStackVersion, that could be queried by whatever means one desires. If we want to be more sophisticated, we could have a set with version, date, author, changes. By the way, when implementing both versions, are we going to have libURL inited at startup now or the current practice of each urlLib call librarizing it again will continue? The copy I got lately from Chipp is an installer with separate buttons for Rev and MC, so patching the code with missing libraryStack handler could be done in the installer. I am sure the author will agree with that. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Proposed Icons for MC
We might want to give some thought to image IDs, for Rev compatibility where practical and to avoid conflicts with current images IDs. Suggestions? Well, I'm fine with changing the IDs of the current images in MC, but keep in mind that this may conflict with other people's icons (i.e. they may have provided their own replacements and now they won't work). I honestly don't think that anyone created images in that ID range for other purposes (because they shouldn't have according to the MC docs), but I can see accidentally kaboshing people's answer/ask dialog replacement icons. Does anyone have any objection to me changing the IDs of the icons in the MetaCard IDE to use the same ID numbers as Rev uses for their icons of the same type/name? Or is there a better suggestion/approach? Ken Ray While at it, you might want to fix the little issue of icons staying put in the top location instead of sliding down if the dialog content is long. Using icon ids from Rev might be a good idea if it works as it would ensure full compatibility between environments. People who happen to used those ids will have to change their code when switching to this version of IDE. I don't think it is too much to ask. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Proposed Icons for MC
We might want to give some thought to image IDs, for Rev compatibility where practical and to avoid conflicts with current images IDs. Suggestions? Well, I'm fine with changing the IDs of the current images in MC, but keep in mind that this may conflict with other people's icons (i.e. they may have provided their own replacements and now they won't work). I honestly don't think that anyone created images in that ID range for other purposes (because they shouldn't have according to the MC docs), but I can see accidentally kaboshing people's answer/ask dialog replacement icons. Does anyone have any objection to me changing the IDs of the icons in the MetaCard IDE to use the same ID numbers as Rev uses for their icons of the same type/name? Or is there a better suggestion/approach? Ken Ray While at it, you might want to fix the little issue of icons staying put in the top location instead of sliding down if the dialog content is long. Using icon ids from Rev might be a good idea if it works as it would ensure full compatibility between environments. People who happen to used those ids will have to change their code when switching to this version of IDE. I don't think it is too much to ask. Robert Brenstein I mean that the icons now slide down whereas I'd want them to stay put. Am I the only one noticing this? Robert Brenstein PS the new icons are really great. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: pre-installed plugins
I was thinking it might be useful to include the GoRevNet plugin in the MC IDE distribution. I certainly don't want to start a trend of loading the distro with all sorts of non-essentials, but one of the nice things about RevNet is that it opens the door to easily getting others. Should we consider adding GoRevNet to the final distro for v2.6? Any other plugins that should be pre-installed? Or should I ditch the idea altogether? -- Richard Gaskin Fourth World Media Corporation Yes, it would be nice if a few plugins were included. GoRevNet could be one of them. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE v2.6b6 posted
I am having trouble using an alias in the plugins folder. I've tried both OS X native aliases and unix-style symlinks. Symlinks used to work in MC (though I could never get them to work in Rev) but now they don't work in MC either. Anyone else? This has not changed from b5, which has been out for nearly 6 months. The routine needed for checking the initialization properties must open the stack file to get at those properties, and I believe that while open stack honors aliases get the whateverProperty of stack does not. There may be a way to use aliasReference for that. Care to add support for that? This has been quite a while but I am pretty sure I tested at least Finder aliases and they worked. May be you are using a newer engine and there was some change there. Also, in the programming plugins text file, there is a reference to a Revolution property: In Revolution, the opening mode is defined for each plugin through Plugin Settings. To make MetaCard's plugins compatible with Revolution, you need to set the custom property: And no property is named. Don't keep us guessing. ;) Robert, got time to finish that? Here is the complete text: In Revolution, the opening mode (open-as mode) is defined for each plugin through Plugin Settings. To make MetaCard's plugins compatible with Revolution, you need to set the custom property: set the cRevLoadInfo[mode] to empty -- palette set the cRevLoadInfo[mode] to modeless -- modeless set the cRevLoadInfo[mode] to modal -- modal set the cRevLoadInfo[mode] to invisible -- invisible I will send the latest version of that file directly to you, Richard. You will need to edit it after all since you are removing active plugins. I intend to maintain my own version of plugin manager which supports active plugins. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE v2.6b6 posted
Robert Brenstein wrote: I am having trouble using an alias in the plugins folder. I've tried both OS X native aliases and unix-style symlinks. Symlinks used to work in MC (though I could never get them to work in Rev) but now they don't work in MC either. Anyone else? This has not changed from b5, which has been out for nearly 6 months. The routine needed for checking the initialization properties must open the stack file to get at those properties, and I believe that while open stack honors aliases get the whateverProperty of stack does not. There may be a way to use aliasReference for that. Care to add support for that? This has been quite a while but I am pretty sure I tested at least Finder aliases and they worked. May be you are using a newer engine and there was some change there. I wonder why they also break in Rev?: http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=484 This should be tested further to see whether it is an engine or IDE issue. I just retested in OS9 and no problems here. Also, in the programming plugins text file, there is a reference to a Revolution property: In Revolution, the opening mode is defined for each plugin through Plugin Settings. To make MetaCard's plugins compatible with Revolution, you need to set the custom property: And no property is named. Don't keep us guessing. ;) Robert, got time to finish that? Here is the complete text: In Revolution, the opening mode (open-as mode) is defined for each plugin through Plugin Settings. To make MetaCard's plugins compatible with Revolution, you need to set the custom property: set the cRevLoadInfo[mode] to empty -- palette set the cRevLoadInfo[mode] to modeless -- modeless set the cRevLoadInfo[mode] to modal -- modal set the cRevLoadInfo[mode] to invisible -- invisible In cases where desired functionality is also available in Rev I would indeed honor the Rev method. But in this case the desired functionality is already in the engine, in the built-in style property of stack. I don't follow the reason behind your comment. The above was just documenting what Rev does for those who want to have MC plugins compatible with both environments. Given that, instead I would recommend that Rev follow the engine method, which is what the MC IDE relies on. This recommendation has been submitted: http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=1077 But your suggestion, Richard, while useful in itself does not address the main point: one should be able to place an alias in the plugins folder. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: MC IDE
Klaus Major wrote: Hi folks, the new engine (or more precise the new RR IDE) will drop the good old hand cursor... I think we will have to take that into account? Any comments/hints/suggestions? That's a bug, which I would imagine would be fixed before 2.5 is released. Removing the hand cursor completely would be a horrifyingly bad decision if it were intentional, as it would completely eliminate the sort of browser-like hand-cursor-over-clickable-text features so easy to do in all previous releases for more than a decade. I'm not sure why the hand cursor was accidentally removed from the current beta, but I'm confident the smart folks at RunRev will restore it before shipping. I am still catching up with recent posts on the Rev list but me thinks there was something there about this being an intentional change. If so indeed, hopefully, they will add an option to set the old hand cursor when desired. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: active plugins
So the question is: Do we need an active mode for plugins in addition to the engine-supported open and library options? If the majority opinion is to keep it we should release this beta as final soon -- please get any bug reports in if you haven't already (the item about the menu references is already on this list -- thank you Klaus). If not, we can remove it and get a last round of testing with a final release soon after. I see that there is an overwhelming agreement to remove the active plugins. I agree that pretending that such a plugin is a library is a usable workabout (but a workabout nevertheless). At least for plugins that we use for ourselves. I agree that there is no extreme need for a class of active plugins right now (nobody suggested a better label than active -- I agree it is not optimal). It might have paved a road for some new uses of plugin stacks (beyond using the plugin menu as simply a convinience launchpad for normal stacks). IMHO it gave almost the same power as Rev's more complicated plugins setup (and no overhead). But alas, simplicity rules, so be it :( Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Resize stack
Shari wrote: I just pulled this from my post for you: Opening a stack sends a whole series of messages: at least preOpenStack, preOpenCard, suspendStack, focusIn, openStack, openCard, mouseEnter, suspendStack, focusOut, resumeStack, focusIn, but even more are possible. I got this list from Message Watcher. They are a tad different in standalone. Robert Brenstein Very interesting. I wonder what would be different in a standalone. I did not see resizeStack in there. A resizeStack message may be sent if the stack being opened has a menubar and is being opened on a Mac while its editMenus property is false. -- Richard Gaskin Fourth World Media Corporation I think I was seeing resizestack without having menubar in my stack but I may be confusing things now. In IDE, things may also vary depending whether any palettes are open. And when opening invisibly, some open msgs are not sent. Anyway, you can use one of the standalone message watchers (as opposed to the one built into IDE) to see what's really going on in your stack when running in IDE or standalone. http://www.fourthworld.com/rev/ (4W UmbrellaMan) http://www.robelko.com/metacard/mw.html (Robelko Msg Watcher) Tip: in standalone, activate watching from the startup handler if you want to watch the mainstack. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Resize stack
The resizeStack handler (in the stack script) puts the new stack rect into a file for safekeeping. on resizeStack global sPrefs put the rect of this stack into line 3 of cd fld Prefs of cd 1 of stack sPrefs save stack sPrefs end resizeStack The preOpenStack handler is supposed to retrieve this info, and use it. on preOpenStack global sPrefs put the effective fileName of this stack into sPrefs set the itemDel to / put prefs.mc into the last item of sPrefs set the itemDel to comma set the rect of stack Central to \ (line 3 of cd fld Prefs of cd 1 of stack sPrefs) end preOpenStack It fails. As the stack will be a standalone, I cannot set its rect permanently on resizeStack. So it must retrieve the info from a preferences stack. After resizeStack, I verify that the Prefs fld has the new info. All is well. But somewhere when opening the stack, the old info gets put back into the Prefs file. The resizeStack is apparently called automatically from Metacard before the new info is handled. Now I can avoid using the resizeStack altogether and create a workaround, but that shouldn't be necessary. Help? Shari, I think your scheme failes because resizestack is called in the opening sequence and overwrites the saved values. I ran into this in one of my programs. If I recall, I used a global that is set after the opening ritual and the prefs file is modified only if this global says we are in normal execution mode. I posted the sequence of opening events in the thread discussing plugins not so long ago. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
tabbed buttons
I have noticed this earlier and ignored, but I have now a new stack that exhibits the same problem. So is anyone seeing this? The problem: when I click a tab, the neighboring tab (the one to the left) is hilighted and menupick executes according to the hilighted not clicked tab -- as if I clicked an inch to the point where I really clicked. If the last tab is misbehaving, I need to click in the space to the right of that tab to get it highlighted. The tabbed button in each case is in a bg group by itself and has many tabs, 11-14 tabs. This does not seem to happen for buttons that do not have so many tabs. The menupick script has only a single go to another card. It seems to happen only in stacks produced with an earlier engine and running with 2.6 engine. No problems when running same stacks with 2.5.1* or 2.5 engine. I first noticed this in a stack that has been in use for a few years. However, so far, I failed to reproduce this in a new test stack produced either in 2.5 or 2.6. Even more puzzling is that this behavior is not consistent. Mostly these tabs work 100% correct. When the problem shows, only a few tabs misbehave. More often on the right end than left. Sometimes clicking second time the same tab, highlights the correct tab. But not always. No clear pattern. No receipe. Robert Brenstein * In 2.5.1 another issue is visible: when switching cards, the card flickers as if it was displayed twice but turning buffering on eliminates this. Funny, that buffering is not needed under 2.5 or 2.6. But I don't care much about 2.5.1 since I want to move all my stacks from 2.5 to 2.6. ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: dammit
[EMAIL PROTECTED] wrote: On 08.06.2004 07:27:18 metacard-bounces wrote: ...I can't get a day's work done with the current state of the error messages coming from the v2.6 engine. ... Am I the only one who finds this a show-stopper? Have y'all worked out a solution and forgot to share? :) How does the Rev IDE cope with it? what is the problem? I was hoping to be able to provide a URL to the Bugzilla report that has all the details, but alas I can't figure out how to get my old reports there. I suppose the upside is that it may mean it's fixed, but without being able to track my reports I can't know. It took me a while but I managed to find it http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=1445 It is indeed marked as resolved. I wonder whether it is already in 2.3a3. One solution might be to make copy that one fix into the v2.2 code base and release a v2.2.1 engine to the FTP site. Would that get your vote? Would get mine :) Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Format question
I have a tricky issue where I want to run a script to remove double spaces in the script of an object but not damage any code which is actually injecting it into something. To be clear, I want the following: set the visible of image monkey to true ... to look like this: set the visible of image monkey to true ... but what i don't want to do is affect any code trying to do something with spaces. For instance: put Hellothere into fld 1 ... depending on how many times I run my code to clean the extra spaces between words this script can end up looking like this: put Hellothere into fld 1 So I guess what I'm saying is I don't want to affect spaces between quotes. Any ideas? Sincerely, Simon I'd (in pseudo-code) put empty into newscript repeat for each line in orgscript repeat until found all quote pairs find first and 2nd quote of each quote pair in the line using offset and shifting the beginchar* replace all spaces between quotes with special char that is not used end repeat put the line and cd after newscript end repeat delete last char of newscript repeat whileis in text global replace ofto in newscript end repeat replace the special char with space in nerwscript * alternative is to keep replacing each quote with another character, tracking its location whether it is the first or second quote in pair instead of fiddling with beginchar and then replace this char in the very end with quote -- this would made the scripting simpler me thinks because the offset would always be from the beginning of line Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: proposed features - not necessarily for this version
I'd like to propose some new features in the plugin manager. How about adding the ability to type in the topleft coords we would like each plugin to go to? How about a separate control to designate the topleft of the home stack? How about a control to designate whether the message box auto-opens and where its topleft should be? What about the ability to designate whether substacks of our plugins auto-open and their toplefts? Rich Mooney Payne Sparkman Mfg. Adding the opening location is possible but I am not convinced that it is so truly useful. The plugins open at their last saved positions, so you can just position them as desired and save. More useful would be IMO specifying the opening mode, so the stacks can be kept as toplevel but open as a palette or modeless as plugins. But may be adding a button to the plugin manager that saves the current location of a selected plugin could be handy, particularly in the case of plugins opened as palette or modeless. IMHO opening substacks of plugins should normally be controlled by the plugin's mainstack. If you want to open only substack but not the mainstack, you can designate the plugin as active and do opening from the pluginStack handler. RObert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: colorize script bailout
Did I hear an optimizing challenge Just kidding- many of you probably have noticed I tend to get a little over-zealous when a script gets to being optimized on-list. I'd be happy to take a crack at the colorizing script over the weekend provided nobody is anxious to do it themselves before then. Go for it :) Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: MC IDE 2.6 - next steps
I have been using Metacard heavily for the past 5 years and mostly lurking this list for around 4 years. I'm still using the 2.5 engine and have not bought a new Revolution license though I plan to eventually. Since I don't have a current license I haven't joined the yahoo group and therefore can't vote. Actually, since IDE is now a separate product, due to its open-source nature,there is nothing against your using the newest IDE with 2.5 engine as far as I know. You license only the engine. IDE is a freebie so do speak :) If I am wrong, I am sure our esteemed puhbah will correct me. I have tested the recent betas with 2.5 engine and they seem to work fine. Try it out. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
2.6b5
Well, the b5 is uploaded to Yahoo. It is different from b4 in a number of ways. I tried to test it thoroughly but those last minute improvements are always a potential hazard :) I have included a separate release notes to outline the changes more clearly for those who follow (much of this is only relevant at this stage, so no reason to add it to the docs for now). Included is also the first draft of plugin primer. I have also took a liberty to include a few sample plugins to play with. We will need to decide at some point which plugins to include in the final release (I mean in general). Now a few days break for me away from my office :) Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Open as palette
So the question for the crew here is: Is it better to have the IDE honor the stack's style or override it and open the stack in a specific mode. IMHO: Open from menu in IDE as well as open/go from script should respect the saved stack style. Other opening commands (toplevel, palette,...) should overwrite it not doubt. It would be plausible for IDE that option-open from menu enforces toplevel so one can easily open a stylized stack to get into it. Or this could be added as a new menu item. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Open as palette
Scott Rossi wrote: Recently, Richard Gaskin wrote: The style property of a stack is a persistent property, so if it's opened with the generic open command it should be fine. Question: is this something new that's been added to the latest engine, or is a part of the Rev IDE? Because I notice that stack styles are apparently not persistent with MC 2.5. I can save a stack whose style is palette, close it, and reopen it, and it displays as topLevel. Personall I would consider that a bug, but others might prefer that the IDE's File-Open open things for editing. What's the general opinion among users here? Should we change the behavior? I think the effect may be a factor of the exact way the stack is being open. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Plugins, fonts
Auto-open plugins -- plugins that are opened automatically at startup. Any MetaCard or Revolution stack can be set to be an auto-open plugin. The standard sequence of preOpen and open messages is sent when the stack opens. (new) Active plugins -- plugins that are executed automatically at startup: they are not opened but a 'pluginStack' message is sent to them. Such plugins are meant to perform one-time actions just after the MetaCard IDE loads. They open as normal stacks when selected from the Plugins menu or opened in the Plugin Manager. Can you give me an example of an active plugin that wouldn't work properly if it was an auto-open plugin? They look nearly identical... Ken Ray The forementioned setScriptEditorFont plugin is a good example. When I open it as a normal stack, it collects the info and displays a window showing the current selection and allows me to select another font/size. When I make new selection, it saves it and updates the currently open editors. When being closed, it also checks if I changed the selection but forgot to make it the new default. In other words, it functions like a normal stack using a number of standard messages. Upon startup, the stack is supposed to only set the default for the engine. Nothing else. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Plugins, fonts
Could they also be done via the auto-open type: on preOpenStack doMyOneStartupThing close this stack end preOpenStack Cheers Monte Well, Monte, and how do you know whether preOpenStack is to run the doMyOneStartupThing and close or whether to open the stack properly (see the example as I just posted in reply to Ken). I looked at the plugin model used in Rev and found it powerful but overly complicated. I agree with Richard that we should keep things as simple as possible in MC IDE. However, we should still try to make them right. I am not proposing this new type haphazzardly. I have been playing with plugins since b1 and we got as far as b4. In the meantime I have coded a number of plugins of different types and functionality (and envisioned even more). I realized that a) using libraries as non-libraries is a hack b) there is no 100% certain way to distinguish when preopenstack is executed from auto-open and from manual open. Sure, all MC programmers are advanced and we can code hacks in our stacks that do things the way we want them. However, plugin stacks are likely to be shared among other developers, so should be coded more like products. And the framework of the plugin technology we set in place now is not only for today. Note that there no penalty whatsoever to having the new type. It does not complicate things for using plugin manager either (except for having an extra checkbox in the window). One will use it only when needed. Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Robert Brenstein wrote: But as far as I am concerned it is a kludge and a kludge that anyone writing such plugins must always remember to follow. If I open Plugin Manager and see something marked as a library, it should be a library. May be I am a purist, but since plugins are new to MC, it would be a shame to start with a kludge that is not necessary. Using Transcript is a kludge? I would imagine the audience for such a specific feature would be rather small, possibly more than one but unlikely to be many more given how few people use MC. Why not just encourage ever more effective use of the language, so that the developer can have any behavior she wants wants, get a much larger audience for her effort, and the other 99% of Transcripters have the opportunity to benefit from it? These are MetaCard folks here. Mostly professional developers, they seem accustomed to scripting a line or two as needed. :) Come on, Richard. The issue is not in using Transcript or our ability to code. Why did you add the library as plugin type? One could use auto-open with a preOpenStack handler which checks whether it is among the stacksInUse and start using it, then exit. I am now proposing to recognize yet another type which is somewhat similar to library but with different execution characteristics. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
I was hoping to post the B5 build you sent, but it crashes my Stuffit Expander: I double-checked my Stuffit installation by downloading a fresh copy of B4, which decompressed without error. While I haven't had issues with other attachments I can't rule out a Mozilla email issue (I'm testing last night's build of Mozilla 1.7b). This was actually a zip archive produced by DropStuff. My Stuffit Expander unzips it without problems. But I vaguely recall some zip issues on OSX. I was going to ask you to resend but it seemed simpler to just add you to the moderator list so I did. You can post b5 directly. You may want to double-check the Stuffit file before posting to make sure the issue I encountered was just a Mozilla issue. Also, a housekeeping favor if you don't mind: when I post a new build into the Latest Test Version folder I move the last one into Archives/Non-Release Builds/. There's a handy Cut and Paste feature for moving files easily. Okay, I can post it myself. But I need to update the documentation first. While I see no harm in the new IDE message you've added, in the future please post feature requests to the list for discussion before posting a build that contains them. Staying away from IDE messages flying around is one of the reasons we use the MC IDE, and while I'm confident your dilligent style will avoid the pitfalls of other designs, some folks here have strong opinions about such matters and I feel their arguments have merit. The new message will be sent explicitely to a specific stack, only once when starting, and only when the stack was marked accordingly. So there is no danger of messages flying around. Yes, the matter of plugins should have been discussed more on the list. I gather they are very few people truly interested in this, though. B1 through B4 were just minor incremental improvements. The B5 changes a number of things, and thus I brought this up on the list. Above all else this is a community project. The crew here chose the X11 license specifically because it has the fewest hindrances of any GPL-compatible license. Among other things this means there's nothing stopping anyone interested in more adventurous exploration from making their own forked project from any version of the MC IDE from v2.5.1 forward. As Scott Raney says, Let a thousand flowers bloom. But this specific implementation has a narrow mandate from the community: make the fewest changes necessary. Well, yes, I could produce my own version of IDE but I am not sure whether does would be truly beneficial to the MC community. I have may be more vested interested in MC as it is and will for quite a while still be my primary production tool. Please review the credit for your contributions that I added in B4 and let me know if you feel it's appropriate (Help-Licensing, Version History tab). Also, please consider updating the Read Me to include a descriptions of this new active plugin feature. Will do. And as discussed here a couple weeks ago in response to the leftover script editor windows, please send the message mcStripAndShip to the mctools mainstack before posting; that strips any leftover script editors and saves the IDE. Ok. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Okay, I promise this to be the last post from me today. I have already used more bandwidth than normal :) I split my reply to Richard's long email to cover different aspects more clearly. For Rev compatibility it's useful to support the auto-open option, and with preOpenStack as a hook the world is the scripter's oyster. But beyond the most basic compatibility with the majority of Transcripters I'm much less excited about plugin features. Actually, if we are talking about Rev compatibility, we should support all its open options, including quit, as well different open modes (modeless, invisible, etc). I think this can be added without much effort. Admittedly though, all Rev plugins I have seen are passive or simple auto-open types. In case of MC, I can envision a number of plugins that expand or supplement its spartan interface. Most of the handful of people who still use the MC IDE have businesses based around it. They're mostly building applications, not IDE components. The relative few who do make publicly-distributed plugins usually make them for Rev, or at least Rev-compatible. I have indeed been using MC for many years and built a business around it so do speak. However, even for my own usage, I see plugins as a big boost, actually extending into my products (and yes, active plugins play a critical role there :). Personally I wouldn't write components for use by other developers that weren't compatible with the current shipping product, and the stuff I write for internal use hasn't been slowed down by anything absent from an IDE. True for commercial or shareware plugins. Not so true for utilities. Even some of us MC diehards may need to dig into modifying home and mctools less and start using plugins instead. Many of the MC developers I know have been using one form of Plugins folder or another for years, far less feature-rich and with narry a complaint But until now there was no way to share any such extensions to IDE. Most are probably hard coded in Home stack. Plugins allow us to share. We will see what happens. Furthermore, I postulate that the order of events at startup should be to 1. build plugins menu 2. start using all library plugins 3. execute all active plugins 4. open plugins to be opened at startup Holding shift key down, should disable 2, 3, and 4. That the order of things in B4 (with the exception of #3, as active plugins hadn't been discussed here at the time). Actually, that was not the order of things in b4. #2 and #4 were executed for each stack alphabetically. It means that if my aXXX auto-open stack needed y library to function, I had to rename it to Za. Also, in b4, shift key disables not only execution but also building the plugin menu. I think that plugins should be always openable in passive mode (that is from menu). Another important change that I made for b5 is that the plugin menu is build only at startup and when plugin manager opens (and when the folder is changed, of course). The execution is done only at startup. In beta b4, any action involving plugin manager, opening it or even changing the display mode of the list, resulted in menu being rebuilt and all stacks opening/executing again. Yes, another change I did is to place all the plugin code inside the plugin manager stack (in b4 most is in the backscript from mctools), so plugin technology is more self-contained rather than spread between mctools and plugin manager stacks. The extra stuff sounds okay to me, as long as it doesn't break Rev compatibility and I don't have to write it. I'll be the first to admit that it's hard to get me motivated to spend much time on nuances that will be used by so few people. Well, I have already coded all this for others to try. I will post a new beta over the weekend. Then anyone can try it out and see whether it is an improvement or anything should be rolled back or improved further. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Sorry for breaking my promise to keep quiet, but either I presented my case badly or you are misreading my words, Richard. For Rev compatibility it's useful to support the auto-open option, and with preOpenStack as a hook the world is the scripter's oyster. But beyond the most basic compatibility with the majority of Transcripters I'm much less excited about plugin features. Actually, if we are talking about Rev compatibility, we should support all its open options, including quit, as well different open modes (modeless, invisible, etc). I think this can be added without much effort. If you look at little deeper I don't think you want to employ full Rev compatibility: those extra messages bouncing around are anethema to the MC experience, and the inconsistency of their behavior annoys even die-hard Rev fans. I did not say anything about FULL compatibility but about OPEN options. This meant to exclude support for the custom messages. As for modeless, invisible, etc.: those were discussed here, and the general preferences was to just use the built-in properties for those things rather than Rev's custom properties which redundantly mirror the built-in ones. I agree that using built-in properties would really suffice. However, Rev plugins may rely on the setting in the plugin manager since RunRev decided otherwise. The issue is whether we care. Coding to support this and actual execution are insignificant. The only issue is degree of compatibility with Rev. It is also possible to recognize these options as set by Rev but not support for MC stacks. Once upon a time this was all so simple: folks wanted a menu to provide convenient access to extra utilities, and decided it would be useful to also have the option of having some of those automatically opened if they choose. At that point, everything else possible with the engine is available or a plugin's behavior. Well, you know the saying about the finger and the hand. If Plugins menu is used only as a simple launchpad to open stacks, the plugin concept stops short to fullfill its promise IMHO. If we make the next step, we need to recognize that some stacks may have dual functionality when used as plugins. Why it needs to be any more complicated than that continues to elude my simple mind. Well, all this complicated stuff comes into play ONLY when you explicitely ask for it. If you don't, you have your simple world. Admittedly though, all Rev plugins I have seen are passive or simple auto-open types. In case of MC, I can envision a number of plugins that expand or supplement its spartan interface. Such distinctions are arbitrary. Plugins are just stack files, and using preOpenStack as a hook there is nothing the engine allows that can't be done by a plugin. Of course, such distinctions are arbitrary. They just help to keep things apart. Why do we talk about toplevel, modal, modeless etc stacks? They are all still stacks. Rather than two or four types or modes or whatever we call them, I see an infinite variety of possibilities. Apple and oranges. Those four modes define simply their handling by plugin manager. What the plugins do is up to programmers. But I don't see it as the IDE's responsibility to provide point-and-click affordances for all of them. One hook opens the world for a plugin. I don't understand what you mean. The number of lines written to justify automatic accomodation of the script font settings plugin easily exceeds the number of lines needed to simply make it do whatever it needs in a simpler Plugins Manager. Please explain. If I have 5 plugins that are active I need to repeat the same kludge code in each of them. In the plugin manager, it is a few extra lines which work same for any number of such plugins. If there are no such plugins, plugin manager just ignores this code. BTW, it took me longer to debug this kludge code than write and debug those few lines in Plugin manager. Personally I wouldn't write components for use by other developers that weren't compatible with the current shipping product, and the stuff I write for internal use hasn't been slowed down by anything absent from an IDE. True for commercial or shareware plugins. Not so true for utilities. Even some of us MC diehards may need to dig into modifying home and mctools less and start using plugins instead. Why, now that there's a plugins menu with auto-open capabilities? That is what I said, didn't I? And how is it that such a person would be inclined to dive into direct modification of the IDE but be unable/unwilling to write a two-line initialization plugin to coordinate any specialized needs they might have? That is what I said, too, didn't I? Many of the MC developers I know have been using one form of Plugins folder or another for years, far less feature-rich and with narry a complaint But until now there was no way to share any such extensions to IDE. Most are probably hard coded in Home
Re: Plugins, fonts
Robert Brenstein wrote: Why did you add the library as plugin type? Because two people presented an argument that there may be times when a stack should only be libraried at startup but not when opening the stack. Moreoever, most good libraries are designed to be initialized with start using called from an app, and have no auto-initialization of their own. But this is exactly the same argument for the active plugin type. Is the fact that I am the only one advocating it the issue? Or is it that I am the only one who sees the utility of it? But what I do is completely irrelevant here. This project is a community effort, so when a feature is proposed and the majority vote in favor of it, someone must write even if some will never use it. I don't see other open source projects run really so democratically but I have actively participated only in a couple :) There was a brief but interesting thread on these issues on HyperCard list just recently. Anyway, I think by now I have outlined and argued all changes I envisioned for the next beta. A few people suggested to continue with the workabout solutions using either auto-open or library routes instead of supporting active plugins explicitely. Only Richard discussed the operation of Plugin Manager self. The majority has been quite silent. So, should I bother to post what I suggested as b5? Or should we continue with b4? If everyone is happy with the way b4 works, I will shut up and just make my own version as Richard suggested :) Robert Brenstein ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Plugins, fonts
Signe Marie Sanne wrote: Good morning On both Mac Classic and Windows XP using engine 2.6 and IDE 2.6.b4: When I open the script editor, see its small indistinct font and want to change it, I select Brensteins SetScriptEditorFont under Plugins and head for the font. However, the pointer tool does not change when over the plugin stack. Would it be possible to make it change automatically to browse tool? If the stack's style property is set to modeless or palette it will behave as though always in browse mode. Okay, the SetScriptEditorFont plugin now opens as modeless by default. It also forces the font change onto the currently open script editor windows. However, I can't release this version until MC IDE b5 is out because the plugin works now in a mode not supported by b4. And when talking about fonts, on Windows XP all instructions in the Home stack (for instance: File, Edit, Tools etc.) show in a very small and ugly font (1024x756), actually, it is not much better in the Rev environment either. But would it be possible to make it more distinct, use another font or preferably use a bigger size? I guess we should think about SetDefaultIDEfont plugin :) Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: commandKeyDown
This will cause problems with any menu in your own stack that uses Cmd-1 through 4. I propose removing those but keeping the optionKey section for script access: Are more people relying on maintenance of this behavior than are adversely affected by it? -- Richard Gaskin Actually, I do rely on cmd-number to navigate stacks in development mode. In this mode, MC shows its default menubar not the one from our programs, so no conflict is possible. Therefore, I believe a better approach would be to check the defaultmenubar setting and execute cmd-number when it is the default and pass commandKeyDown otherwise. Robert ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
