Shared menus
Richard Gaskin wrote: Dude, don't get me started. While I have apps written for Win95 that continue to run without difficulty in Microsoft's latest OS, on Mac we've had to port from 68k to PPC, and then from Classic to OS X, and even now stuff break between releases of OS X. You have reason, but it must consider also that XP is only little different from Windows 98, while Classic and MacOsX are example of a core and GUI real progress. However, if someone knows a workaround in order to realize a shared menu, it will be the welcome. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Shared menus
At 5:53 PM +0200 10/6/2005, Paul Claude wrote: I need, as for ABDialer or Jon's Phone Tool, to make a menu available from any app with the possibility to make a phone call, choosing an address, etc. There is no way currently to do this in Rev; you would need a low-level compiler. Perhaps a system window would do? This is a type of palette that floats above all applications, so it's always in front. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: HELP!! - Geometry Gone Berserk, How to fix?
At 12:11 PM +0100 10/6/2005, David Burgun wrote: HELP! I have a Stack and the geometry has gone berserk. I have a breakpoint inserted in a preOpenStack handler that allows me to quit the startup path. If I let it continue the Stack displays and the geometry has scaled/moved objects as if the Stack window were MUCH bigger. If I Abort in the debugger, the stack displays ok. However, if I type: revUpdateGeometry (which would have been called on the preOpenStackk path anyway) The geometry goes beswick! How it fix? Is there anyway of resetting the geometry of the Stack? With the stack in the correct state (e.g. if you abort), try typing revCacheGeometry in the message box. In theory this should rebuild the Geometry Manager settings, and base them off the current position and size. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: # POSSIBLY SPAM #::Re: HELP!! - Geometry Gone Berserk, How to fix?
David, Jeane, only in theory... In practice, i've seen this not work, work wrong, rescrew everything... i've never seen this work correctly... I know because i tried for MONTHS not to go crazy with the thing!!! The best way to make this work: make a handler to save all your control's positions try rev*geocraptry if it doesn't work, you can restore the geometry with your settings. Rev's cachegeostuff doesn't work 100% correctly... cheers Xavier [EMAIL PROTECTED] wrote on 07/10/2005 10:06:50: At 12:11 PM +0100 10/6/2005, David Burgun wrote: HELP! I have a Stack and the geometry has gone berserk. I have a breakpoint inserted in a preOpenStack handler that allows me to quit the startup path. If I let it continue the Stack displays and the geometry has scaled/moved objects as if the Stack window were MUCH bigger. If I Abort in the debugger, the stack displays ok. However, if I type: revUpdateGeometry (which would have been called on the preOpenStackk path anyway) The geometry goes beswick! How it fix? Is there anyway of resetting the geometry of the Stack? With the stack in the correct state (e.g. if you abort), try typing revCacheGeometry in the message box. In theory this should rebuild the Geometry Manager settings, and base them off the current position and size. -- jeanne a. e. devoto ~ [EMAIL PROTECTED] http://www.jaedworks.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution - Visit us at http://www.clearstream.com IMPORTANT MESSAGE Internet 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 use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Speed optimisation
Dick Kriesel wrote: On 10/6/05 4:21 AM, Alex Tweedly [EMAIL PROTECTED] wrote: Hmmm - can you give a case where Kay's method gives wrong answers because of a negative seconds value ? As far as I can see (both by inspection and by testing) it always gets it right. Whenever the negative seconds cause the result to be negative, the result is wrong. For example, 00:01:00.5,-61 gives 23:59:59.5. But that's the right answer ! 00:01:00.5 represents 60.5 seconds after midnight. Subtract 61 seconds and you should get .6 seconds before midnight - i.e. 23:59:59.5 But even if the convert function didn't cause a wrap-around, the result would be wrong, because the decimal digit is appended without checking the sign. The function would compute (60-61).5 = -1.5 seconds, instead of -.5 seconds. There's no need to check a sign here. Any fractional part of a second in the original time value is always positive; so you always want to add it. Since the result is also always positive (it uses wrap-around rather than return negative times), the positive fractional part should always be added. In the case you mention, (60-61).5 doesn't give -1.5, what it gives is the wrapped version, i.e. (something:59).5 On the other hand, both your method and mine (which is really just a variant of yours) get it wrong in key cases of negative seconds (e.g. 00:00:00.1 - 31 gives 0:00:0-31 for you and 0:00:0-31.0 for me - both rather hopeless :-) So I'm glad I wasn't throwing any stones. Here's a new version that handles negative seconds and negative results correctly (I think): No, it doesn't I'm afraid. 00:00:00.0 - 31 gives a wrong answer. You can fix that with an extra if test to put in a sign if the whole tSeconds is negative. But once you've done that, even using the format variant for its speed, it's slower than Kay's version using twelvehourtime. Rob indicated in another email that they could change the spec to allow wrap-around within the 24-hour space. So *if* Rob can accept the missing trailing 0 then Kay is the winner apparent for the QP (pending any other faster method). function addTimeAndSeconds pTime,pSeconds set the itemDelimiter to : put item 1 of pTime * 3600 + item 2 of pTime * 60 + item 3 of pTime \ + pSeconds into tSeconds put tSeconds div 3600 : abs(tSeconds) mod 3600 div 60 : \ abs(tSeconds) mod 60 into tTime if item 2 of tTime 10 then put 0 before item 2 of tTime if item 3 of tTime 10 then put 0 before item 3 of tTime return tTime end addTimeAndSeconds The new version runs faster than my old, invalid version, oddly enough. I wonder if Rob still cares... -- Dick ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- Alex Tweedly http://www.tweedly.net No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Strange math behaviour... could someone explain this ?
Hi list, example 1 : put 1.8 into myA put trunc(myA * 100) into myA in that case, myA=180which is OK -- example 2 : put 34.2 into myA put 36 into myT if myA 0 then if myA myT then get myA put myT - myA into myA put it into myT else put 0 into myA end if end if put trunc(myA * 100) into myA in that case, myA=179? Best, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
I get the same thing... That's gotta be a bug. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 7:17 AM To: How to use Revolution Subject: Strange math behaviour... could someone explain this ? Hi list, example 1 : put 1.8 into myA put trunc(myA * 100) into myA in that case, myA=180which is OK -- example 2 : put 34.2 into myA put 36 into myT if myA 0 then if myA myT then get myA put myT - myA into myA put it into myT else put 0 into myA end if end if put trunc(myA * 100) into myA in that case, myA=179? Best, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: destroyStack, was: Stack Switching Question
Robert, 1. Clicking the go away box in the window of a stack should close it (and any substacks). In other words, clicking the close box should close the stack. Clicking the box in a substack should hide it. 2. You can do whatever you want with modals - probably Show and Hide, as needed. 3. If the stack is loaded but not visible, just Show Stack - no need to close or unload. Ken seems to have all the bases covered. Paul Looney -Original Message- From: Robert Brenstein [EMAIL PROTECTED] To: How to use Revolution use-revolution@lists.runrev.com Sent: Fri, 7 Oct 2005 01:27:42 +0200 Subject: Re: destroyStack, was: Stack Switching Question On 10/6/05 3:23 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Jeanne, It got 5 of my votes as well. But I think there is more confusion here. Paul, I think the open/close and load/purge ideas are great, with a few minor changes (plus I've included other terms in use to get an overview of the situation): load stack stackDescriptor Loads stack into memory, does not display it, does not get listed in the 'openstacks'. [Resulting status: loaded] unload stack stackDescriptor Removes stack from memory (Note: does not work on 'open' stacks.) [Resulting status: closed] open stack stackDescriptor Loads stack into memory, makes it visible, locks stack from other users, adds entry to 'openStacks'. [Resulting status: open] open inv[isible] stack stackDescriptor Loads stack into memory, keeps it hidden, locks stack from other users, adds entry to 'openStacks'. [Resulting status: open] close stack stackDescriptor Releases lock on stack, removes the stack image from the screen, unloads the stack from memory, removes the entry from the 'openStacks'. [Resulting status: closed] close stack stackDescriptor and remain resident Releases lock on stack, removes the stack image from the screen, removes the entry from the 'openStacks', but keeps the stack in memory. [Resulting status: loaded] hide stack stackDescriptor Hides the stack image from the screen. (Note: does not work on closed stacks.) [Resulting status: open] show stack stackDescriptor Shows the stack image. (Note: does not work on closed stacks.) [Resulting status: open] That's my 2 cents... Not really wanting to prolong this but... What happens when user clicks the close box of a stack window? Is the stack closing or hiding? How is this going to work with a substack that is shown repeatedly as a modal dialog or a palette upon some user action, so it should stay in memory? Many of my dialog stacks (particularly modeless) use openstack to initialize things and closestack to wrap things up. What happens if the stack was loaded but then needs to be shown to user? Does it have to be first unloaded before opening? Robert ___ use-revolution mailing list [EMAIL PROTECTED] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
Even just this simple line produces the same error: answer trunc((36-34.2)*100) This is odd... Look at the results I get when testing this: Trunc((36-34.1)*100) should = 190, but returns 189 Trunc((36-34.2)*100) should = 180, but returns 179 Trunc((36-34.3)*100) should = 170, and in fact does return 170 Trunc((36-34.4)*100) should = 160, and in fact does return 160 Trunc((1.8)*100) returns 180, like it should Trunc((1.9)*100) returns 190, like it should So... Somehow, Rev is performing 36-34.2, and even though it displays that number as 1.8, it must be processing it internally as 1.799 or something like that. Very disturbing - This could affect a program of mine. It is easily worked around, with a function like this: function trueTrunc pNumber set the itemdelimiter to . return item 1 of pNumber end trueTrunc But still, trunc should work properly. That makes me wonder if any other math functions might have some underlying weirdness. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lynch, Jonathan Sent: Friday, October 07, 2005 9:13 AM To: How to use Revolution Subject: RE: Strange math behaviour... could someone explain this ? I get the same thing... That's gotta be a bug. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 7:17 AM To: How to use Revolution Subject: Strange math behaviour... could someone explain this ? Hi list, example 1 : put 1.8 into myA put trunc(myA * 100) into myA in that case, myA=180which is OK -- example 2 : put 34.2 into myA put 36 into myT if myA 0 then if myA myT then get myA put myT - myA into myA put it into myT else put 0 into myA end if end if put trunc(myA * 100) into myA in that case, myA=179? Best, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
Further confirmation of what JB noticed: This: round(((36-34.2)*100)-.5) also returns 179, when it should return 180. So the problem is not in the trunc function itself, it is in the way Rev performs a calculation like 36-34.2 -- How many accounting errors might this have caused for people? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lynch, Jonathan Sent: Friday, October 07, 2005 9:32 AM To: How to use Revolution Subject: RE: Strange math behaviour... could someone explain this ? Even just this simple line produces the same error: answer trunc((36-34.2)*100) This is odd... Look at the results I get when testing this: Trunc((36-34.1)*100) should = 190, but returns 189 Trunc((36-34.2)*100) should = 180, but returns 179 Trunc((36-34.3)*100) should = 170, and in fact does return 170 Trunc((36-34.4)*100) should = 160, and in fact does return 160 Trunc((1.8)*100) returns 180, like it should Trunc((1.9)*100) returns 190, like it should So... Somehow, Rev is performing 36-34.2, and even though it displays that number as 1.8, it must be processing it internally as 1.799 or something like that. Very disturbing - This could affect a program of mine. It is easily worked around, with a function like this: function trueTrunc pNumber set the itemdelimiter to . return item 1 of pNumber end trueTrunc But still, trunc should work properly. That makes me wonder if any other math functions might have some underlying weirdness. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lynch, Jonathan Sent: Friday, October 07, 2005 9:13 AM To: How to use Revolution Subject: RE: Strange math behaviour... could someone explain this ? I get the same thing... That's gotta be a bug. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 7:17 AM To: How to use Revolution Subject: Strange math behaviour... could someone explain this ? Hi list, example 1 : put 1.8 into myA put trunc(myA * 100) into myA in that case, myA=180which is OK -- example 2 : put 34.2 into myA put 36 into myT if myA 0 then if myA myT then get myA put myT - myA into myA put it into myT else put 0 into myA end if end if put trunc(myA * 100) into myA in that case, myA=179? Best, JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
According to my tests (which aren't exhaustive) there seems to be another workaround : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) this gives 180 as a result, while the following line (replacing the last 2 of the above example) gives 179 put trunc(C*100) into C JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
I just tried this script - but I still get 179 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 10:02 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? According to my tests (which aren't exhaustive) there seems to be another workaround : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) this gives 180 as a result, while the following line (replacing the last 2 of the above example) gives 179 put trunc(C*100) into C JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
with Rev 2.5 on Mac OS9.1 the following gives 180 put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) but with Rev 2.5 Linux I still get 179... so much for Xplatform compatibility :( JB I just tried this script - but I still get 179 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 10:02 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? According to my tests (which aren't exhaustive) there seems to be another workaround : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) this gives 180 as a result, while the following line (replacing the last 2 of the above example) gives 179 put trunc(C*100) into C JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
Lynch, Jonathan wrote: Even just this simple line produces the same error: snip Somehow, Rev is performing 36-34.2, and even though it displays that number as 1.8, it must be processing it internally as 1.799 or something like that. Very disturbing - This could affect a program of mine. It is easily worked around, with a function like this: function trueTrunc pNumber set the itemdelimiter to . return item 1 of pNumber end trueTrunc That won't necessarily work. trueTrunc(179.) == 179 You need to be very careful how you test things like this given half a chance, Transcript will use a string representation rather than an arithmetic one. set the itemDel to . put something into myT put item 1 of myT trunc(myT) Gives the following results something output 179.179 179 (it used the string repr) 179.+0 180 179 (the addition forced arithmetic representation - and then got rounding; trunc didn't get any rounding). But still, trunc should work properly. That makes me wonder if any other math functions might have some underlying weirdness. (see the little snippet above :-) As I understand it (though I can't now find it in the docs), when doing arithmetic Transcript represents numbers in the most suitable format - either integer or double-prec floating point. In the example here, because it has 34.2 the suitable precision is double. Since many simple decimal floating values can't be exactly represented in binary floating point format, there is always a chance of minor discrepancies between the obvious value and the precise one used by Transcript. Transcript does a good job of magically rounding as needed - but the issue is still there. trunc(x) is always dangerous because it will truncate down to the lower integral part (e.g. 179.999 -- 179) if there is even the tiniest discrepancy. Much safer would be to trunc(x+delta), where delta is the level of accuracy required - say typically delta = 0.05 trueTrunc() will be slightly safer because it uses Transcripts magic conversion, and hence rounds off at some nominal level - probably 6 decimal places or something like that -- but if it were me I'd rather take control and determine for myself what number of digits to do the rounding at. I do not believe this is a bug - merely a trap for the unwary. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Copy Image
Thanks Chip and Sarah for your responses. It seems to be a false alarm. Or at least not a real problem for rev but rather for Constellation... :( I love Constellation. Jerry has done a terrific job. But it seems to be throwing a phantom error here. Or at least switching to using Rev's Object editors removes the error. I am going to see if I can recreate the problem in simple stack pair and send it to Jerry. Thanks Again Todd On 10/6/05 10:47 PM, Sarah Reichelt [EMAIL PROTECTED] wrote: I am trying to copy and image from the current card to a card in a external stack, GrommetData. If the image is already there from a previous copy, I delete it first and then copy it to the card. If the image is already there all works as expected, BUT if the image is not alredy there I get an error after the image is copied. The handler looks like this IF exists (img image of cd tCard of stack GrommetData) THEN delete img image of cd tCard of stack GrommetData END if copy img image to cd tCard of stack GrommetData Hi Todd, I just made a test with a mainStack and a sub-stack called Sub. I imported an image from the image library and tested it with the following button script: on mouseUp if there is an img alerthand.gif of cd 1 of stack Sub then delete img alerthand.gif of cd 1 of stack Sub wait 1 second end if copy img alerthand.gif to cd 1 of stack Sub put the result end mouseUp It all worked perfectly whether Sub had the image already or not. (The wait is only there so that I can see that the original is really deleted). You say the error occurs after the image has been copied. What is the error? What happens next in your script? If you isolate the copying script completely, does it work then? Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- Todd Geist __ g e i s t i n t e r a c t i v e ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
Um... Really freakin' weird! I am on win 2000, and that script returns 179 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 10:27 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? with Rev 2.5 on Mac OS9.1 the following gives 180 put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) but with Rev 2.5 Linux I still get 179... so much for Xplatform compatibility :( JB I just tried this script - but I still get 179 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 10:02 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? According to my tests (which aren't exhaustive) there seems to be another workaround : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) this gives 180 as a result, while the following line (replacing the last 2 of the above example) gives 179 put trunc(C*100) into C JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
If you add in a line like this: Put char 1 to -1 of C into C then it forces Rev to use the proper number, rather than the almost-but-not-quite proper number - but man, that has gotta slow things down. Basically, that is forcing it to convert it from a number to text, then back to a number. For mass calculations, that would be a real problem. But, it is another work-around -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 10:27 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? with Rev 2.5 on Mac OS9.1 the following gives 180 put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) but with Rev 2.5 Linux I still get 179... so much for Xplatform compatibility :( JB I just tried this script - but I still get 179 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jbv Sent: Friday, October 07, 2005 10:02 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? According to my tests (which aren't exhaustive) there seems to be another workaround : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) this gives 180 as a result, while the following line (replacing the last 2 of the above example) gives 179 put trunc(C*100) into C JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
The method you are suggesting would also be faster, because it does not force a type conversion -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Tweedly Sent: Friday, October 07, 2005 10:20 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? Lynch, Jonathan wrote: Even just this simple line produces the same error: snip Somehow, Rev is performing 36-34.2, and even though it displays that number as 1.8, it must be processing it internally as 1.799 or something like that. Very disturbing - This could affect a program of mine. It is easily worked around, with a function like this: function trueTrunc pNumber set the itemdelimiter to . return item 1 of pNumber end trueTrunc That won't necessarily work. trueTrunc(179.) == 179 You need to be very careful how you test things like this given half a chance, Transcript will use a string representation rather than an arithmetic one. set the itemDel to . put something into myT put item 1 of myT trunc(myT) Gives the following results something output 179.179 179 (it used the string repr) 179.+0 180 179 (the addition forced arithmetic representation - and then got rounding; trunc didn't get any rounding). But still, trunc should work properly. That makes me wonder if any other math functions might have some underlying weirdness. (see the little snippet above :-) As I understand it (though I can't now find it in the docs), when doing arithmetic Transcript represents numbers in the most suitable format - either integer or double-prec floating point. In the example here, because it has 34.2 the suitable precision is double. Since many simple decimal floating values can't be exactly represented in binary floating point format, there is always a chance of minor discrepancies between the obvious value and the precise one used by Transcript. Transcript does a good job of magically rounding as needed - but the issue is still there. trunc(x) is always dangerous because it will truncate down to the lower integral part (e.g. 179.999 -- 179) if there is even the tiniest discrepancy. Much safer would be to trunc(x+delta), where delta is the level of accuracy required - say typically delta = 0.05 trueTrunc() will be slightly safer because it uses Transcripts magic conversion, and hence rounds off at some nominal level - probably 6 decimal places or something like that -- but if it were me I'd rather take control and determine for myself what number of digits to do the rounding at. I do not believe this is a bug - merely a trap for the unwary. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
But still... Answer trunc((36-34.2)*100) should return 180, not 179. I mean, the underlying code should work to return an accurate value. Perhaps it is just a matter of opinion, but to me, if the software returns a wrong value in a calculation, it is a bug. I use trunc in a calendar that calculates things like the number of weeks in a month, or which days belong in which week of a given month. An error of this sort could put a day into the wrong week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Tweedly Sent: Friday, October 07, 2005 10:20 AM To: How to use Revolution Subject: Re: Strange math behaviour... could someone explain this ? Lynch, Jonathan wrote: Even just this simple line produces the same error: snip Somehow, Rev is performing 36-34.2, and even though it displays that number as 1.8, it must be processing it internally as 1.799 or something like that. Very disturbing - This could affect a program of mine. It is easily worked around, with a function like this: function trueTrunc pNumber set the itemdelimiter to . return item 1 of pNumber end trueTrunc That won't necessarily work. trueTrunc(179.) == 179 You need to be very careful how you test things like this given half a chance, Transcript will use a string representation rather than an arithmetic one. set the itemDel to . put something into myT put item 1 of myT trunc(myT) Gives the following results something output 179.179 179 (it used the string repr) 179.+0 180 179 (the addition forced arithmetic representation - and then got rounding; trunc didn't get any rounding). But still, trunc should work properly. That makes me wonder if any other math functions might have some underlying weirdness. (see the little snippet above :-) As I understand it (though I can't now find it in the docs), when doing arithmetic Transcript represents numbers in the most suitable format - either integer or double-prec floating point. In the example here, because it has 34.2 the suitable precision is double. Since many simple decimal floating values can't be exactly represented in binary floating point format, there is always a chance of minor discrepancies between the obvious value and the precise one used by Transcript. Transcript does a good job of magically rounding as needed - but the issue is still there. trunc(x) is always dangerous because it will truncate down to the lower integral part (e.g. 179.999 -- 179) if there is even the tiniest discrepancy. Much safer would be to trunc(x+delta), where delta is the level of accuracy required - say typically delta = 0.05 trueTrunc() will be slightly safer because it uses Transcripts magic conversion, and hence rounds off at some nominal level - probably 6 decimal places or something like that -- but if it were me I'd rather take control and determine for myself what number of digits to do the rounding at. I do not believe this is a bug - merely a trap for the unwary. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
Lynch, Jonathan wrote:
But still...
Answer trunc((36-34.2)*100) should return 180, not 179.
No it shouldn't.
I mean, the
underlying code should work to return an accurate value.
It does.
Perhaps it is just a matter of opinion, but to me, if the software returns a
wrong
value in a calculation, it is a bug.
It's not a matter of opinion, and it's not a wrong answer - it's a
correct answer. The binary double precision representation of 34.2 is
inexact, and hence the binary double precision representation of 36-34.2
is similarly inexact - so instead of exactly 180, it's about 1x2**-40
less than that.
And then when you use trunc() it does what you ask.
It's NOT a Rev bug - it's an artifact of double precision binary
arithmetic (or, if you like, an artifact of the IEEE format used by
Intel (and everyone else)).
Here's the equivalent C program and its output (Intel P4, WinXP,
Bloodshed C++ IDE):
#include stdio.h
#include stdlib.h
#include math.h
int main(int argc, char *argv[])
{
double f1, f2;
double t1, t2;
int i;
f1 = 36.0;
f2 = 34.2;
printf(%6.4f %6.4f\n, f1, f2);
t1 = 100.0*(f1-f2);
t2 = trunc(t1);
printf(%6.4f gives %6.4f\n, t1, t2);
system(PAUSE);
return 0;
}
36. 34.2000
180. gives 179.
I use trunc in a calendar that calculates things like the number of
weeks in a month, or which days belong in which week of a given month.
An error of this sort could put a day into the wrong week.
Users of trunc() (whichever language they use it in :-) should be wary
of the dangers.
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Strange math behaviour... could someone explain this ?
It's NOT a Rev bug - it's an artifact of double precision binary arithmetic (or, if you like, an artifact of the IEEE format used by Intel (and everyone else)). Alex, your explanation makes perfect sense, and I accept that it is not a Rev bug. But... I still don't like it, though. This affects both the trunc and round functions. Are there any others that are affected by this? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
Alex, Users of trunc() (whichever language they use it in :-) should be wary of the dangers. Thank you so much for your explanations. As for rev users, I strongly suggest that this potential problem should be mentioned in the doc, at least in the part dedicated to the trunc() function... Nevertheless, how do you explain that the following : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) returns 180 with Rev 2.5 on Mac OS9, but returns 179 on other platforms such as Linux or Win2000 ? Just curious... JB ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
enlarge field to size of labeltext
Hi All I have a button that resizes a label (custonlabel) via 2 fields labelnewname and labelnewtextsize. the script is on mouseUp set the text of field CustomLabel to field LabelNewName set the textsize of field CustomLabel to field LabelNewTextsize end mouseUp I have a large area for the label but if I add too much text or too large a font, the new label is only partially visible because most is outwith the boundary of the label field. Is there a way to dynamically resize the field customlabel to enlarge to the size of the text? cheers Bob ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
jbv wrote: Nevertheless, how do you explain that the following : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) returns 180 with Rev 2.5 on Mac OS9, but returns 179 on other platforms such as Linux or Win2000 ? Just curious... I was curious about that too. What's the hardware involved in each case ? Are they all the same ? It could be differences in the floating-point hardware (or floating point emulation library). Or it could be difference in the library used by Rev to convert from the text string into fp format (if it chose a different value for the last bit, it would be 180+tiny delta instead of 180-tiny delta (once multiplied by 100) and then the trunc() call would get a different answer. Remember they may *both* be considered correct answers, depending on the binary representation used by different machines / libraries. (Sigh. I don't like it either Jonathan - but after 34 years of computing in a wide variety of languages, I'm getting used to it :-) (I'm hoping that the OS9 machine is an old Motorola based machine, rather than a PPC-based and Intel-based machine, and that I can use that as my answer :-) :-) Though come to think of it, even if it's a modern Mac (i.e. PPC) that may be different enough from the Linux/Win machines you tried. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.13/123 - Release Date: 06/10/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Playing with strings
Hello everybody, I'm curenytly trying to perform a small utility wich would extract the text datas of an html file into separated items or lines of a field. For example, this html code : … strongfont size=1example of texte 1 br a href=#linkbr example of link/a/font/strong … …would return these result in a defined field : example of texte 1 example of link The problem is that it seems impossible to extract something beetween two items (simply beetween the and tags) in a simple way. Do you see any good way to do this ? Thanks for you help, Cordialy Aurélien Durand ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Playing with strings
Easy, create a field, set the htmlText of the field to your html, then get the text of the field. It will strip out the tags for you. best, Chipp Setec Multimedia wrote: Hello everybody, I'm curenytly trying to perform a small utility wich would extract the text datas of an html file into separated items or lines of a field. For example, this html code : … strongfont size=1example of texte 1 br a href=#linkbr example of link/a/font/strong … …would return these result in a defined field : example of texte 1 example of link The problem is that it seems impossible to extract something beetween two items (simply beetween the and tags) in a simple way. Do you see any good way to do this ? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: enlarge field to size of labeltext
I have a button that resizes a label (custonlabel) via 2 fields labelnewname and labelnewtextsize. the script is on mouseUp set the text of field CustomLabel to field LabelNewName set the textsize of field CustomLabel to field LabelNewTextsize end mouseUp I have a large area for the label but if I add too much text or too large a font, the new label is only partially visible because most is outwith the boundary of the label field. Is there a way to dynamically resize the field customlabel to enlarge to the size of the text? set the width of fld CustomLabel to the formattedWidth of fld CustomLabel set the height of fld CustomLabel to the formattedHeight of fld CustomLabel Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: enlarge field to size of labeltext
Quoting Sarah Reichelt [EMAIL PROTECTED]: Hi Sarah Thanks, that is exactly what I wanted. I've left the text quoted below for anyone searchig the archives. Cheers Bob; sunny Scotland (honest) I have a button that resizes a label (custonlabel) via 2 fields labelnewname and labelnewtextsize. the script is on mouseUp set the text of field CustomLabel to field LabelNewName set the textsize of field CustomLabel to field LabelNewTextsize end mouseUp I have a large area for the label but if I add too much text or too large a font, the new label is only partially visible because most is outwith the boundary of the label field. Is there a way to dynamically resize the field customlabel to enlarge to the size of the text? set the width of fld CustomLabel to the formattedWidth of fld CustomLabel set the height of fld CustomLabel to the formattedHeight of fld CustomLabel Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Copy Image
Todd, By all means, send an example along to me. If I can replicate it, I can fix it. I copy images pretty often but have not had any problems with it, but that doesn't mean there isn't a bug in there waiting to be fixed. Best, Jerry On Oct 7, 2005, at 9:23 AM, Todd Geist wrote: Thanks Chip and Sarah for your responses. It seems to be a false alarm. Or at least not a real problem for rev but rather for Constellation... :( I love Constellation. Jerry has done a terrific job. But it seems to be throwing a phantom error here. Or at least switching to using Rev's Object editors removes the error. I am going to see if I can recreate the problem in simple stack pair and send it to Jerry. Thanks Again Todd On 10/6/05 10:47 PM, Sarah Reichelt [EMAIL PROTECTED] wrote: I am trying to copy and image from the current card to a card in a external stack, GrommetData. If the image is already there from a previous copy, I delete it first and then copy it to the card. If the image is already there all works as expected, BUT if the image is not alredy there I get an error after the image is copied. The handler looks like this IF exists (img image of cd tCard of stack GrommetData) THEN delete img image of cd tCard of stack GrommetData END if copy img image to cd tCard of stack GrommetData Hi Todd, I just made a test with a mainStack and a sub-stack called Sub. I imported an image from the image library and tested it with the following button script: on mouseUp if there is an img alerthand.gif of cd 1 of stack Sub then delete img alerthand.gif of cd 1 of stack Sub wait 1 second end if copy img alerthand.gif to cd 1 of stack Sub put the result end mouseUp It all worked perfectly whether Sub had the image already or not. (The wait is only there so that I can see that the original is really deleted). You say the error occurs after the image has been copied. What is the error? What happens next in your script? If you isolate the copying script completely, does it work then? Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution -- Todd Geist __ g e i s t i n t e r a c t i v e ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
On 10/7/05 2:30 PM, jbv [EMAIL PROTECTED] wrote: Nevertheless, how do you explain that the following : put 36 into A put 34.2 into B put A-B into C put C*100 into C put trunc(C) returns 180 with Rev 2.5 on Mac OS9, but returns 179 on other platforms such as Linux or Win2000 ? I don't know about that, but perhaps the docs should say that coercing the number back into a string (by adding ) would make the trunc() function more right. ;-) That is, if you had: put (C*100) into C -- coerces to a string put trunc(C) You should always get 180... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
FWIW: In MS Excel (v.97, on Windows), =TRUNC((36-34.2)*100) gives 180. :-) Curry Kenworthy Curry K. Software http://curryk.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Playing with strings
If you set the HTMLtext of the field to you bit of html, it will generally do a pretty good job of displaying only the text, though it will be formatted according to the html formatting tags. To get around this, you can do set the HTMLText of fld myField to theBitOfHtml put fld myField into fld myField -- effectively resets the the formatted text to whatever font, size and style the field is set to. Mark On 7 Oct 2005, at 21:36, Setec Multimedia wrote: Hello everybody, I'm curenytly trying to perform a small utility wich would extract the text datas of an html file into separated items or lines of a field. For example, this html code : … strongfont size=1example of texte 1 br a href=#linkbr example of link/a/font/strong … …would return these result in a defined field : example of texte 1 example of link The problem is that it seems impossible to extract something beetween two items (simply beetween the and tags) in a simple way. Do you see any good way to do this ? Thanks for you help, Cordialy Aurélien Durand ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Strange math behaviour... could someone explain this ?
Alex Tweedly wrote: Lynch, Jonathan wrote: But still... Answer trunc((36-34.2)*100) should return 180, not 179. No it shouldn't. I mean, the underlying code should work to return an accurate value. It does. Perhaps it is just a matter of opinion, but to me, if the software returns a wrong value in a calculation, it is a bug. It's not a matter of opinion, and it's not a wrong answer - it's a correct answer. The binary double precision representation of 34.2 is inexact, and hence the binary double precision representation of 36-34.2 is similarly inexact - so instead of exactly 180, it's about 1x2**-40 less than that. And then when you use trunc() it does what you ask. It's NOT a Rev bug - it's an artifact of double precision binary arithmetic (or, if you like, an artifact of the IEEE format used by Intel (and everyone else)). One man's artifact is another man's bug. :) The original poster never specified that it was a Rev bug, and you've shown that the anomaly lies outside of Rev. Computers are the servants of humans, not the other way around. In human logic, this: trunc((36-34.2)*100) ...is evaluated in three steps: 1. 36-34.2 = 1.8 2. 1.8 * 100 = 180 3. truncate 180 = 180 Math is a human tool devised for the benefit of humans. Parentheses have a specific meaning which breaks down operations into an explicit order of operations. If a computer system is designed in such a way that it no longer serves its masters faithfully by honoring things like the explicit order of exectution, it's commonly called a bug, and it's usually up to another human to come in an fix it. Whether the fault lies with Rev or the microprocessor, the anwer of 179 is logically incorrect. It may be understandable, but understanding why it's giving an incorrect answer doesn't change the answer. :) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
OT: Eolas Patent Upheld
Though support for an M$ cause is ??able. Their bid to overturn Eolas has been turned down. Could this mean that: go stack URL http://www.example.org/data/mystack.rev; in a new window will be deemed an illegal call? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Copy Image
On 10/7/05 3:32 PM, Jerry Daniels [EMAIL PROTECTED] wrote: Todd, By all means, send an example along to me. If I can replicate it, I can fix it. I copy images pretty often but have not had any problems with it, but that doesn't mean there isn't a bug in there waiting to be fixed. Best, I haven't been able to completely isolate the issue but I did get a work around. My app is processing and saving some Clipboard Contents. A series of handlers does the work GetTheClip -- got the clipboard ParseTheClip -- Parsed some stuff and put the clipboard image in a img on the current card SaveTheClip -- Saved some text and the img to a card on a data stack SaveTheClip worked just fine As did ParseTheClip. But strung together in a parent handler they did not. So I put a wait .05 sec in between them and everything worked. That is as close as I can get. If I get any more info I will pass it on. Thanks Todd -- Todd Geist __ g e i s t i n t e r a c t i v e ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
