Polling the mouse
Title: Polling the mouse Jim Hurley wrote: > I regularly use "repeat until the mouseClick" without the same > problems I experience with the mouse function. My question is: Does > the advice to stay away from polling the mouse extend to the > mouseClick function as well? Scott has warned that the mouse() > function may/will be discontinued. How about mouseClick()? Is it also > in jeopardy? Scott Rainey 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 ;-) The last 3 can be safely acquired with "the keysDown", but be careful to not sit in a repeat loop calling that or you may hang your app or at the very least have the gods of multiuser development strike you down. And while we're on the subject of bad technique that will cause you grief at some point, also avoid using the following messages: mouseStillDown mouseWithin idle That's it. Not a long list, and in all cases it's very easy (I would even in most cases say trivial) to do it the right way. A small price to pay for shrugging off the last of the circa 1984 single-user single-tasking design of MacOS and HyperCard. Regards, Scott After 35 years as a professor of physics, it has been my experience that trivial is in the mind of the beholder. Scott is quite right is pressing *developers* not to anger the "gods of multi-user development." But there is also another class of user, one to which Run Rev is trying to appeal, and that is the *student* who is using HyperTalk as a computer language--perhaps as young as eighth grade. And this user would be programming in the development environment and would be unconcerned with tying up the CPU. For some time I have been using HC, MC and/or RR to build Turtle Graphics into HyperTalk and allow grade school students to use the package to program their own solutions to problems in mathematics and physics. There are two areas in this work in which HyperCard is quite superior to MC or RR. (And there are many others, of course, in which MC and RR are infinitely superior to HC.) The most serious problem is the glacial speed with which MC draws images (in many cases this problem is lethal) and the second, and much less important, is the problems students have in polling the mouse. There appears to be no remedy in the offing to the speed problem. However, regarding mouse-polling, my earlier question dealt with the reliability and continued viability of the mouseClick function. As an example, students create a button which, when clicked, sends a satellite on its way into orbit around the earth--leaving a line in its wake to show the trajectory. (The student has programmed the turtle to obey the laws of Newtonian gravity.) When the student is satisfied with the length of the trajectory, he or she clicks again (anywhere on the screen) to stop the process. This is accomplished with a "repeat until the mouseClick" or "if the mouseClick then exit repeat." So my question is three-fold: 1. Is this a reliable operation given the current state of the MC engine? That is, is there a bug similar to that in "repeat until the mouse is down?" 2. We know that we may lose the mouse() function in the future. Is mouseClick vulnerable as well? 3. If mouseClick will not be an option, what is the work-around so that the student may click anywhere on the screen to exit a repeat loop, and hopefully one which is simple enough for an eighth grader to discover? (Since the student clicked the button to start the process, it is more natural to click again to stop the process. It would be awkward to have to move to the keyboard.) Jim Hurley -- Jim Hurley
Polling the mouse
Not since Mickey has there been such genuine affection for a mouse, such concern for his well being, whether he is up or down, or just moving about. It seems we do not appreciate the simple things in life until they are threatened. By the way, I just heard a rumor that in the next release, MC/RR will no longer recognize the keyboard. All communication will be through miss Cleo. -- Jim Hurley ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Polling the mouse
What will be the consequence of polling the mouse in Revolution. repeat until the mouse is up set the loc of btn "dragBtn" to the mouseLoc end repeat Certain people discourage use of this in MetaCard and Revolution? Thanking you, Lince M Lawrence FOCAL IMAGE (INDIA) PVT. LTD. [ mailto:[EMAIL PROTECTED] ] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Polling the mouse state
> >Message: 7 >Date: Tue, 19 Feb 2002 11:46:23 +0100 >Subject: Re: Boxes, Grids, & Snap to Objects >From: Klaus Major <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] > >Hi Ian, > >> I don't like the grab command, it seems to me program flow doesn't >> stop, >> i.e. >> >> Grab me >> Beep >> >> Will beep immediately even though you're still dragging the thing >> around the >> screen. This means you'll need to use a mouseup handler to do the new >> location stuff instead. >> >> I find it much better to hide the cursor, and set loc of the object >> needing >> dragging to the mouseloc, this is done in a "repeat while the mouse is >> down" loop and lets me do clever things, I can check if the mouseloc is >> within the bounds of another object, and if so hilite that object, etc. >> It's much more flexible. >> ... > >maybe you missed some of the previous posts, where experts (!) are >advising to >not poll the mouse-state. > >It is far more efficient to use the mousemove function. This issue of polling the mouse state continues to crop up. I have had to avoid the use of the old HyperCard standby: "repeat while the mouse is down" not so much because I worry about burdening the CPU but more importantly because there is a bug in the MC engine which causes it to fail quite regularly. (Very often the MC engine fails to recognize when the mouse the mouse state changes to up.) And Scott says that fixing this bug is not high on the priority list. I regularly use "repeat until the mouseClick" without the same problems I experience with the mouse function. My question is: Does the advice to stay away from polling the mouse extend to the mouseClick function as well? Scott has warned that the mouse() function may/will be discontinued. How about mouseClick()? Is it also in jeopardy? -- Jim Hurley ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
I must voice my opinion: The "gods" of programming may say it is a bad practice to program in a certain way, using certain functions under certain circumstances. This may be true. *BUT* There also may be legitimate uses for the "bad practices" for which there may be no alternative. I would rather see the functions remain viable for use at THE DEVELOPERS DISCRETION. Otherwise, it is kind of like saying everyone HAS TO USE Microsoft products. oops! I forgot... That one *IS* already being enforced. That's my 2 cents worth... Let the games (or flames) begin. ~Roger Eller <[EMAIL PROTECTED]> > Scott Rainey 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 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Hi Roger, > I must voice my opinion: > > The "gods" of programming may say it is a bad practice to program in a > certain way, using certain functions under certain circumstances. > This may be true. *BUT* > There also may be legitimate uses for the "bad practices" for which > there > may be no alternative. > I would rather see the functions remain viable for use at THE DEVELOPERS > DISCRETION. > Otherwise, it is kind of like saying everyone HAS TO USE Microsoft > products. > oops! I forgot... That one *IS* already being enforced. > That's my 2 cents worth... Let the games (or flames) begin. > > ~Roger Eller <[EMAIL PROTECTED]> > >> Scott Rainey 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 this is an advice and not a dogma ;-) C'mon, don't we all consciously and happily kill several million brain-cells from time to time, somehow ? (That was a metaphore :-) Regards from germany Klaus Major [EMAIL PROTECTED] ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
On Thu, 21 Feb 2002 Jim Hurley <[EMAIL PROTECTED]> 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 ;-) > > > >The last 3 can be safely acquired with "the keysDown", but be careful > >to not sit in a repeat loop calling that or you may hang your app or > >at the very least have the gods of multiuser development strike you > >down. One more note on this: as of engine version 2.4.2, the last three are also now done asynchronously and so won't be a problem anymore. And they've always been safe to use a single time in a "mouseDown" or "mouseUp" handler. It's getting them in a repeat loop that will potentially cause problems. (snip) > For some time I have been using HC, MC and/or RR to build Turtle > Graphics into HyperTalk and allow grade school students to use the > package to program their own solutions to problems in mathematics and > physics. There are two areas in this work in which HyperCard is quite > superior to MC or RR. (And there are many others, of course, in which > MC and RR are infinitely superior to HC.) The most serious problem is > the glacial speed with which MC draws images (in many cases this > problem is lethal) and the second, and much less important, is the > problems students have in polling the mouse. > > There appears to be no remedy in the offing to the speed problem. Actually the current release is pretty close to HC in performance, the primary remaining difference being due to running in color vs black and white (anywhere from 8 to 32 times as much data to move around, you know). > However, regarding mouse-polling, my earlier question dealt with the > reliability and continued viability of the mouseClick function. > > As an example, students create a button which, when clicked, sends a > satellite on its way into orbit around the earth--leaving a line in > its wake to show the trajectory. (The student has programmed the > turtle to obey the laws of Newtonian gravity.) When the student is > satisfied with the length of the trajectory, he or she clicks again > (anywhere on the screen) to stop the process. This is accomplished > with a "repeat until the mouseClick" or "if the mouseClick then exit > repeat." > > So my question is three-fold: > > 1. Is this a reliable operation given the current state of the MC > engine? That is, is there a bug similar to that in "repeat until the > mouse is down?" > 2. We know that we may lose the mouse() function in the future. Is > mouseClick vulnerable as well? > 3. If mouseClick will not be an option, what is the work-around so > that the student may click anywhere on the screen to exit a repeat > loop, and hopefully one which is simple enough for an eighth grader > to discover? (Since the student clicked the button to start the > process, it is more natural to click again to stop the process. It > would be awkward to have to move to the keyboard.) The short answer to your question is, don't use a repeat loop, use "send .. in" to draw the segments instead, and cancel the message if you get a mouseDown. 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
Re: Polling the mouse
> The short answer to your question is, don't use a repeat loop, use > "send .. in" to draw the segments instead, and cancel the message if > you get a mouseDown. > > 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). This is the best explanation yet, and I've saved it to explain to clients why so much of their code needs to be rewritten when moving stuff from another xTalk. They hate paying for it, but attempting to check the mouse during a repeat loop is not reliable in MC, even though it works well in other xTalks, and I try to tell them it's just a small tradeoff for gaining the other 97.5% of the market (is the Mac really down to 2.5% as MediaMetric reported two weeks ago?). However, something that would be even more useful than this explanation are a couple of good examples in the docs of how one would approach converting such a handler. The mental flip-flops needed to do this took me a fair amount of trial and error to get down, and the time lost is something either a client pays for or I absorb here, but regardless who's writing the check it still feels like a loss when the same handler worked perfectly before conversion. Given the background you provided I support the move, but anything that could be done to reduce conversion costs would be very helpful. As it is, with complex projects it's sometimes easier to write something over from scratch than pick your way through differences in syntax and object model. There are many benefits to a complete rewrite (and with OS X and XP, most projects need a UI overhaul anyway), but it's a hard sell for new clients who don't understand how something can be "compatible" and "incompatible" at the same time. :) -- 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 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Thu, 21 Feb 2002 12:58:57 -0700 (MST) Scott Raney <[EMAIL PROTECTED]> wrote >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). Just for the sake of accuracy, in HC & SuperCard , the mouse function does NOT necessarily reutun "down" if the user clicked anytime between when the handler started and when the function is called. Both SuperCard and HyperCard return the actual state of the mouse, up or down, whenever the mouse function is called within a handler, at least under Mac OS 9. Perhaps it works differently in OS X. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
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: Polling the mouse
On Thu, 21 Feb 2002 "J. Scott Saults" <[EMAIL PROTECTED]> wrote: > Thu, 21 Feb 2002 12:58:57 -0700 (MST) > Scott Raney <[EMAIL PROTECTED]> wrote > >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). > > Just for the sake of accuracy, in HC & SuperCard , the mouse function does > NOT necessarily reutun "down" if the user clicked anytime between when the > handler started and when the function is called. Both SuperCard and > HyperCard return the actual state of the mouse, up or down, whenever the > mouse function is called within a handler, at least under Mac OS 9. Perhaps > it works differently in OS X. I didn't check SC, but HC definitely does not work the way you say. Try it yourself and see. Put the following script in a button, then click to run it and click again before the repeats finish (you may need to adjust the count depending on the speed of your system): on mouseUp get 0 repeat for 1 times add 1 to it end repeat put the mouse end mouseUp It's compatibility at that level that's hard to do, convenient as it might be for some things. Regards, Scott Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
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: Polling the mouse
At 10:51 PM -0500 2/21/02, Scott Raney <[EMAIL PROTECTED]> wrote: >I didn't check SC, but HC definitely does not work the way you say. Try it >yourself and see. Put the following script in a button, then click to >run it and click again before the repeats finish (you may need to >adjust the count depending on the speed of your system): >on mouseUp > get 0 > repeat for 1 times > add 1 to it > end repeat > put the mouse >end mouseUp > >It's compatibility at that level that's hard to do, convenient as it >might be for some things. > Regards, Scott Evidently, I misunderstood your original post. I afraid I don't get the point of this post or script, either. I'm sorry to be so dense. It seems to me, in HC, that your script calls the mouse function once, after the repeat loop has finished its 1 iterations. If the mouse button is down when that occurs, then "down" appears in the message box. If the mouse button is up at that moment, then "up" appears in the message box. If I press the mouse while the loop is still being executed, but then release it before the loop is finished, then "up" appears in the message box. This is what I expect, and this seems to be what happens. If, on the other hand, "put the mouse" is executed WITHIN the loop (below), then "down" appears in the message box whenever the mouse is being pressed, and "up" appears whenever it is not being pressed, until the repeated put's have ended. on mouseUp repeat for 1 times add 1 to it put the mouse end repeat end mouseUp So, it seems to me that HyperCard IS returning the actual state of the mouse button, up or down, whenever the mouse function is called within the handler. This is all I meant to say. Is this not true? Obviously, either I've not expressed myself clearly, or I've misunderstood the point of this debate, or both. I certainly apologize for adding my confusion to this discussion. J. Scott Saults ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
On Fri, 22 Feb 2002 "J. Scott Saults" <[EMAIL PROTECTED]> wrote: > > At 10:51 PM -0500 2/21/02, Scott Raney <[EMAIL PROTECTED]> wrote: > >I didn't check SC, but HC definitely does not work the way you say. Try it > >yourself and see. Put the following script in a button, then click to > >run it and click again before the repeats finish (you may need to > >adjust the count depending on the speed of your system): > >on mouseUp > > get 0 > > repeat for 1 times > > add 1 to it > > end repeat > > put the mouse > >end mouseUp > > > >It's compatibility at that level that's hard to do, convenient as it > >might be for some things. > > Regards, > Scott > > Evidently, I misunderstood your original post. I afraid I don't > get the point of this post or script, either. I'm sorry to be so > dense. It seems to me, in HC, that your script calls the mouse > function once, after the repeat loop has finished its 1 > iterations. If the mouse button is down when that occurs, then "down" > appears in the message box. If the mouse button is up at that > moment, then "up" appears in the message box. If I press the mouse > while the loop is still being executed, but then release it before > the loop is finished, then "up" appears in the message box. But did you actually try this? It *doesn't* work that way in either MC or HC now. If you don't see it, try increasing the loop count (you may need to at one zero for HC, and about 3 in MC/RR ;-) My real question is, given that you're confused about this, how many other people must be, and if a lot, does this behavior really need to be preserved? Regards, Scott > J. Scott Saults Scott Raney [EMAIL PROTECTED] http://www.metacard.com MetaCard: You know, there's an easier way to do that... ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
At 1:22 PM -0700 2/22/02, Scott Raney wrote: >But did you actually try this? It *doesn't* work that way in either >MC or HC now. If you don't see it, try increasing the loop count (you >may need to at one zero for HC, and about 3 in MC/RR ;-) Maybe this script will make it clearer: on mouseUp repeat with i = 1000 down to 1 put i end repeat put the mouse end mouseUp If this is in a button, click the button once, and (in either HC or Rev or MC) you will see the message box count down from 1000 to 1, and then display "up" If you click the button, and then press and hold the mouse button (while the countdown is displaying), you will see the message box count down to 1 and then display "down" If you click the button and while the countdown is in progress click a second time (down and up while the countdown is displaying), even though the mouse button is "up" the end message displayed is "down" regards, Geoff ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Scott Raney wrote: > But did you actually try this? It *doesn't* work that way in either > MC or HC now. If you don't see it, try increasing the loop count (you > may need to at one zero for HC, and about 3 in MC/RR ;-) > > My real question is, given that you're confused about this, how many > other people must be, and if a lot, does this behavior really need to > be preserved? I tried this: on mousedown put the mouse repeat 5 times wait 1 second put the mouse end repeat end mousedown In Revolution 1.1.1 Beta 1, it would accurately show if you had kept holding the mouse all the time, had released it once, or had released and pressed it down once more--but it wouldn't show "up" again if you released it the second time. That's not too bad. But even better: adding "with messages" to the wait achieved perfect accuracy. Then I tried this: on mousedown put the mouse repeat 5 repeat with i=100 down to 1 end repeat put the mouse end repeat end mousedown That time, it only said "down" and kept saying down, despite every effort to make it do otherwise. Adding "wait 1 millisec with messages" after the inner repeat loop, however, made it perfectly accurate about the mouse button state. So, at least a bit of tinkering can yield a great result. (I think I've used this technique to use the polling function inside repeat loops also.) As far as the question, should the behavior be maintained if people aren't aware of the exact details, it misses an important point. People don't know the exact behavior of some feature until they need it and try it. No one can be on top of every detail at every time. (Except of course the great teams that produce MC and Rev!) But you have to realize, this is your career and your specialty. Every aspect of our lives involve technologies we use on a daily basis but do not fully understand. But people do have expectations about things which they use and care about, even though they aren't always completely up to date or up to speed on the details. And I'm betting that when people do need to try out this kind of feature, this is what the vast majority would anticipate: that the mouse simply returns "up" when it's up and "down" when it's down. That's what I expect. Of course, absolute perfection is difficult, so I would ask that the behavior aim for perfection and stop where it is practical. If it behaves well in most situations and needs a bit of tinkering now and then for special situations, just like any piece of equipment, then it's acceptable. I think it would be perfect if the capability were there for those people who need to avoid the mouse polling functions in making the very best-behaved software for the most savvy operating systems, but retaining the ability to poll the mouse singly or in repeat statements for people who aren't on such a strict "keyword diet". I think that using the mouse, the mouseLoc, and similar functions once, a few times in a handler, in a repeat loop, or at intervals after actions or waits (adding "with messages" is no incovenience) is very important for typical scripting as it has always worked. Without these keywords and capabilities, the result wouldn't truly be xTalk any more in my opinion. I don't want a situation in the future where I'm not able to script a line like "repeat until the mouse is up." I want to be able to avoid it when necessary, but I always want the option to be there. This type of thing is why I'm here right now with this product in the first place. I consider the use of these functions to be typical scripting style. I want a product that continues to support this style. I also appreciate being able to use other methods when they are called for, but to my viewpoint, that doesn't take away from the polling functions; it just means that they are not suited for certain special situations. I would assert that right now, they are adequate for the great majority of situations, and those special situations are a minority. So, I think that removing or disabling these polling functions would be a huge overreaction to a finite problem. If something needs to be adjusted, that's okay, but the adjustment shouldn't extend far beyond what's necessary to solve the problem. All I'm saying is that we need these functions. Let people avoid them when necessary, but keep them full-strength and usable for when people do choose to use them. How it's done technically doesn't matter too much as long as the behavior is as close to the expected behavior as possible in most situations--single use, multiple single uses over time in a handler, and in repeat loops. If I got mixed up in my previous post with the technical terms and the synchronouslies, my apologies! :-) This time I've avoided all such lingo to make sure it's clear what I'm proposing. In short, I'm opposed to depracating the polling functions. (With the exception of the mouseClick, which I couldn't care less about.) Suggesting that people don't use
Re: Polling the mouse
Scott Raney wrote: > My real question is, given that you're confused about this, how many > other people must be, and if a lot, does this behavior really need to > be preserved? Originally, I thought the answer to this should be "yes", but perhaps it should be "no"--it depends on what the question means. If preserving the behavior means keeping every little detail compatible with HyperCard, then certainly not. It would be great if the polling accuracy could actually be improved and better than HyperCard, and polling after the long repeat loop in the example would return the correct value, even though it doesn't in HyperCard and the current version of MC. I think the behavior doesn't have to be preserved in every detail as it is now, but the functions themselves should be retained and kept working as well as now or better--with the only criteria for judgment being on how accurately they return the true state of what is being polled; if it's different than HyperCard but better than HyperCard, then let's go there! So, there are my answers to both possible meanings I can see in the question. (I know, the question was directed to someone else, but I hope you don't mind me taking it up, since it's a good question.) I really hope that the MC team considers the big picture and does the right thing in fully retaining these functions while making any necessary adjustments. Now, I'm going to try to think about something else for a while! Thanks, Curry Kenworthy ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
> My real question is, given that you're confused about this, how many > other people must be, and if a lot, does this behavior really need to > be preserved? As long as the docs provide clear examples of how to live without it, migrating away from it should not be a problem in the long run. -- 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 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Fri, 22 Feb 2002 13:22:55 -0700 Scott Raney <[EMAIL PROTECTED]> wrote >But did you actually try this? It *doesn't* work that way in either >MC or HC now. If you don't see it, try increasing the loop count (you >may need to at one zero for HC, and about 3 in MC/RR ;-) > >My real question is, given that you're confused about this, how many >other people must be, and if a lot, does this behavior really need to >be preserved? Scott & Geoff, Sorry! I THOUGHT I'd tried it in HC, but I must have done something WRONG. HyperCard does return "down" after the mouse button has been clicked during the loop, even though it is actually up when the script gets "the mouse." Geoff 's step-by-step explanation helped me see this. I'd not understood the implications of this exception to the way "the mouse" seemed to work. I apologize for posting my mistake, but thanks for the correction. The the mouse function seems to check some kind of event queue, rather than actually checking the state of the mouse button. Obviously, the mouse is more complicated than I thought, but maybe most people are not as easily confused as me. During this subsequent testing, I discovered a couple of other curiosities, for what it's worth. SuperCard 3.6 SEEMS to behave more consistently than MC or HC, because it does, according to my tests, return "up" even after clicking during the loop of Scott's script. Also, a slight modification to the 'put' command in Scott's script (below)actually causes HyperCard to put "down up" when the mouse is clicked during the loop and then not pressed again ! Weird. on mouseUp get 0 repeat for 1 times add 1 to it end repeat put the mouse && the mouse end mouseUp My 2¢? Revolution should drop "the mouse" function, unless it can be made to work in a reliable, predictable way, as documented. I can live without it. Scott Saults ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Scott Saults wrote: > My 2¢? Revolution should drop "the mouse" function, unless it can be made > to work in a reliable, predictable way, as documented. I can live without it. Why not take the second option? I say make it work in a reliable way--let it just indicate the real-time mouse button position with a direct call. Drop the HyperCard compatibility rather than dropping the function. (After all, you'd lose a lot more compatibility by removing the whole thing than by altering the behavior to be more straightforward and logical.) I would rather have the mouse give the real position of the mouse--all these buffered behaviors make no sense! As it has been pointed out, most of us don't know the complex behaviors anyway and just expect it to give the mouse value as it is at the time of being called. Surely no one would mind if the behavior is changed, since the alternative considered is to get rid of the whole thing! I already told myself I'd shut up already on this issue after the last post, but sometimes I muddle through a few posts without explaining my intended point as clearly as I tried to, so here goes one more final shot at it. These poor under-appreciated functions are part of the heart and soul of xTalk, allowing us to handle the most common types of interactions in a very intuitive fashion that's easy to learn and convenient to use--without umpteen separate handlers for ups, downs, moves, etc. Come on, people, you'd really rather do that than just say "until the mouse is up" or "if the mouse is down" or "get the mouseH"? Are you really looking at how much you'll be losing? Just because HyperCard made the implementation imperfect and a pain to continue to support compatibly doesn't mean that the concept, syntax, and functionality isn't perfect; it is. Rather than dropping these functions and statements that use these functions, I suggest that MetaCard alter the inner workings and behavior to match what MetaCard needs, and forget about the complex HC behavior. I would prefer simple, direct polling that showed the true state, but something else close to that would also be fine--whatever works for MetaCard, as close to true polling as possible. Then, as far as I could tell, everyone could be happy--people who like separate handlers for OS-friendliness or personal style could use them to their heart's content and pretend the functions no longer exist; people who appreciate the stylish and convenient power of the traditional statements could enjoy them and make good use of them; and hopefully the MetaCard team would have a straightforward way of implementing them that would be a lot easier to support and remove the current problems. I'm a big believer in these functions. They are a familiar and IMHO necessary part of scripting, and other competitive languages for the non-C++ audience, like BASIC, have similar functions. Having two ways to handle these types of interaction--in separate specific handlers and with functions inside other handlers--is the norm. So we need to have both ways too. If the tiny details of the traditional implementation cause problems, it's the tiny details that need to go, but the functions really need to stay. Well, that's it, I'm zipping it! I hope I've made a good case for the survival of these "endangered species" of precious keywords. Thanks, Curry Kenworthy ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Not if the Feds have anything to say about it @;-) Judy On Wed, 27 Feb 2002, Jim Hurley wrote: > By the way, I just heard a rumor that in the next release, MC/RR > will no longer recognize the keyboard. All communication will be > through miss Cleo. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
In a message dated 2/27/02 6:33:47 PM, [EMAIL PROTECTED] writes: << By the way, I just heard a rumor that in the next release, MC/RR will no longer recognize the keyboard. All communication will be through miss Cleo. >> You joke...but I bet you have just touched the next big discussion It's like the game telephone, you say one thing and we weed through a ton of e-mail's. Randy ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
>By the way, I just heard a rumor that in the next release, MC/RR
>will no longer recognize the keyboard. All communication will be
>through miss Cleo.
Jim, et al:
Great news! I've been waiting for this development for years:
Somehow the computer instructions I have in my head often don't make it to
the keyboard correrctly. Since I don't have HAL to read my lips, Cleo's
invtervention would be most appreciated. I presume Cleo's services are
included in my license fee.:{`)
Rob Cozens
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
--- Lince M Lawrence <[EMAIL PROTECTED]> wrote: > What will be the consequence of polling the mouse in > Revolution. > > repeat until the mouse is up > set the loc of btn "dragBtn" to the mouseLoc > end repeat > > Certain people discourage use of this in MetaCard > and Revolution? > > Thanking you, > > Lince M Lawrence > Hi Lince, The main problem with the above construct is that the engine needs to constantly check if the mouse state happened to change. All you'll ever want to know about mouse polling, including how to achieve the same effect withut hogging the CPU, can be found at : <http://www.hyperactivesw.com/polling.html> Hope this helped, Jan Schenkel. = "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Hi Lince, What will be the consequence of polling the mouse in Revolution. Eternal damnation and a special x-talk purgatory! :-D repeat until the mouse is up set the loc of btn "dragBtn" to the mouseLoc end repeat Certain people discourage use of this in MetaCard and Revolution? Jan (or his current clone on duty ;-) is right. It will eat CPU time unecessarily. And this is a very good read indeed: http://www.hyperactivesw.com/polling.html Thanking you, Lince M Lawrence FOCAL IMAGE (INDIA) PVT. LTD. [ mailto:[EMAIL PROTECTED] ] Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Hi Lince, While this routine may eat a few more CPU cycles than usual, it poses absolutely no problems. Since RunRev doesn't thread anyway, there no impact on would be rev-background running applications. CPU hogging is only 20% more than resizing or moving any window in windows (out of runrev). Moving or resizing a stack in rev will equally eat as much if not more CPU! It's also much easier to implement, edit and debug IMOHO. The mousedown event is usually pretty short anyway (depending on the application naturally.) My 2 cents Xavier On 01.12.2004 09:40:37 use-revolution-bounces wrote: >Hi Lince, > >> What will be the consequence of polling the mouse in Revolution. > >Eternal damnation and a special x-talk purgatory! :-D > >> repeat until the mouse is up >> set the loc of btn "dragBtn" to the mouseLoc >> end repeat >> >> Certain people discourage use of this in MetaCard and Revolution? > >Jan (or his current clone on duty ;-) is right. >It will eat CPU time unecessarily. > >And this is a very good read indeed: >http://www.hyperactivesw.com/polling.html > >> Thanking you, >> >> Lince M Lawrence >> FOCAL IMAGE (INDIA) PVT. LTD. >> [ mailto:[EMAIL PROTECTED] ] > >Regards > >Klaus Major >[EMAIL PROTECTED] >http://www.major-k.de > >___ >use-revolution mailing list >[EMAIL PROTECTED] >http://lists.runrev.com/mailman/listinfo/use-revolution - Visit us at http://www.clearstream.com IMPORTANT MESSAGEInternet communications are not secure and therefore Clearstream International does not accept legal responsibility for the contents of this message.The information contained in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any views expressed in this e-mail are those of the individual sender, except where the sender specifically states them to be the views of Clearstream International or of any of its affiliates or subsidiaries.END OF DISCLAIMER ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse
Hi Lince, What will be the consequence of polling the mouse in Revolution. repeat until the mouse is up set the loc of btn "dragBtn" to the mouseLoc end repeat in this case the following would be more effective: Script of btn "dragBtn" on mousedown grab me end mousedown No damnation and no purgatory ;-) Thanking you, Lince M Lawrence FOCAL IMAGE (INDIA) PVT. LTD. [ mailto:[EMAIL PROTECTED] ] Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
On 20/2/02 2:50 pm, "Jim Hurley" <[EMAIL PROTECTED]> scribed: > Hi Ian, >> >>> I don't like the grab command, it seems to me program flow doesn't >>> stop, >>> i.e. >> >> maybe you missed some of the previous posts, where experts (!) are >> advising to >> not poll the mouse-state. >> >> It is far more efficient to use the mousemove function. Using the mousemove is no good. I want to suspect all the messages from happening while I'm dragging a pin around on my timer plug. With mousemove I'm effectively dropping back to an "idle" state between each call, I need to stay in the handler, to do that I'm back to checking myself whether the mouse is still down or not. Try this as an example, call beeper from the message box to get the beeps going, then the challenge is to make the drag work but suspect the beeps, however, just killing the event is no answer, my program might have 30-40 different events pending and killing them all is out of the question. Put in card script, and have a button called "drag": on mousedown global dragging put the short name of the target = "drag" into dragging end mousedown on mousemove x,y global dragging put x & "," & y into myPointIs if xyz then set the loc of the target to myPointIs -- I have code here to check whether the object has intersected other -- things, if so different drag handlers take over, so using the -- drag command isn't on end mousemove on mouseup global dragging put false into dragging end mouseup on beeper beep send beeper to this card in 10 secs end beeper And all hell is let loose if a mouseup event is lost, as can happen if you switch out of revolution with the mouse still down. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
on 2/20/02 6:50 AM, Jim Hurley at [EMAIL PROTECTED] wrote: > This issue of polling the mouse state continues to crop up. I have > had to avoid the use of the old HyperCard standby: > > "repeat while the mouse is down" -- I love "repeat while the mouse is down" because it allows me to do a bunch of mouseDown stuff, then a bunch of mouseUp stuff when the repeat ends, all in one handler. I'm working on an HC stack right now that uses it. Never had a problem in HC, except with the occasional bonk in an idle handler, but NEVER in a repeat loop. Does 'grab' and 'mousemove' really have potential response speed problems in RR/MC? I have some HC stacks I want to convert where a 'hunting' button is tied to the cursor. This ability is key to the stack's function, no good without it. Best regards, Ken N. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
> At 4:37 AM + 2/21/02, Ian Summerfield wrote: >> Using the mousemove is no good. I want to suspect all the messages from >> happening while I'm dragging a pin around on my timer plug. With >> mousemove >> I'm effectively dropping back to an "idle" state between each call, I >> need >> to stay in the handler, to do that I'm back to checking myself whether >> the >> mouse is still down or not. Doesn't "grab" do what you want? I think it suspends other messages while the user is dragging and automatically exits when the user lets go of the mouse button. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
On 21/2/02 4:24 pm, "Jacqueline Landman Gay" <[EMAIL PROTECTED]> scribed: > > Doesn't "grab" do what you want? I think it suspends other messages while > the user is dragging and automatically exits when the user lets go of the > mouse button. No, drag doesn't let me check whether the object has been dragged into the bounds of another while the dragging is still going on. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
Jacqueline Landman Gay writes: > Doesn't "grab" do what you want? I think it suspends other messages while > the user is dragging and automatically exits when the user lets go of the > mouse button. The grab command could give me everything I need for 90% of the times I need such a thing, if only I could specify bounds for the dragging operation (I usually need to restrict it to either axis, or within a given rect). Any syntax sugestions for such an addition? -- 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 ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
on 2/21/02 12:10 PM, Ian Summerfield at [EMAIL PROTECTED] wrote: > On 21/2/02 4:24 pm, "Jacqueline Landman Gay" <[EMAIL PROTECTED]> scribed: > >> >> Doesn't "grab" do what you want? I think it suspends other messages while >> the user is dragging and automatically exits when the user lets go of the >> mouse button. > > No, drag doesn't let me check whether the object has been dragged into the > bounds of another while the dragging is still going on. -- I need to do the exact same thing in an eduware game stack. I'll be watching for the solutions while trying my own. Best regards, Ken N. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
On Thursday, February 21, 2002, at 03:27 PM, Ken Norris (dialup) wrote: >>> Doesn't "grab" do what you want? I think it suspends other messages >>> while >>> the user is dragging and automatically exits when the user lets go of >>> the >>> mouse button. >> >> No, drag doesn't let me check whether the object has been dragged into >> the >> bounds of another while the dragging is still going on. > -- > I need to do the exact same thing in an eduware game stack. I'll be > watching > for the solutions while trying my own. Is this what you folks are trying to do? http://www.tactilemedia.com/download/ Regards, Scott Rossi Creative Director, Tactile Media [EMAIL PROTECTED] http://www.tactilemedia.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Polling the mouse state
Wow, What a web site. Very, very nice! You didn't do that using Revolution did you? Alistair Campbell Senior Clinical Psychologist Manager, CAMHS(N): "Oakrise" 3 Kelham St, Launceston, Tas, 7250 Ph: (03) 6336 2867 Fax:(03) 6336 2886 Email: <mailto:[EMAIL PROTECTED]> -Original Message- From: Scott Rossi [mailto:[EMAIL PROTECTED]] Sent: Friday, 22 February 2002 11:07 AM To: [EMAIL PROTECTED] Subject: Re: Polling the mouse state On Thursday, February 21, 2002, at 03:27 PM, Ken Norris (dialup) wrote: >>> Doesn't "grab" do what you want? I think it suspends other messages >>> while >>> the user is dragging and automatically exits when the user lets go of >>> the >>> mouse button. >> >> No, drag doesn't let me check whether the object has been dragged into >> the >> bounds of another while the dragging is still going on. > -- > I need to do the exact same thing in an eduware game stack. I'll be > watching > for the solutions while trying my own. Is this what you folks are trying to do? http://www.tactilemedia.com/download/ Regards, Scott Rossi Creative Director, Tactile Media [EMAIL PROTECTED] http://www.tactilemedia.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
On 22/2/02 12:07 am, "Scott Rossi" <[EMAIL PROTECTED]> scribed: > On Thursday, February 21, 2002, at 03:27 PM, Ken Norris (dialup) wrote: > Doesn't "grab" do what you want? I think it suspends other messages while the user is dragging and automatically exits when the user lets go of the mouse button. >>> >>> No, drag doesn't let me check whether the object has been dragged into >>> the >>> bounds of another while the dragging is still going on. >> -- >> I need to do the exact same thing in an eduware game stack. I'll be >> watching >> for the solutions while trying my own. > > Is this what you folks are trying to do? > > http://www.tactilemedia.com/download/ > > Regards, > Well sort of, but the messages are still being sent, I need to suspend all other events while the dragging takes place. There might be as many as 12 events pending. That's the bit I'm having trouble with. I don't know whether I might be able to save the pendingmessages into a global and restore them once the dragging is done. -i- ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
on 2/20/02 10:47 PM, Geoff Canyon at [EMAIL PROTECTED] wrote: > If you have a specific need that seems to require "repeat while the mouse is > down," post it and we'll see if we can figure a way around it. > -- Not exactly, but, how about this: on mousestilldown put max(81,min(557,the mouseh)) into x put max(167,min(287,the mousev)) into y set the loc of me to x,y end mousestilldown ...This is an oval (made round) button with the hilite set to true. It 'sees through' a black-filled rectangular box, like a spyglass, so the user can see portions of a color image underneath. It stays within the borders of the box as you drag it around. The user is looking for an object. When they find what they believe is the correct object, release the mouse button (other stuff left out of the example): on mouseUp global objCnt, plyrName,gmName,total,xFer,objName,verse get the loc of me if it is within rect of bg fld (objCnt+2) then --other stuff here-- end if end mouseUp Thanks for looking, Ken N. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
Recently, Ken Norris (dialup) wrote: >> If you have a specific need that seems to require "repeat while the mouse is >> down," post it and we'll see if we can figure a way around it. >> > -- > Not exactly, but, how about this: > > on mousestilldown > put max(81,min(557,the mouseh)) into x > put max(167,min(287,the mousev)) into y > set the loc of me to x,y > end mousestilldown > > ...This is an oval (made round) button with the hilite set to true. It 'sees > through' a black-filled rectangular box, like a spyglass, so the user can > see portions of a color image underneath. It stays within the borders of the > box as you drag it around. The user is looking for an object. > > When they find what they believe is the correct object, release the mouse > button If I understand your request, this is one way you could do the above. Make 3 small graphics named box 1, box 2 and box 3 within the region you define. Then place the following script in your oval: on mouseDown set the uAllowMove of me to true end mouseDown on mouseMove x,y if not the uAllowMove of me then exit mouseMove set the loc of me to (max(81,min(557,x))),(max(167,min(287,y))) end mouseMove on mouseUp set the uAllowMove of me to empty put "box1,box2,box3" into bList repeat for each item B in bList if within(me,loc of grc B) then put "You found box" && B exit repeat else put empty end repeat end mouseUp on mouseRelease mouseUp end mouseRelease - This should display the name (in the message box) of any box graphic that falls within the oval when the mouse is released. BTW, did you look at the drag example I posted a few days ago? http://www.tactilemedia.com/download/drag_sample.mc You might find this useful. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
on 2/23/02 12:47 PM, Scott Rossi at [EMAIL PROTECTED] wrote: > If I understand your request, this is one way you could do the above. Make > 3 small graphics named box 1, box 2 and box 3 within the region you define. > Then place the following script in your oval: > > on mouseDown > set the uAllowMove of me to true > end mouseDown > > on mouseMove x,y > if not the uAllowMove of me then exit mouseMove > set the loc of me to (max(81,min(557,x))),(max(167,min(287,y))) > end mouseMove > > on mouseUp > set the uAllowMove of me to empty > put "box1,box2,box3" into bList > repeat for each item B in bList > if within(me,loc of grc B) then > put "You found box" && B > exit repeat > else put empty > end repeat > end mouseUp -- This much I understand. I have 10 objects in each card, but the principal is the same. --- > on mouseRelease > mouseUp > end mouseRelease -- Is this some kind of backup redundancy for PC's? As far as I know, the mouseUp message gets sent automatically when you release the mouse, and doesn't need a separate handler. -- > This should display the name (in the message box) of any box graphic that > falls within the oval when the mouse is released. > > BTW, did you look at the drag example I posted a few days ago? > > http://www.tactilemedia.com/download/drag_sample.mc -- I haven't yet. I couldn't get it to DL. I'm using a Mac. I'll try again later. Thanks somuch, Ken N. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Polling the mouse state
Recently, Ken Norris (dialup) wrote: >> on mouseRelease >> mouseUp >> end mouseRelease > -- > Is this some kind of backup redundancy for PC's? As far as I know, the > mouseUp message gets sent automatically when you release the mouse, and > doesn't need a separate handler. You need this handler in case the mouse is released when it falls outside the rect of the dragged object. You risk missing the mouseUp event if you don't include this handler. >> BTW, did you look at the drag example I posted a few days ago? >> >> http://www.tactilemedia.com/download/drag_sample.mc > -- > I haven't yet. I couldn't get it to DL. I'm using a Mac. I'll try again > later. I use Macs as well. Just control click the link and choose "Download link to disk" or equivalent. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design Email: [EMAIL PROTECTED] Web: www.tactilemedia.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
