Re: Compressing stacks - is it possible?
on 02.21.02 08:11PM, Scott Rossi wrote: > FWIW, one thing I've done is to compress sounds, import the compressed data > into a custom property in a stack, and later write the sounds to the drive > and decompress them for playback. I assume the same will work fine with > stacks. Are you saying I can script set the MyCustomProperty of stack "mystack" to stack "stackToCompress" ? I just get "source is not a container". I see that I could write the stack to disk, then read it as a binfile, compress it, then write the compressed data out again. To reconstitute it, I guess I'd have to read the compressed file as a data, decompress it as a data, write it out as data again, then open the file as a stack. I was hoping there would be a way to get MetaCard to treat a stack in memory (not a file) as a lump of data to compress. I have about 1000 small stacks to put on a CD. I guess it won't kill me to have the stack-indexer-and-writer-outer script read-write-read-write each stack to get them onto the CD when I prepare it for distribution, but I don't like having to read-write-read stacks to open them for the end user. So, no one knows a way to coerce MetaCard to treat a stack in memory as text? ever hopeful, tereza + Tereza Snyder + Senior Software Developer + Attainment Company, Inc. + + 800.327.4269 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Polling the mouse
On Thu, 21 Feb 2002 Curry <[EMAIL PROTECTED]> wrote: > > Scott Raney wrote: > > > Yes. The full list of functions to avoid because they are deprecated is: > > the mouse > > the mouseClick > > the mouseH > > the mouseV > > the mouseLoc > > the optionKey > > the commandKey > > the controlKey > > > > And the very worst thing to do with any of these is "repeat until > > ", which will condemn you to the fires of eternal damnation > > in multiuser hell ;-) I noticed you CCed the MetaCard list, which is a good thing, I guess, though they're getting dumped into the middle of the discussion. Here's the key part of my previous message, just to bring them up to speed: The long answer, and probably much more than you want to know, is that "the mouseClick" is really the problem here, not "the mouse". "the mouse" could in theory be done asynchronously. If this were changed you'd still have the performance issue to deal with (i.e., "repeat until" would never be as smooth as using mouseMove messages and would eventually cause the OS to start penalizing your app), but reliability wouldn't because this information can be queried directly from the OS on all platforms. You'd also be subject to the normal behavior of async functions (e.g., in HC, "the mouse" returns "down" if the user clicked down anytime between when the handler started running and when the function is called, whereas an async implementation would only return "down" if it was actually down when you made the call). The problem with "the mouseClick" is that of state management and event order: it has to wait for the mouse to go down and then back up. Worse, at least for HC compatibility, is that if you do something in a script that takes a few seconds and click twice in that interval, "the mouseClick" will return true *twice*. This means that it's necessary to maintain a queue of these mouse events and check the whole queue each time the function is called to see if there is both a mouseDown and a mouseUp message in it, and pull them out as a pair if so. And of course you can't just leave the rest of the events in the queue either, because some of them (like socket events and redraws) need to be handled independently of what the currently running handler is doing. Doing this cross-platform is horrendously complicated, and results in compromized reliability for *everything*, not just the mouseClick function. Which is why we want to (and plan to) remove this functionality, or at least substantially modify it to remove this queueing aspect (e.g., the mouseClick would return true only if you clicked down and up any time between the start of the handler and when you made the call, and once it returned true *all* state information would be tossed out so it wouldn't return true again until the user clicked again after the function returned true, even if they clicked multiple times before the first call). It'd also be good to discuss the topic of sync/async polling on the HC and SC mailing lists to get a sense of how aware people are of this issue (I just responded to one poster on the use-revolution list who wasn't aware of this behavior of the mouse function, though lord knows we got enough bug reports about this back when MetaCard did a simple async report). > Scott, I understand the problems of the OS penalty due to hogging the > computer with polling of mouse functions during a repeat, but there are > different kinds of software; in some cases, we may want to make software > that is supposed to be the only main application running on a computer, for > example, a game, a presentation, or an educational application with a lot of > animation. > > Often, the documentation may even advise users of these types of programs to > not run other applications unnecessarily at the same time for better > performance. With these types of applications, often you would be > ill-advised to run other major software at the same time anyway, not just > because of its effect on the other software, but also because of other > software's effect on it. Understood, and that's why we added the keysDown function, which is a much better way to do this kind of thing than using keyDown messages and the optionKey/commandKey/shiftKey functions. I guess all that remains is a async mouse polling function, but we never considered this necessary because using message is always possible (and always preferred) in this case. > For example, in one game project, I started off with the mouseMove message, > and then had to switch to send..in plus the mouseLoc (once per handler), > because mouseMove was not nearly responsive enough. (The object was always > moving toward the mouse, but at its own speed, not directly tied to the > mouse.) This was much more responsive. I can't see why this would be the case unless you're running on a very slow system, moving very large objects or a large number of objects, or maybe doi
Re: Compressing stacks - is it possible?
Recently, Tereza Snyder wrote: > Is it possible to compress a stack, save it to disk, then later read it, > decompress it and presto! have a stack again? FWIW, one thing I've done is to compress sounds, import the compressed data into a custom property in a stack, and later write the sounds to the drive and decompress them for playback. I assume the same will work fine with stacks. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Compressing stacks - is it possible?
What I've done with the educational gradebook program I'm working on is to use MetaCard stacks as 'templates'. I've written scripts which pull all user data out when they quit and write it to a compressed text file. When the user returns to work I decompress the text file and load it back into a duplicate of the template. - Original Message - From: "Tereza Snyder" <[EMAIL PROTECTED]> To: "MetaCard" <[EMAIL PROTECTED]> Sent: Thursday, February 21, 2002 8:47 PM Subject: Compressing stacks - is it possible? > Hi all, > > Is it possible to compress a stack, save it to disk, then later read it, > decompress it and presto! have a stack again? > > I don't think so, but maybe? > > tereza > > > > > + Tereza Snyder > + Senior Software Developer > + Attainment Company, Inc. > + > + 800.327.4269 > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Compressing stacks - is it possible?
Hi all, Is it possible to compress a stack, save it to disk, then later read it, decompress it and presto! have a stack again? I don't think so, but maybe? tereza + Tereza Snyder + Senior Software Developer + Attainment Company, Inc. + + 800.327.4269 ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Polling the mouse
Scott Raney wrote: > Yes. The full list of functions to avoid because they are deprecated is: > the mouse > the mouseClick > the mouseH > the mouseV > the mouseLoc > the optionKey > the commandKey > the controlKey > > And the very worst thing to do with any of these is "repeat until > ", which will condemn you to the fires of eternal damnation > in multiuser hell ;-) Scott, I understand the problems of the OS penalty due to hogging the computer with polling of mouse functions during a repeat, but there are different kinds of software; in some cases, we may want to make software that is supposed to be the only main application running on a computer, for example, a game, a presentation, or an educational application with a lot of animation. Often, the documentation may even advise users of these types of programs to not run other applications unnecessarily at the same time for better performance. With these types of applications, often you would be ill-advised to run other major software at the same time anyway, not just because of its effect on the other software, but also because of other software's effect on it. For example, in one game project, I started off with the mouseMove message, and then had to switch to send..in plus the mouseLoc (once per handler), because mouseMove was not nearly responsive enough. (The object was always moving toward the mouse, but at its own speed, not directly tied to the mouse.) This was much more responsive. There are comparable situations with the other functions. I have no problem with the mouseClick going out. It's an obvious case. But I think it would be terrible to remove the others functions which were mentioned. As Scott said, it's using them with repeats that causes the problems. So, first, can we be assured that these functions will still remain, at least asynchronously, in the future? Otherwise, if the corresponding messages don't work well enough for a certain task, we will be in a jam someday. Secondly, using these functions synchronously allows much more convenient scripting for testing, personal projects, students (as someone mentioned), etc. Why not keep the functions synchronous, with the exception of mouseClick which could be turned asynchronous or simply trashed, and leave the responsibility of using them correctly up to the scripter? If a function is only called once per handler, it still won't hurt the system if called synchronously. For those making utilities and well-behaved games or educational apps that aren't full-screen or intensive, that would allow them to have a way to check once or twice within a handler and be assured of an accurate result. For those making full-screen or intensive apps, or testing or making projects for personal use, they could choose to poll these functions and take the consequences. If used wrongly, like anything else if life, they could cause problems, but that's what life is all about--using things the right way according to the situation. Any professional developer would avoid them where necessary. I think that avoiding these functions shouldn't have to be forced on all users in all situations just because it would be unwise some users in some situations. Ever since switching to Revolution, I've marvelled at how it is really such "an easier way to do that". I love everything about it. But I hope you will listen to all the users about this type of feature, since all of us are paying the subscription price, not just those who will definitely not miss these features because of the type of projects they do. Since it isn't absolutely necessary to remove all the features (the mouseClick is the main problem) and it isn't absolutely necessary to make the functions asynchronous as long as the scripter can be trusted to use them correctly according to the situation, I suggest that these changes not be forced on everyone. People really *can* choose to do the right thing. And any professional developers, or users in the appropriate situations, *will*. So on behalf of all those who want to make scripting choices, please keep the old power in there--we only need an FAQ, not a nanny! There's no reason to take away useful scripting features everyone writing scripts as a student, for personal use or testing, or making special types of software just because it can hurt someone else if used incorrectly. We all must be responsible for ourselves. If someone hogs the wrong CPU and it penalizes them, they may not care if they are working on a personal project for their own use. If not, they will fix it. That's my two cents--maybe it's three cents. I think this is a pretty important issue. It's not just about sentimentality--although those functions, used with and without repeat--are a very important part of scripting up to now in history. Going forward is good, but cutting out old ways altogether is not always good. It's easy for one group of people to decide that we must be resolute and the old way should be discarded, but som
Re: Unique Macintosh Identification
Great idea... now any idea on if there's an XCMD out there (or equivalent) to get the MAC address? Ken RaySons of Thunder SoftwareEmail: [EMAIL PROTECTED]Web Site: http://www.sonsothunder.com/ - Original Message - From: MisterX To: [EMAIL PROTECTED] Sent: Thursday, February 21, 2002 12:07 PM Subject: RE: Unique Macintosh Identification just get the Mac Address of the network card. It's unique for each hardware - model/manuf. regardless! You could also generate a time base code coupled with that just to make sure it's never duplicate. I've heard of some duplicate ids in Mac addresses but it's one in a zillion. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ken RaySent: Thursday, February 21, 2002 18:31To: [EMAIL PROTECTED]Subject: Unique Macintosh Identification THis is slightly off-topic, but does anyone know how to uniquely identify a Mac? We're trying to set up a specific install that works on a set number of machines by getting a unique ID for the machine and using it to verify that the machine is "licensed". This doesn't have to specifically be through MetaCard (it could be AppleScript, XCMD, gestalt selector, etc.). Thanks! Ken RaySons of Thunder SoftwareEmail: [EMAIL PROTECTED]Web Site: http://www.sonsothunder.com/
RE: Unique Macintosh Identification
For macOSX get shell(ipcfg /something) should work... but I dont own one so i can't tell you... the output should contain the mac address should. Otherwise... different challenge for the puzzled-minded: Get the registered user's name, mix (encrypt) the characters interposing the date string (zip, adress...) within the name, do some bit rotations and xoring and you'll have a for sure random code... if you know the order of the operations, you can unmixit... Two john smiths can't have the same input date ever... ;) (aka build your own pgp anytime!) cu Xa > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Gaskin > Sent: Thursday, February 21, 2002 19:25 > To: [EMAIL PROTECTED] > Subject: Re: Unique Macintosh Identification > > > MisterX wrote: > > > just get the Mac Address of the network card. It's unique for > each hardware - > > model/manuf. regardless! > > You could also generate a time base code coupled with that just > to make sure > > it's never duplicate. I've heard of some duplicate ids in Mac > addresses but > > it's one in a zillion. > > > > How does one obtain the Mac address of the network card from MetaTalk? > > -- > Richard Gaskin > Fourth World Media Corporation > Custom Software and Web Development for All Major Platforms > Developer of WebMerge 1.9: Publish any Database on Any Site > ___ > [EMAIL PROTECTED] http://www.FourthWorld.com > Tel: 323-225-3717 AIM: FourthWorldInc > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Unique Macintosh Identification
im sure there is a one toolbox call for that. duh scratch... loading hypermodules memory banks (were in the attic) go to matthias kahler external's excellent site. -- Rinaldi? im not sure... -- CompileIt-able? for sure... you need Hypercard for that though... Anyone tried CompileIt on MetaCard on MacOS? ;)) -- alternatively there must be an osax (as in applescript extension). -- hope that helps. Sorry, but im doing mostly nt bitching all day at the gui today... > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Gaskin > Sent: Thursday, February 21, 2002 19:25 > To: [EMAIL PROTECTED] > Subject: Re: Unique Macintosh Identification > > > MisterX wrote: > > > just get the Mac Address of the network card. It's unique for > each hardware - > > model/manuf. regardless! > > You could also generate a time base code coupled with that just > to make sure > > it's never duplicate. I've heard of some duplicate ids in Mac > addresses but > > it's one in a zillion. > > > > How does one obtain the Mac address of the network card from MetaTalk? > > -- > Richard Gaskin > Fourth World Media Corporation > Custom Software and Web Development for All Major Platforms > Developer of WebMerge 1.9: Publish any Database on Any Site > ___ > [EMAIL PROTECTED] http://www.FourthWorld.com > Tel: 323-225-3717 AIM: FourthWorldInc > > ___ > metacard mailing list > [EMAIL PROTECTED] > http://lists.runrev.com/mailman/listinfo/metacard > ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Unique Macintosh Identification
MisterX wrote: > just get the Mac Address of the network card. It's unique for each hardware - > model/manuf. regardless! > You could also generate a time base code coupled with that just to make sure > it's never duplicate. I've heard of some duplicate ids in Mac addresses but > it's one in a zillion. > How does one obtain the Mac address of the network card from MetaTalk? -- Richard Gaskin Fourth World Media Corporation Custom Software and Web Development for All Major Platforms Developer of WebMerge 1.9: Publish any Database on Any Site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
OS X and tool selection
My brain is hard-wired to use Cmd-tab to switch tools. In Mac OS 9 I had changed the application switcher long ago to another keyboard combination so I could continue to use Cmd-tab in HC and MC. In OS X I can't find a way to change the application switching combination. How have others worked around this? I wouldn't mind turning app switching off entirely, if that's what it takes. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
RE: Unique Macintosh Identification
just get the Mac Address of the network card. It's unique for each hardware - model/manuf. regardless! You could also generate a time base code coupled with that just to make sure it's never duplicate. I've heard of some duplicate ids in Mac addresses but it's one in a zillion. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ken RaySent: Thursday, February 21, 2002 18:31To: [EMAIL PROTECTED]Subject: Unique Macintosh Identification THis is slightly off-topic, but does anyone know how to uniquely identify a Mac? We're trying to set up a specific install that works on a set number of machines by getting a unique ID for the machine and using it to verify that the machine is "licensed". This doesn't have to specifically be through MetaCard (it could be AppleScript, XCMD, gestalt selector, etc.). Thanks! Ken RaySons of Thunder SoftwareEmail: [EMAIL PROTECTED]Web Site: http://www.sonsothunder.com/
Unique Macintosh Identification
THis is slightly off-topic, but does anyone know how to uniquely identify a Mac? We're trying to set up a specific install that works on a set number of machines by getting a unique ID for the machine and using it to verify that the machine is "licensed". This doesn't have to specifically be through MetaCard (it could be AppleScript, XCMD, gestalt selector, etc.). Thanks! Ken RaySons of Thunder SoftwareEmail: [EMAIL PROTECTED]Web Site: http://www.sonsothunder.com/
