Bug Tracking
I've learned over the last few days how important it is to keep track of code changes in each release of an app. I already have a LiveCode app that lets me catalog bugs/enhancements, prioritise them, write notes about how they were fixed and define which release they were fixed in. What's missing is a way to keep a copy of the code base (i.e. the stack files) for each release so I can go back to it later if necessary. My ideal solution would be to simply copy the stack files to a folder for the release and then somehow kick off a build of the standalone application. Copying the files won;t be a problem but is there any way to automate the build of a standalone? It's not a huge deal to do it manually but would be a nice touch to automate it. And the real icing on the cake would be to the equivalent of a diff on the code bases to see what changed between releases. Does anyone else have a bug/version tracking tool they use and like? Thanks, Pete Haworth ___ 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: Bug Tracking
Peter, This was a hot topic some months ago here. There are many alternatives and many users have rolled their own as well. Your first choice is: (a) To use a standard VCS/SCM software such as Git, Mercurial, Darcs, Bazaar, Svn, Fossil... (b) Roll your own If you go with letter (a) then you should notice that LiveCode stacks are binary files and most of these systems are designed to use text files. So while you can still use the versioning system as an archival system, your merge operations will be troublesome since IIRC none of these software is able to do binary merges or unknown file types. I've used Mercurial with LiveCode and am quite happy with dumping binaries into it since I don't do merges, I just want the ability to rollback if needed. If you decide to go with option (b) then you can do pretty much whatever you want. Chipp Walters has a wonderful tool in the form of Magic Carpet. It is available and it served me and Sivaktirswami well on our HTDE project. It is a very good program and for simple needs (no merging, simple archival, no branching) it solves the problem. I know developers here have rolled their own import/export routines to create textual formats of stacks to better use tools such as Git. I haven't gone that far. Andre my two Brazilian Real cents ___ 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: Bug Tracking
Thanks Andre. I guess I've gone down the path of rolling my own so far. I don;t think I need the more exotic features like branching, merging, etc so I think I'll just go ahead and add the logic to copy the necessary files to a version folder when I set up a release. I will check out Magic Carpet as well though! Pete Haworth On Nov 12, 2010, at 10:16 AM, Andre Garzia wrote: Peter, This was a hot topic some months ago here. There are many alternatives and many users have rolled their own as well. Your first choice is: (a) To use a standard VCS/SCM software such as Git, Mercurial, Darcs, Bazaar, Svn, Fossil... (b) Roll your own If you go with letter (a) then you should notice that LiveCode stacks are binary files and most of these systems are designed to use text files. So while you can still use the versioning system as an archival system, your merge operations will be troublesome since IIRC none of these software is able to do binary merges or unknown file types. I've used Mercurial with LiveCode and am quite happy with dumping binaries into it since I don't do merges, I just want the ability to rollback if needed. If you decide to go with option (b) then you can do pretty much whatever you want. Chipp Walters has a wonderful tool in the form of Magic Carpet. It is available and it served me and Sivaktirswami well on our HTDE project. It is a very good program and for simple needs (no merging, simple archival, no branching) it solves the problem. I know developers here have rolled their own import/export routines to create textual formats of stacks to better use tools such as Git. I haven't gone that far. Andre my two Brazilian Real cents ___ 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: Bug Tracking
Chipp - where can I get a copy of Magic Carpet? Pete Haworth On Nov 12, 2010, at 10:16 AM, Andre Garzia wrote: f you decide to go with option (b) then you can do pretty much whatever you want. Chipp Walters has a wonderful tool in the form of Magic Carpet. ___ 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: Bug Tracking
Chipp - where can I get a copy of Magic Carpet? I'm not Chip obviously, but you can find everything you should need here: http://www.altuit.com/webs/altuit2/MagicCarpetCover/default.htm I registered it several years ago and it's a nice product! Best regards, David C. ___ 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: animated gif bug?
I did as you asked. The animated gif I imported into a group I was editing animated just fine while I was in the editing mode. It did not stop animating after I stopped editing. Did you want it to stop animating? I have an entire card of animated gifs that just sit there animating the entire time whether I am editing their group or not. Are they not supposed to? Cheers, Bantymom -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/animated-gif-bug-tp3001301p3001495.html Sent from the Revolution - User mailing list archive at Nabble.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: animated gif bug?
No, I want it to animate. On my stack it doesn't. That's fine. Thanks for the test. I'll keep trying to figure out what's wrong. Thanks! Jeff M. On Tue, Oct 19, 2010 at 1:04 AM, Bantymom banty...@yahoo.com wrote: I did as you asked. The animated gif I imported into a group I was editing animated just fine while I was in the editing mode. It did not stop animating after I stopped editing. Did you want it to stop animating? I have an entire card of animated gifs that just sit there animating the entire time whether I am editing their group or not. Are they not supposed to? Cheers, Bantymom -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/animated-gif-bug-tp3001301p3001495.html Sent from the Revolution - User mailing list archive at Nabble.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 ___ 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: animated gif bug?
On 10/19/10 11:55 AM, Jeff Massung wrote: No, I want it to animate. On my stack it doesn't. That's fine. Thanks for the test. I'll keep trying to figure out what's wrong. Just to chime in here, I have an animated gif in a group and it's working okay too, whether editing or not. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
animated gif bug?
Can someone duplicate this and see if it's just me or a bug? - import an animated gif into your stack - ensure that it does animate just fine in the stack - create a simple group - edit the group - import the animated gif into the group - ensure that it does animate _while editing the group_ - stop editing the group - confirm that the gif stops animating :-( Jeff M. ___ 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: RevBrowser bug
I think at some point the RevBrowser needs to be completely reworked so that the browser is attached not to a window but to an object like a field or a button. Perhaps even a new object called a View Port or something. The way it works now causes all kinds of problems if you try to do anything fancy. Bob On Oct 6, 2010, at 4:04 AM, Klaus on-rev wrote: Hi all, I just filed a bug report for a nasty bug I found today and wanted to let you know. When you toggle the resizable of a stack with an active browser, the content of the browser will disappear in data nirvana :-/ Try it yourself: Open an URL in any browser and toggle the resizable of that stack with a button or the message box, big fun :-/ You will need to close the browser and open a new instance to make it work again. Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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 ___ 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: RevBrowser bug
I'm just curious, I guess... is it only during dev in the IDE that you are toggling the resizable of a stack? Or if you do it at runtime, I'd be curious to find how you're applying this functionality... In my current project I need to toggle this according to some META TAGs inside of the html source. That's what I was looking for... thanks! Ken, I was not born yesterday (LiveCode-wise) :-D Don't I know it! ;-) Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.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: RevBrowser bug
On 10/7/10 9:44 PM, Ken Ray wrote: I'm just curious, I guess... is it only during dev in the IDE that you are toggling the resizable of a stack? Or if you do it at runtime, I'd be curious to find how you're applying this functionality... In my current project I need to toggle this according to some META TAGs inside of the html source. That's what I was looking for... thanks! Ken, I was not born yesterday (LiveCode-wise) :-D Don't I know it! ;-) Very few of us were born yesterday; but when I look at LiveCode / RunRev I wish I had been: then I could have dived straight into LiveCode / RunRev without having to spend Velikovskian Ages in Chaos with FORTRAN, PASCAL, ZILOG and even relatively leverable stuff such as ToolBook. ___ 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
RevBrowser bug
Hi all, I just filed a bug report for a nasty bug I found today and wanted to let you know. When you toggle the resizable of a stack with an active browser, the content of the browser will disappear in data nirvana :-/ Try it yourself: Open an URL in any browser and toggle the resizable of that stack with a button or the message box, big fun :-/ You will need to close the browser and open a new instance to make it work again. Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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: RevBrowser bug
Hi all, Hi all, I just filed a bug report for a nasty bug I found today and wanted to let you know. When you toggle the resizable of a stack with an active browser, the content of the browser will disappear in data nirvana :-/ Try it yourself: Open an URL in any browser and toggle the resizable of that stack with a button or the message box, big fun :-/ You will need to close the browser and open a new instance to make it work again. the same happens when you set the fullscreen of stack xyz to true Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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: RevBrowser bug
This happens because the revbrowser instance is linked to a specific windowid and certain things change that id. As you mentioned changing the resizable, going fullscreen, and if I recall correctly, changing the window decorations all change the windowid. Haven't tried it but changing window mode will probably do this also. This is something that I too hope will be changed/fixed? Though i'm not sure if it should be a bug report or a feature request. Where is your report, i'll vote for it. On Wed, Oct 6, 2010 at 5:20 AM, Klaus on-rev kl...@major.on-rev.com wrote: Hi all, Hi all, I just filed a bug report for a nasty bug I found today and wanted to let you know. When you toggle the resizable of a stack with an active browser, the content of the browser will disappear in data nirvana :-/ Try it yourself: Open an URL in any browser and toggle the resizable of that stack with a button or the message box, big fun :-/ You will need to close the browser and open a new instance to make it work again. the same happens when you set the fullscreen of stack xyz to true Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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 ___ 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: RevBrowser bug
Hi Mike, This happens because the revbrowser instance is linked to a specific windowid and certain things change that id. As you mentioned changing the resizable, going fullscreen, and if I recall correctly, changing the window decorations all change the windowid. Haven't tried it but changing window mode will probably do this also. This is something that I too hope will be changed/fixed? Though i'm not sure if it should be a bug report or a feature request. whatever, I marked it as Blocker A workaround ist to make the stack NOT resizable and use the Mac Style Stack Resizer from the object lib or make your own :-) Where is your report, i'll vote for it. Ah, sorry, here it is: http://quality.runrev.com/qacenter/show_bug.cgi?id=9041 Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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: RevBrowser bug
Done. I've fought with this before. Its a real pain in the butt. Did things like setup the browser stack as a float on top stack that was docked with the stack behind. Then I could do stuff with the back stack and have the front respond. Never did work very well. Ended up doing as you suggested, using the resizer from the library, dumped the stock decorations etc, and since it was a video player window that I wished to be able to go in and out of fullscreen while playing a streaming vid in the browser, I ended up having a 2nd stack that existed for the sole purpose of going into and out of fullscreen behind the browser window to obscure the menu bar and dock. libKiosk worked pretty good for this too. Hoping when/if the externals go public that problems like this will poof and go away. On Wed, Oct 6, 2010 at 6:37 AM, Klaus on-rev kl...@major.on-rev.com wrote: Hi Mike, This happens because the revbrowser instance is linked to a specific windowid and certain things change that id. As you mentioned changing the resizable, going fullscreen, and if I recall correctly, changing the window decorations all change the windowid. Haven't tried it but changing window mode will probably do this also. This is something that I too hope will be changed/fixed? Though i'm not sure if it should be a bug report or a feature request. whatever, I marked it as Blocker A workaround ist to make the stack NOT resizable and use the Mac Style Stack Resizer from the object lib or make your own :-) Where is your report, i'll vote for it. Ah, sorry, here it is: http://quality.runrev.com/qacenter/show_bug.cgi?id=9041 Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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 ___ 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: RevBrowser bug
can someone confirm this is a regression? Did it happen in 4.0 or 3.x ? On Wed, Oct 6, 2010 at 9:58 AM, Mike Bonner bonnm...@gmail.com wrote: Done. I've fought with this before. Its a real pain in the butt. Did things like setup the browser stack as a float on top stack that was docked with the stack behind. Then I could do stuff with the back stack and have the front respond. Never did work very well. Ended up doing as you suggested, using the resizer from the library, dumped the stock decorations etc, and since it was a video player window that I wished to be able to go in and out of fullscreen while playing a streaming vid in the browser, I ended up having a 2nd stack that existed for the sole purpose of going into and out of fullscreen behind the browser window to obscure the menu bar and dock. libKiosk worked pretty good for this too. Hoping when/if the externals go public that problems like this will poof and go away. On Wed, Oct 6, 2010 at 6:37 AM, Klaus on-rev kl...@major.on-rev.com wrote: Hi Mike, This happens because the revbrowser instance is linked to a specific windowid and certain things change that id. As you mentioned changing the resizable, going fullscreen, and if I recall correctly, changing the window decorations all change the windowid. Haven't tried it but changing window mode will probably do this also. This is something that I too hope will be changed/fixed? Though i'm not sure if it should be a bug report or a feature request. whatever, I marked it as Blocker A workaround ist to make the stack NOT resizable and use the Mac Style Stack Resizer from the object lib or make your own :-) Where is your report, i'll vote for it. Ah, sorry, here it is: http://quality.runrev.com/qacenter/show_bug.cgi?id=9041 Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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 ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: RevBrowser bug
Hi Andre, can someone confirm this is a regression? Did it happen in 4.0 or 3.x ? I also tested this on Rev 3.4 and 4.0, same problem. Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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: RevBrowser bug
On 10/6/10 9:58 AM, Klaus on-rev kl...@major.on-rev.com wrote: Hi Andre, can someone confirm this is a regression? Did it happen in 4.0 or 3.x ? I also tested this on Rev 3.4 and 4.0, same problem. But isn't this just when you turn the resizable of a stack on and off? I mean if the stack is meant to be resizable, wouldn't you just leave it resizable? I have several resizable revBrowser stacks with no problems (at least, not as far as resizing goes :-)... I'm just curious, I guess... is it only during dev in the IDE that you are toggling the resizable of a stack? Or if you do it at runtime, I'd be curious to find how you're applying this functionality... Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.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: RevBrowser bug
Hi Ken, On 10/6/10 9:58 AM, Klaus on-rev kl...@major.on-rev.com wrote: Hi Andre, can someone confirm this is a regression? Did it happen in 4.0 or 3.x ? I also tested this on Rev 3.4 and 4.0, same problem. But isn't this just when you turn the resizable of a stack on and off? Yep and if I toggle the fullscreen of stack xyz. I mean if the stack is meant to be resizable, wouldn't you just leave it resizable? I have several resizable revBrowser stacks with no problems (at least, not as far as resizing goes :-)... I'm just curious, I guess... is it only during dev in the IDE that you are toggling the resizable of a stack? Or if you do it at runtime, I'd be curious to find how you're applying this functionality... In my current project I need to toggle this according to some META TAGs inside of the html source. Ken, I was not born yesterday (LiveCode-wise) :-D Ken Ray Sons of Thunder Software, Inc. Email: k...@sonsothunder.com Web Site: http://www.sonsothunder.com/ Best Klaus -- Klaus Major http://www.major-k.de kl...@major.on-rev.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: Open printing to PDF bug?
Hi everyone, Thanks for the replies. Indeed it seems that Printmargins and PrintScale affect the cuttoff of text and images. Thats a pity because I want to increase text and images by setting the PrintScale to to 1.1. It looks as if Printscale doesn't work with images and with 'printing to PDF' and printPaperOrientation 'Landscape'. And I was so happy when they announced 'printing to PDF'!!! greetings, William 2010/9/24 JosepM jmye...@mac.com: This work for me, without change the exact size of the elements, but l lost about 2 cm at the bottom of the page. I need to force the stack size and move to some position that I can edit later, so if I use it in my laptop the stack is resized and when I print the PDF only show the visible area of the stack. The idea is make this stack invisible. Put the margin to 0 left about 2 cm at top and at bottom, left and right are about 1cm... on mouseUp set the location of this stack to 600,600 set the width of this stack to 595 set the height of this stack to 842 set the printPaperSize to 595,842 put 595,842 into thePaperSize put 0 into theMargin -- get the page area: set the printMargins to theMargin,theMargin,theMargin,theMargin -- put theMargin,theMargin, item 1 of thePaperSize - theMargin, item 2 of thePaperSize - theMargin into destinationRect -- print into that rectangle: open printing to pdf /Users/joss/Desktop/card_test.pdf print this card --into destinationRect close printing end mouseUp Salut, Josep -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-printing-to-PDF-bug-tp2550663p2552864.html Sent from the Revolution - User mailing list archive at Nabble.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 ___ 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: Open printing to PDF bug?
A workaround might be to take a picture of the region, put that on another card, rotate that, and print from that card. -- Dar On Sep 25, 2010, at 5:59 AM, William de Smet wrote: Hi everyone, Thanks for the replies. Indeed it seems that Printmargins and PrintScale affect the cuttoff of text and images. Thats a pity because I want to increase text and images by setting the PrintScale to to 1.1. It looks as if Printscale doesn't work with images and with 'printing to PDF' and printPaperOrientation 'Landscape'. And I was so happy when they announced 'printing to PDF'!!! greetings, William 2010/9/24 JosepM jmye...@mac.com: This work for me, without change the exact size of the elements, but l lost about 2 cm at the bottom of the page. I need to force the stack size and move to some position that I can edit later, so if I use it in my laptop the stack is resized and when I print the PDF only show the visible area of the stack. The idea is make this stack invisible. Put the margin to 0 left about 2 cm at top and at bottom, left and right are about 1cm... on mouseUp set the location of this stack to 600,600 set the width of this stack to 595 set the height of this stack to 842 set the printPaperSize to 595,842 put 595,842 into thePaperSize put 0 into theMargin -- get the page area: set the printMargins to theMargin,theMargin,theMargin,theMargin -- put theMargin,theMargin, item 1 of thePaperSize - theMargin, item 2 of thePaperSize - theMargin into destinationRect -- print into that rectangle: open printing to pdf /Users/joss/Desktop/card_test.pdf print this card --into destinationRect close printing end mouseUp Salut, Josep -- View this message in context: http://runtime-revolution. 278305.n4.nabble.com/Open-printing-to-PDF-bug-tp2550663p2552864.html Sent from the Revolution - User mailing list archive at Nabble.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 ___ 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: Open printing to PDF bug?
On 9/25/10 6:59 AM, William de Smet wrote: Hi everyone, Thanks for the replies. Indeed it seems that Printmargins and PrintScale affect the cuttoff of text and images. Thats a pity because I want to increase text and images by setting the PrintScale to to 1.1. It looks as if Printscale doesn't work with images and with 'printing to PDF' and printPaperOrientation 'Landscape'. And I was so happy when they announced 'printing to PDF'!!! Bug report it, there may be something RR can do. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Open printing to PDF bug?
I have seen the page cutoff problem with landscape (but not the other concerns), so if William doesn't report it, I'm willing to report that much. -- Dar On Sep 25, 2010, at 11:06 AM, J. Landman Gay wrote: On 9/25/10 6:59 AM, William de Smet wrote: Hi everyone, Thanks for the replies. Indeed it seems that Printmargins and PrintScale affect the cuttoff of text and images. Thats a pity because I want to increase text and images by setting the PrintScale to to 1.1. It looks as if Printscale doesn't work with images and with 'printing to PDF' and printPaperOrientation 'Landscape'. And I was so happy when they announced 'printing to PDF'!!! Bug report it, there may be something RR can do. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 ___ 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: Open printing to PDF bug?
Hi there, I will report it in the next coming days but I think you need to do it aswell Dar. The more the better! Greetings, William - Verstuurd vanaf mijn iPhone! Op 25 sep. 2010 om 19:32 heeft Dar Scott d...@swcp.com het volgende geschreven: I have seen the page cutoff problem with landscape (but not the other concerns), so if William doesn't report it, I'm willing to report that much. -- Dar On Sep 25, 2010, at 11:06 AM, J. Landman Gay wrote: On 9/25/10 6:59 AM, William de Smet wrote: Hi everyone, Thanks for the replies. Indeed it seems that Printmargins and PrintScale affect the cuttoff of text and images. Thats a pity because I want to increase text and images by setting the PrintScale to to 1.1. It looks as if Printscale doesn't work with images and with 'printing to PDF' and printPaperOrientation 'Landscape'. And I was so happy when they announced 'printing to PDF'!!! Bug report it, there may be something RR can do. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 ___ 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: Open printing to PDF bug?
Bug reports should be crisp and address a particular bug. One can add details to a existing bug report or suggest changes in parts. Additional reports for the same bug should not be made. Often though, it is only after the fact that it is clear that two bugs are the same. Fortunately, it is possible for the bug wranglers to mark a bug as a duplicate of another. I think there are changes coming in the reporting of bugs, so that may not exactly apply. Dar On Sep 25, 2010, at 11:51 AM, William de Smet wrote: Hi there, I will report it in the next coming days but I think you need to do it aswell Dar. The more the better! Greetings, William - Verstuurd vanaf mijn iPhone! Op 25 sep. 2010 om 19:32 heeft Dar Scott d...@swcp.com het volgende geschreven: I have seen the page cutoff problem with landscape (but not the other concerns), so if William doesn't report it, I'm willing to report that much. -- Dar On Sep 25, 2010, at 11:06 AM, J. Landman Gay wrote: On 9/25/10 6:59 AM, William de Smet wrote: Hi everyone, Thanks for the replies. Indeed it seems that Printmargins and PrintScale affect the cuttoff of text and images. Thats a pity because I want to increase text and images by setting the PrintScale to to 1.1. It looks as if Printscale doesn't work with images and with 'printing to PDF' and printPaperOrientation 'Landscape'. And I was so happy when they announced 'printing to PDF'!!! Bug report it, there may be something RR can do. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 ___ 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: Open printing to PDF bug?
On 9/22/10 11:09 PM, Dar Scott wrote: William, I tried this: on mouseUp reset printing set the printPaperSize to 595,842 set the printPaperOrientation to landscape set the printmargins to 72,36,0,0 set the printscale to 1.1 open printing to pdf test.pdf -- add error check here print this card from 193,90 to 833,570 -- add error check here close printing end mouseUp And I get the right part of my images, rectangles and fields cut off. It cuts off at the unrotated paper width. This works for me: set the printpapersize to 595,842 set the printPaperOrientation to landscape set the printmargins to 18,18,18,18 set the printScale to 0.85 open printing to pdf test.pdf print this card from the topleft of fld 1 to the bottomright of fld 1 close printing I got the cutoff until I scaled the printout down to 0.85; this likely needs to be adjusted for each layout. The printmargins will also play a role in how much it needs to be scaled. If the scaling is too large, then it prints right off the edge of the page. If William's original intention is to make the text larger for the printout, then probably I'd increase the textsize of the field before printing, then change it back afterward. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Open printing to PDF bug?
This work for me, without change the exact size of the elements, but l lost about 2 cm at the bottom of the page. I need to force the stack size and move to some position that I can edit later, so if I use it in my laptop the stack is resized and when I print the PDF only show the visible area of the stack. The idea is make this stack invisible. Put the margin to 0 left about 2 cm at top and at bottom, left and right are about 1cm... on mouseUp set the location of this stack to 600,600 set the width of this stack to 595 set the height of this stack to 842 set the printPaperSize to 595,842 put 595,842 into thePaperSize put 0 into theMargin -- get the page area: set the printMargins to theMargin,theMargin,theMargin,theMargin -- put theMargin,theMargin, item 1 of thePaperSize - theMargin, item 2 of thePaperSize - theMargin into destinationRect -- print into that rectangle: open printing to pdf /Users/joss/Desktop/card_test.pdf print this card --into destinationRect close printing end mouseUp Salut, Josep -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-printing-to-PDF-bug-tp2550663p2552864.html Sent from the Revolution - User mailing list archive at Nabble.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
Open printing to PDF bug?
Hi there, It seems I have the same problem! I use almost the same code as Joseph (asked earlier today) to print on A4 paper. When I want a PDF preview on OSX everything is/looks fine. When using the code below and adding 'open printing to PDF' about 1/4 of the printed text is cut off. Is this a bug or are we doing something wrong? --- open printing to pdf test.pdf set the printRotated to true set the printMargins to 72,36,72,36 set the printScale to 1.1 print this card from 193,90 to 833,570 close printing --- greetings, William ___ 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: Open printing to PDF bug?
On 9/22/10 11:44 AM, William de Smet wrote: Hi there, It seems I have the same problem! I use almost the same code as Joseph (asked earlier today) to print on A4 paper. When I want a PDF preview on OSX everything is/looks fine. When using the code below and adding 'open printing to PDF' about 1/4 of the printed text is cut off. Is this a bug or are we doing something wrong? --- open printing to pdf test.pdf set the printRotated to true set the printMargins to 72,36,72,36 set the printScale to 1.1 print this card from 193,90 to 833,570 close printing --- One thing I just found out is that PDF printing will cut off text and ruin the layout if you have formatForPrinting set to true on Windows. It is the one time you do not want to use that property for printing text. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Open printing to PDF bug?
Hi Jacqueline, Thanks for your reaction. I just tested with an image and the same thing happens. I never set formatForPrinting. Anyone else? groeten, William 2010/9/22 J. Landman Gay jac...@hyperactivesw.com: On 9/22/10 11:44 AM, William de Smet wrote: Hi there, It seems I have the same problem! I use almost the same code as Joseph (asked earlier today) to print on A4 paper. When I want a PDF preview on OSX everything is/looks fine. When using the code below and adding 'open printing to PDF' about 1/4 of the printed text is cut off. Is this a bug or are we doing something wrong? --- open printing to pdf test.pdf set the printRotated to true set the printMargins to 72,36,72,36 set the printScale to 1.1 print this card from 193,90 to 833,570 close printing --- One thing I just found out is that PDF printing will cut off text and ruin the layout if you have formatForPrinting set to true on Windows. It is the one time you do not want to use that property for printing text. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 ___ 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: Open printing to PDF bug?
Hi folks, My tests... put 595,842 into thePaperSize put 20 into theMargin -- get the page area: set the printMargins to theMargin,theMargin,theMargin,theMargin put theMargin,theMargin, item 1 of thePaperSize - theMargin, item 2 of thePaperSize - theMargin into destinationRect -- print into that rectangle: open printing to pdf /Users/joss/Desktop/card_test.pdf print this card into destinationRect close printing With 20 into the margin is the best aproximation, some graphics inside are a little small, so I print for a card game, and I need that the card have the exact size. If I down the margin I get the real size but the bottom is cutted. Any idea? Salut, Josep -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-printing-to-PDF-bug-tp2550663p2550844.html Sent from the Revolution - User mailing list archive at Nabble.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: Open printing to PDF bug?
Now I see that in relation to the width and height of the stack the PDF change the width and the height... :( -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-printing-to-PDF-bug-tp2550663p2550927.html Sent from the Revolution - User mailing list archive at Nabble.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: Open printing to PDF bug?
Any help? :) -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-printing-to-PDF-bug-tp2550663p2551168.html Sent from the Revolution - User mailing list archive at Nabble.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: Open printing to PDF bug?
I set parameters for the entire print batch before open printing to pdf. Am I doing that wrong? Try setting up for A4: set the printPaperSize to 595,842 Try printPaperOrientation instead of printRotated. If those don't work, try putting margins and printscale before the batch. I'm guessing. Mine works but I'm not using landscape. And I use full-page printing. Dar Scott On Sep 22, 2010, at 10:44 AM, William de Smet wrote: Hi there, It seems I have the same problem! I use almost the same code as Joseph (asked earlier today) to print on A4 paper. When I want a PDF preview on OSX everything is/looks fine. When using the code below and adding 'open printing to PDF' about 1/4 of the printed text is cut off. Is this a bug or are we doing something wrong? --- open printing to pdf test.pdf set the printRotated to true set the printMargins to 72,36,72,36 set the printScale to 1.1 print this card from 193,90 to 833,570 close printing --- greetings, William ___ 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: Open printing to PDF bug?
William, I tried this: on mouseUp reset printing set the printPaperSize to 595,842 set the printPaperOrientation to landscape set the printmargins to 72,36,0,0 set the printscale to 1.1 open printing to pdf test.pdf -- add error check here print this card from 193,90 to 833,570 -- add error check here close printing end mouseUp And I get the right part of my images, rectangles and fields cut off. It cuts off at the unrotated paper width. It looks like it scaled right, but it has the cutoff. I tried setting the rotated paper size after setting orientation, but it is the same. I think with some other fiddling, parts showed up but not all. I'm not an expert at all the printing parameters, but it seems to me you are right. It seems there is a bug. Maybe somebody with more printing experience can say. Dar Scott On Sep 22, 2010, at 10:44 AM, William de Smet wrote: Hi there, It seems I have the same problem! I use almost the same code as Joseph (asked earlier today) to print on A4 paper. When I want a PDF preview on OSX everything is/looks fine. When using the code below and adding 'open printing to PDF' about 1/4 of the printed text is cut off. Is this a bug or are we doing something wrong? --- open printing to pdf test.pdf set the printRotated to true set the printMargins to 72,36,72,36 set the printScale to 1.1 print this card from 193,90 to 833,570 close printing --- greetings, William ___ 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: Harry Potter's magic button - a solution to another tricky group bug
Wilhelm Sanke wrote: On August 7 you wrote: Yeah, the boundingRect property been a godsend on some projects, and I was quite pleased when Raney added it. Makes short work of things that can get quite complicated without it. Could you possibly provide us - the revolution users - with more details and examples, why the boundingrect is a godsend and and how it simplifies things that otherwise remain complicated?- Looks like you did a good job of it here: Of course, the boundingrect is one of the solutions to the set the loc of objects in a group problem, identical (in that) to the effect of the magic button, and very similar to the effect of Jacqueline's proposal to switch off the scrollbars of a group if the image is smaller than the group. The only difference when focusing on this bug - as it were on the surface, but not only - is that with the boundingsrect scrollbars are tolerated with smaller images whereas with Jacqueline's proposal you have to turn the scrollbars off. I think you've hit on the most complex aspects of it. My own work must be pretty simple since that sort of complexity is stuff I never come across. In my simple view, groups are dynamic, in the sense that they automatically adjust to fit the controls within them. On this, one man's dynamic may be another man's squirrelly, depending on various combinations of what you're trying to do, how much time you have to poke around trying, and how much coffee you had when you started out. For me, the boundingRect makes things ultra-simple when what I want is a sort of canvas, a scrollable area of a fixed size which may represent a page or other construct of fixed size. For other uses the default squirrelly mode is actually kinda great to me, as I can adjust the controls in my layout and the group resizes along with 'em. But for fixed-size things like representations of a printed page, you can think of using the boundingRect as being like adding a rectangle graphic to the group to define the scroll region, except you don't need to add anything. Hope that helps a bit, but if it doesn't that may explain why I don't write Rev's docs. :) My advice on such things is usually to just play with properties in some new stack you don't care about to learn about them. Reading can help you learn the syntax, but to really understand so many things nothing beats doing. And exploring in a fresh stack means you can play freely without having to worry if you'll mess something up in a stack that actually matters. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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: Harry Potter's magic button - a solution to another tricky group bug
On Sat Aug 7, 2010, Richard Gaskin ambassador at fourthworld.com wrote: For the main dictionary entry, use the Documentation specifier when filing the request in the RQCC. If the boundingrect of a group is such a powerful property I wonder why the default for groups isn't boundingrect not empty and is automatically set to the coordinates when a group is created or resized ? It depends what you want to do with the group.. Altering that behavior with the boundingRect is useful for making canvas-like regions, but if you're not after a canvas you may prefer the default behavior. Richard, I think *you* are the most competent person to re-write the boundingrect entry of the Dictionary and to specify the details more accurately and understandably, after all, as you mentioned, it was you who requested such a feature from Scott Raney. And this was probably one of the last additions Scott Raney made to the MetaTalk language, as the boundingrect did not find its way into the Help index of the Metacard IDE as we still use it today. On August 6 you wrote: But some time ago I needed more canvas-like behaviors, and Scott Raney accommodated me by adding the boundingRect property for groups. Similar to SuperCard's backSize property, the boundingRect lets you define a rect for the scrollable area of a group regardless of its contents. Question: Can we not achieve the same effect for a fixed scrollable area when we simply set the rect, i.e. not the boundingrect, and the locLocation to true? What is the difference for a scrollable area when you use boundingrect instead? On August 7 you wrote: Yeah, the boundingRect property been a godsend on some projects, and I was quite pleased when Raney added it. Makes short work of things that can get quite complicated without it. Could you possibly provide us - the revolution users - with more details and examples, why the boundingrect is a godsend and and how it simplifies things that otherwise remain complicated?- Of course, the boundingrect is one of the solutions to the set the loc of objects in a group problem, identical (in that) to the effect of the magic button, and very similar to the effect of Jacqueline's proposal to switch off the scrollbars of a group if the image is smaller than the group. The only difference when focusing on this bug - as it were on the surface, but not only - is that with the boundingsrect scrollbars are tolerated with smaller images whereas with Jacqueline's proposal you have to turn the scrollbars off. If would be surely very nice of you and helpful for Revolution users if you would tell us more about the other features coming with the boundingrect property that provide canvas-like behaviors and simplify otherwise complicated things. Thanks very much in advance. Wilhelm Sanke http://www.sanke.org/MetaMedia ___ 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: Harry Potter's magic button - a solution to another tricky group bug
On Fri Aug 6, 2010, Richard Gaskin ambassador at fourthworld.com Wilhelm Sanke wrote: Actually, there are at least two bugs: The problem of setting the loc and that of keeping the loc - although the lockloc of the image is set to true. Lockloc in the context of the definition above is also broken. After having succesfully centered the image, it will - as reported - revert to a topleft position in the group Yes, with the default dynamic behavior of groups this is what most folks will experience. But some time ago I needed more canvas-like behaviors, and Scott Raney accommodated me by adding the boundingRect property for groups. Similar to SuperCard's backSize property, the boundingRect lets you define a rect for the scrollable area of a group regardless of its contents. -- Richard Gaskin Richard, Thanks for this really valuable information. set the boundingrect of group x to the rect of group x solves the complete list of problems, the setting and keeping bugs are no longer interfering and all side effects have gone away - like with the magic button, but with even less effort. They must be a great amount of similarities between what the boundingrect and the magic button achieve, and if the Rev engineers will still try to fix the set the loc bug they should also look how the boundingrect is coded in the engine. The Revolution docs/dictionary should be updated to reflect the dependency of set the loc in groups on the boundingrect property. Regards and many thanks, Wilhelm ___ 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: Harry Potter's magic button - a solution to another tricky group bug
Wilhelm Sanke wrote: Richard, Thanks for this really valuable information. set the boundingrect of group x to the rect of group x solves the complete list of problems, the setting and keeping bugs are no longer interfering and all side effects have gone away - like with the magic button, but with even less effort. Yeah, the boundingRect property been a godsend on some projects, and I was quite pleased when Raney added it. Makes short work of things that can get quite complicated without it. As much as I enjoy using Rev, there are a few things I miss from when when I was using SuperCard daily; this was one of them. They must be a great amount of similarities between what the boundingrect and the magic button achieve, and if the Rev engineers will still try to fix the set the loc bug they should also look how the boundingrect is coded in the engine. I think I missed that bug - what's the RQCC#? The Revolution docs/dictionary should be updated to reflect the dependency of set the loc in groups on the boundingrect property. Good idea - I've just added this note to the Dictionary entry for the location property: If you encounter difficulties setting the loc of objects within a group, see the boundingRect group property in this dictionary. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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: Harry Potter's magic button - a solution to another tricky group bug
On Sat Aug 7, 2010, Richard Gaskin ambassador at fourthworld.com wrote Wilhelm Sanke wrote: Richard, Thanks for this really valuable information. set the boundingrect of group x to the rect of group x solves the complete list of problems, the setting and keeping bugs are no longer interfering and all side effects have gone away - like with the magic button, but with even less effort. Yeah, the boundingRect property been a godsend on some projects, and I was quite pleased when Raney added it. Makes short work of things that can get quite complicated without it. As much as I enjoy using Rev, there are a few things I miss from when when I was using SuperCard daily; this was one of them. They must be a great amount of similarities between what the boundingrect and the magic button achieve, and if the Rev engineers will still try to fix the set the loc bug they should also look how the boundingrect is coded in the engine. I think I missed that bug - what's the RQCC# The first post of this thread of August 3 was intended to be a first draft of the report. I did not yet submit the report as I wanted to see and possibly include relevant feedback from the list, which seems to be justified now. The Revolution docs/dictionary should be updated to reflect the dependency of set the loc in groups on the boundingrect property. Good idea - I've just added this note to the Dictionary entry for the location property: If you encounter difficulties setting the loc of objects within a group, see the boundingRect group property in this dictionary. -- Richard Gaskin I took a look at the comments in the Dictionary: Here are the comments: Use the boundingRect property to control how a group responds when you move one of the group's controls to the edge of the group. Value: The boundingRect of a group consists of four integers separated by commas. By default, the boundingRect property of a group is set to empty. Comments: If a group's boundingRect is empty and its lockLocation is false, when you drag an object toward the boundary of the group, the group automatically expands, resizing itself to fit. If the lockLocation is true, the object is clipped to the group's rectangle. If a group's boundingRect is not empty and its lockLocation is false, when you drag an object toward the boundary of the group, the group does not automatically resize to fit its objects. Instead, the object is clipped at the boundingRect. (In group-editing mode, the entire control is shown, but when you exit group-editing mode, controls outside the boundingRect are clipped.) If the group is a scrolling group, dragging an object in it automatically scrolls the group. When you drag beyond the scrollable area, the object is clipped. Some remarks to these comments: I doubt that a user could see any indication of the problem of setting and keeping the loc in groups in these comments. Setting the loc of an object is not mentioned. There seems to be no difference between boundingrect empty and locLocation true and boundingrect not empty and lockLocation false, the option of boundingrect not empty and lockLocaction true, which would describe the properties of the group as I use it now, is absent in the comments. I could *not* verify the last sentence of the comments: If the group is a scrolling group, dragging an object in it automatically scrolls the group. I think this entry for boundingrect in the docs needs to be updated, too. And I also recommend to change the note for entry location to If you want to set the loc of an object inside a group reliably, set the boundingrect of the group to the rect of the group.- If the boundingrect of a group is such a powerful property I wonder why the default for groups isn't boundingrect not empty and is automatically set to the coordinates when a group is created or resized ? I will test which of the other bugs in my substantial collection of group bugs is positively affected by using the boundingrect property. Regards, Wilhelm Sanke ___ 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: Bug management systems
On 07/08/2010 14:56, wayne durden wrote: Given that almost all will indeed have excessive features, it seems like this might be a good use case for Rev and eating one's own dogfood. Admittedly any prebuilt system has an enormous amount of man hours already in it, but it doesn't seem like a bug report system needs to start with more than 15 or so fields and Rev is ideal for incrementally adding a feature such as a new report type as the need arises... It has bugged me a little in that if Rev is so ideal for some of these things, why isn't the maillist, bug syetem etc. done in Rev? It sent mixed messages to me at least to get a Python or PHP based list signup, etc. Now I fully understand the rationale, each of these things is proven and has a ton of manhours already invested in discovering the gotchas that crop up as time passes, but still, it generates a mixed message when juxtaposed against the main selling claims related to Rev. I'd really hate RunRev to waste resources doing this. If they were to write their own bug tracking system, mailing list etc, then I'd certainly expect them to consider using their own dog food (but possibly decide to use something else); but unless there's really nothing available that's good enough, they should focus on their core job of improving and selling the product, not distract themselves by building from scratch what can be economically purchased. As a programmer, with a load of programmer colleagues, it's taken me years to learn to resist the urge to roll our own. Gradually we've replaced the internally developed intranet calendar, the internally developed bug tracker, the internally developed CRM system and many other pieces, with products or OSS. Each move was a step in the right direction in focusing on what we could do for our clients. Frankly products are probably a better move than OSS in this respect; for the equivalent of perhaps half a day's rates, we get the product of months of work by someone else's developers, with someone else to do support and fix bugs; the inability to change the odd aspects that we don't like are probably outweighed by the inability to waste staff time fixing those aspects. I cry when I recall that in the infancy of our company we kept our accounts using a system written by our MD in Prolog! Ben ___ 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: Harry Potter's magic button - a solution to another tricky group bug
Wilhelm Sanke wrote: There seems to be no difference between boundingrect empty and locLocation true and boundingrect not empty and lockLocation false, the option of boundingrect not empty and lockLocaction true, which would describe the properties of the group as I use it now, is absent in the comments. I could *not* verify the last sentence of the comments: If the group is a scrolling group, dragging an object in it automatically scrolls the group. I think this entry for boundingrect in the docs needs to be updated, too. And I also recommend to change the note for entry location to If you want to set the loc of an object inside a group reliably, set the boundingrect of the group to the rect of the group.- The Comments section is open to you as a way to provide the information you feel is useful immediately. For the main dictionary entry, use the Documentation specifier when filing the request in the RQCC. If the boundingrect of a group is such a powerful property I wonder why the default for groups isn't boundingrect not empty and is automatically set to the coordinates when a group is created or resized ? It depends what you want to do with the group. Groups are very dynamic by default, adjusting themselves for whatever contents are inside of them. Altering that behavior with the boundingRect is useful for making canvas-like regions, but if you're not after a canvas you may prefer the default behavior. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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: Harry Potter's magic button - a solution to another tricky group bug
I need to rephrase the bug definition after Jacqueline has found out about the effect of the group scrollbars: If an image is smaller than the dimensions of a group and the vscrollbar and the hscrollbar are set to true, then you cannot set the loc of the image to the loc of the group or reliably to any other x,y coordinates. Actually, there are at least two bugs: The problem of setting the loc and that of keeping the loc - although the lockloc of the image is set to true. Lockloc in the context of the definition above is also broken. After having succesfully centered the image, it will - as reported - revert to a topleft position in the group - when you go to another card and then navigate back - when you set the imagedata - when you import a new image - when you toggle the scrollbars back to true - when you close the stack (even after having saved it again) and then reopen it. Until these bug will have been fixed, this leaves us with three options for workarounds for the time being: 1. Use the magic button This seems to be indeed the simplest solution as it works under all conditions and also with and without scrollbars - and you set the necessary properties only once. As you know from my report (the first post of this thread) the button has to be visible in the sense that the vis of the button must be true. If you really hide it - with hide or set the vis to false - the effect is lost. Another prerequisite is that the button is placed at the topleft corner of the group. But you can make the button invisible to the eye of the user by setting - the showname, showborder, show hilite etc. to false - the ink of its color to noop - the layer of the button in the group to the lowest. Additionally you could comment out the script of the button or put empty into it to prevent the button being accidentally dragged somewhere because of the grab me script in my sample stack. You could also make the button very small; size does not matter to achieve the effect. Why the magic button works at all is still a mystery to me. 2. Toggle the hscrollbar and the vscrollbar on and off In my configuration of the image-processing stack I needed the scrollbars for images that are larger than the group. In this case of a larger image set the loc of image x works fine with visible scrollbars. You would have to check - when importing an image or retrieving an image stored inside the stack - what the size of the image is , and set the scrollbars accordingly. That would mean to add appropriate script lines to each handler in the stack that imports images or sets images from inside the stack. There is one difficulty here as the size of the image has to be larger in both dimensions - horizontally and vertically - for the set command to work properly with scrollbars turned on, .e.g. meaning that if the image is higher than the group and the scrollbars are on you cannot set the loc accurately: the y-part of the loc will be set accurately, but the image will snap to the left side of the group - Of course - as a different configuration of an image-processing stack - one could dispense with scrollbars altogether, and let the user drag the image around with a grab me script. 3. Use move to instead of set the loc This workaround is the least comfortable. Although move image x to x,y or to the loc of group y ( if you add in 1 millisecond) it will set the image at once and reliably to the intended place, you have then to cope with the problem of keeping the image at its loc - see the conditions listed above. You would need to add the scriptline move to... in quite a number of handlers, in the preopenstack handler of the card, in each filter script that adresses imagedata - there may be hundreds of such filters in an image-processing stack -, in the import image handler and elsewhere. By the way, the effect involving imagedata is not because imagedata are changed in any way, but because they are set. Set the imagedata of img x to the imagedata of img x will also cause to place the image in the topleft corner of the group.-- Some deliberations for the Revolution engineers that will try to fix these bugs: The first places to look for would probably be the codes in the engine for the set loc and move to commands. There must be a distinctive difference in the move to code that overrules the effects caused by a smaller image in a group and the influence of turned on group scrollbars Another approach.might be to analyse the internal differences between the variants of the two-step effects triggered when you set the loc or set the imagedata. With set the loc after the first step - using the command once - only that portion of the image will be displayed that is identical to the overlapping parts of the image set to the topleft corner of the group and the area the image would have occupied when it would have been really centered. Only after applying set the loc
Re: Harry Potter's magic button - a solution to another tricky group bug
Wilhelm Sanke wrote: Actually, there are at least two bugs: The problem of setting the loc and that of keeping the loc - although the lockloc of the image is set to true. Lockloc in the context of the definition above is also broken. After having succesfully centered the image, it will - as reported - revert to a topleft position in the group Yes, with the default dynamic behavior of groups this is what most folks will experience. But some time ago I needed more canvas-like behaviors, and Scott Raney accommodated me by adding the boundingRect property for groups. Similar to SuperCard's backSize property, the boundingRect lets you define a rect for the scrollable area of a group regardless of its contents. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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: Harry Potter's magic button - a solution to another tricky group bug
On 8/6/10 12:01 PM, Wilhelm Sanke wrote: I need to rephrase the bug definition after Jacqueline has found out about the effect of the group scrollbars: If an image is smaller than the dimensions of a group and the vscrollbar and the hscrollbar are set to true, then you cannot set the loc of the image to the loc of the group or reliably to any other x,y coordinates. Actually, there are at least two bugs: The problem of setting the loc and that of keeping the loc - although the lockloc of the image is set to true. Lockloc in the context of the definition above is also broken. After having succesfully centered the image, it will - as reported - revert to a topleft position in the group - when you go to another card and then navigate back - when you set the imagedata - when you import a new image - when you toggle the scrollbars back to true - when you close the stack (even after having saved it again) and then reopen it. (snipping rest) All these, plus other issues you describe in the rest of the message, boil down to the same thing: the loc of the image isn't applied correctly whenever the group (or card, perhaps) is redrawn. Everything in the above list redraws at least part of the card. Even just moving the image causes a redraw. When I did my brief tests it looked like the set command ignored the requested location, even if I stored it in a variable first: get the loc of grp imagegroup -- this was identified correctly set the loc of img eins to it -- didn't work This only failed when the group had scrollbars. So I think setting and keeping the requested location are really the same problem, and fixing one will likely fix the other. I think you can probably revise the bug report with that info and it will be enough for the team to identify the issue, especially if you upload your example stack which makes the problem quite clear. To work around it, I altered your button script to open images this way: on mouseUp answer file Choose image -- with filter *.jpg;*.png if it is empty then exit to top else put it into tfile put binfile: before tfile set the lockloc of img eins to false lock screen put URL tfile into img eins set the lockloc of img eins to true -- changes start here: put (the width of img eins the width of group imagegroup \ or the height of img eins the height of \ group imagegroup) into tIsLarge set the hscrollbar of group imagegroup to tIsLarge set the vscrollbar of group imagegroup to tIsLarge unlock screen end if end mouseUp BTW, I had to comment out the with filter which doesn't apply on Macs. If you will be distributing this cross platform, use with type instead. Since you only have to work around the problem when the image is opened or reset, you shouldn't need to add anything else to other handlers. Leave the scrollbars alone except when changing or importing an image. This worked in your sample stack. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Harry Potter's magic button - a solution to another tricky group bug
On 8/6/10 12:08 PM, Richard Gaskin wrote: Yes, with the default dynamic behavior of groups this is what most folks will experience. But some time ago I needed more canvas-like behaviors, and Scott Raney accommodated me by adding the boundingRect property for groups. His group has only 2 objects, and both are fully within the group rect. The group is locked and extends beyond its contents. The boundingrect is empty so I assume it's the same as the group rect. I don't think dynamic group behavior is in play here, or if it is, I'm at a loss as to why. I didn't play with boundingrect though. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Harry Potter's magic button - a solution to another tricky group bug
On Tue Aug 3, 2010, J. Landman Gay jacque at hyperactivesw.com wrote: I downloaded your stack and took a look. The problem isn't an unlocked group (your group was locked.) Jacqueline, really thanks for taking a look. Thanks to the others who gave feedback, too, but I think by responding to Jacqueline's questions I can cover most of the issues. I did *not* say that the problem is connected to an unlocked group. In fact, I stated somewhere in the report, that both the image-to-be-centered and the group have their lockloc set to true. I should have mentioned this at the beginning. The scenario I came across this bug - or rather a whole can of bugs - is like this: In an image-processing stack I put the image to be processed inside a group. The idea is to be able to display images of any size, images that are larger than the fixed rect (800x600) of the group can be scrolled by the horizontal and vertical scrollbars or inspected with mousedown and dragging the image directly. Besides that there is an option to display the image as a whole adjusted to a separate window covering the full screen. So in this scenario the scrollbars are necessary. Of course there are other possibilities for an image-processing stack to display the processed image without using a group, as we have done in another joint project, where a copy of the image is shown in a display image of fixed size: The real image is hidden, but at the same time transferred to the display image. When the hidden image is changed through filters or otherwise this change will then immediately be reflected via the text-of-image property in the visible image. It seems to be the scrollbars around the group. If I turn them off, it all works as expected. Unfortunately not quite! The work-around would be to turn off scollbars, set the loc of the image, and then turn them on again. It should happen pretty fast, but you could lock the screen in case. When you turn the scrollbars on again, the image will immediately snap to a topleft position again - like it does in some other cases I mentioned (going to another card and back, changing the imagedata etc.) So something about a group with scrollbars is causing the problem but I can't tell what. Neither can I, but I think there is more involved than just the scrollbars.- Another test I just did: When you turn the scrollbars off and use one of the three scripts of the automated demonstrations the stack at once crashes/freezes after having set the image to the center. By the way, the image doesn't always pop to the top left of the group. If you drag it past the bottom right corner, for example, it will go almost to the center (but not quite.) That is not correct. As it were, you are the victim of an optical delusion here, you see only a part of the image! I had described that in my report as the two-steps effect: The full image will be visible at the topleft position, if you set the loc of img x to the loc of group y a second time or click at the area of the image. Moreover, like with test button duplicate colors - lock screen, the image full image will be displayed at once at the topleft position when you add the line lock screen before line set the loc of image x to the loc of group y. I'm not sure why the extra button makes a difference, unless it simply jolts the engine into realizing where the topleft corner of the group is. That seems to be indeed part of the magic of Harry Potter's button, like also the interesting split-button effects. It will be the task and the pleasure of the Revolution engineers to find out what is going on. And they should also contemplate, why the alternate possibility to center the image using move to the loc of group x works in all cases (with or without scrollbars), but not set the loc to the loc of group x It would be good to update the bug report so the team knows what exactly to look at. If I knew myself what is going on behind the scenes, I could of course have told them, but I don't. As the report was already rather long, I have left out some other peculiarities. For instance, setting the loc of the image *not* to the loc of the group, but to other x,y coordinates will also produce unexpected results especially if x,y are near or beyond the borders of the group. Also, when saving the stack, it can happen that the part of the image which was under the window of the save dialog will be moved horizontally for a number of pixels. I have not yet found out the exact conditions, so I cannot reliably replicate this, but it happens from time to time -- Best regards, Wilhelm Sanke ___ 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
Harry Potter's magic button - a solution to another tricky group bug
I was so intrigued by the various effects of the workaround that I included magic in the subject line. Bringing Harry Potter into play may also help to start the process of improvements for Revolution announced by Kevin last week, namely - among them - better communication with users and the total overhaul of the Revolution bug management system along with quicker bug fixes (after all,. the Hogwarts School of Witchcraft and Wizardry is located not far from Edinburgh, which will facilitate the exchange of ideas). Once the Revolution programmers responsible for bug fixes will have analysed and understood what is going on behind the scenes - in the engine - concerning this bug and the workaround, they will be much better equipped to tackle the 9 remaining bugs associated with groups, too. A sample stack that demonstrates bug and workaround can be downloaded from here: http://www.sanke.org/Software/Magic Button.zip There are basically four aspects to this magic: 1. The magic button - as a workaround - resolves the group bug that YOU CANNOT SET THE LOC OF AN IMAGE IN A GROUP IF THE IMAGE IS SMALLER THAN THE GROUP. In the case of a smaller image the scriptline set the loc of image x to the loc of group y will place the image at the topleft corner of the group instead (unless the loc of the image is already exactly identical with the group loc). Now, after you put Harry Potter's button into the upperleft corner of the group, the above scriptline with set the loc will now work as it should. It is essential here that the magic button is visible in the sense that its visibility is set to true. But you could shove the button under the topleft corner of the group so that it actually becomes invisible and it will nevertheless continue to exert its spell. The moment you hide the button, i.e. with hide or set the vis to false, the image will snap again to a topleft position in the group. 2. The magic button can be moved across the visible part of the group area by script - diagonally, horizontally, vertically - without being addressed with its name or any other identifier. One precondition for this to happen is that the image is at least 1 pixel off the loc of the group. Place the button anywhere in the group, press button center image using set the loc repeatedly, and the magic button will move in steps until it reaches the upperleft corner of the group. The first time you press the button the image will be also be placed at the topleft of the group with only one step. The distance the magic button will move vertically and horizontally with a step is different with image size and dependent on the height and width of the image, e.g. with a broader image the horizontal steps will be much smaller, with a smaller height the steps will be bigger. You can see this best with image Steve and friend (Steve Jobs, the iPhone, and Medwedjew), but I recommend to try out the options of the sample stack with image Red Square first. 3. An interesting variant of 2. is the split button: Place the magic button at the bottomleft corner of the group. Make sure the image is at least 1 pixel off the loc of the group (Both the button and the image have a grab me script, so you can do this manually with mousedown). Now, as above in 2. press button center image using set the loc . The magic button will move upwards in steps. When it has reached the area of the image the button will split. The part of the button intersecting with the image will continue to move upwards. The left part of the button will remain in place until the right part of the button has reached the top of the group. At that moment the two separate parts of the magic button will re-unite. If you place the button to the right of the group, the splitting of the button will occur horizontally.-- There are three special buttons in the sample stack that demonstrate these effects (2. and 3.) automated with repeat loops. At the top of these scripts for the automated demonstrations I make use of the move command (which is not broken) to make sure image and magic button are placed at the appropriate places, but for creating the effects the broken set command is used inside the repeat loops. 4. Button reset image will restore the original imagedata stored in a custom property and center the image using the move command. When you have placed the magic button somewhere on the group area like above in points 2. and 3. and you then press the reset image button repeatedly the magic button will also move in steps towards the topleft of the group, but without producing the split effect. A few more particulars and peculiarities for those interested in getting a broader picture: If the magic button is absent or hidden and you have managed to center the image (either by using the move command or by dragging the image manually), there are now several additional
Re: Harry Potter's magic button - a solution to another tricky group bug
On 8/3/10 2:55 PM, Wilhelm Sanke wrote: YOU CANNOT SET THE LOC OF AN IMAGE IN A GROUP IF THE IMAGE IS SMALLER THAN THE GROUP. In the case of a smaller image the scriptline set the loc of image x to the loc of group y will place the image at the topleft corner of the group instead (unless the loc of the image is already exactly identical with the group loc). I haven't looked at your stack yet but I just did a quick test with a new stack, new group, and a small image inside the group, and I had no trouble setting the image location anywhere from the message box, including setting it to the loc of the group. Maybe there is something else required for it to fail? My group had 2 buttons and a small image, and the lockloc was set to true. The group was the normal default size that encompassed the 2 buttons which served as anchors at the top left and lower right of the group. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Harry Potter's magic button - a solution to another tricky group bug
Me, too, with a group and an even smaller image. If I set the loc of the image to a point outside the group, the group expands to contain it, as usual. If I set it to a point anywhere inside the group, again, the group extent adjusts. On a Mac. Does this matter? Craig Newman ___ 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: Harry Potter's magic button - a solution to another tricky group bug
Not sure, but I'd guess that the OP is falling afoul of the elastic nature of groups that have lockloc=false. When that is the case, groups automatically snap to the bounds of whatever they contain whenever they get the chance -- i.e. when the things they contain move or are themselves resized (I believe, I haven't tested all the variations here). That can cause some unexpected behavior if you're expecting groups to behave as if their lockloc were true, which allows them to be sized and positioned as most other controls are (whether those controls have their lockloc set to true or false). gc On Tue, Aug 3, 2010 at 3:21 PM, dunb...@aol.com wrote: Me, too, with a group and an even smaller image. If I set the loc of the image to a point outside the group, the group expands to contain it, as usual. If I set it to a point anywhere inside the group, again, the group extent adjusts. On a Mac. Does this matter? Craig Newman ___ 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: Harry Potter's magic button - a solution to another tricky group bug
On 8/3/10 2:55 PM, Wilhelm Sanke wrote: 1. The magic button - as a workaround - resolves the group bug that YOU CANNOT SET THE LOC OF AN IMAGE IN A GROUP IF THE IMAGE IS SMALLER THAN THE GROUP. In the case of a smaller image the scriptline set the loc of image x to the loc of group y will place the image at the topleft corner of the group instead (unless the loc of the image is already exactly identical with the group loc). I downloaded your stack and took a look. The problem isn't an unlocked group (your group was locked.) It seems to be the scrollbars around the group. If I turn them off, it all works as expected. So something about a group with scrollbars is causing the problem but I can't tell what. By the way, the image doesn't always pop to the top left of the group. If you drag it past the bottom right corner, for example, it will go almost to the center (but not quite.) So it's being offset to the left and top by some amount. Your scrollbars were inactive, but the image is behaving as though the group is scrolled and it's looking for the center of the virtual group space. It should, of course, look for the group's location on the card instead. I'm not sure why the extra button makes a difference, unless it simply jolts the engine into realizing where the topleft corner of the group is. The work-around would be to turn off scollbars, set the loc of the image, and then turn them on again. It should happen pretty fast, but you could lock the screen in case. It would be good to update the bug report so the team knows what exactly to look at. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
Quality Control Center - handling of bug reports
CCs of this post are sent to supp...@runrev.com and ke...@runrev.com. There are about 10 or more (minor to critical) bugs associated with the group object, which have cost me plenty of time and a huge amount of frustation to get to the details of these bugs and eventually to find out workarounds if possible. These bugs seem to be totally outside the scope and interest of the RunRev team. My bug report 8275 of Sept. 16, 2009, Groups: Bugs and features (last group broken)?, which listed 5 of these group bugs, is stiil shown as unconfirned as of today - nearly 11 months later! If they should indeed have looked at the report and cannot replicate the bugs, I would at least expect an organized attempt to communicate with the bug reporter, maybe asking him for more information or a sample stack etc.etc.. As an active supporter and user of Revolution since its beginnings I am of course aware of the difficulties and the multitude of tasks the Rev team has to address with limited personal resources. But I think there is an urgent need to re-organize the handling of bug reports and the management of the so-called Quality Control Center. To completely disregard valuable feedback from motivated users is not the way to keep up or build trust for Revolution and its developers. Regards, Wilhelm Sanke http://www.sanke.org/MetaMedia ___ 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: Quality Control Center - handling of bug reports
There are about 10 or more (minor to critical) bugs associated with the group object, which have cost me plenty of time and a huge amount of frustation to get to the details of these bugs and eventually to find out workarounds if possible. These bugs seem to be totally outside the scope and interest of the RunRev team. My bug report 8275 of Sept. 16, 2009, Groups: Bugs and features (last group broken)?, which listed 5 of these group bugs, is stiil shown as unconfirned as of today - nearly 11 months later! If they should indeed have looked at the report and cannot replicate the bugs, I would at least expect an organized attempt to communicate with the bug reporter, maybe asking him for more information or a sample stack etc.etc.. As an active supporter and user of Revolution since its beginnings I am of course aware of the difficulties and the multitude of tasks the Rev team has to address with limited personal resources. But I think there is an urgent need to re-organize the handling of bug reports and the management of the so-called Quality Control Center. To completely disregard valuable feedback from motivated users is not the way to keep up or build trust for Revolution and its developers. I completely agree Wilhelm. As I said in an email to this list about a month ago, we would all much prefer to see our bugs listed as Confirmed even if there was no immediate prospect of a fix. At least it would indicate that the bug report had been looked at. Kevin responded to my email at the time, and although I forget his exact words, he did imply that they were aware that better communication was needed. Hopefully this will new attitude will extend to the list and to the bug reports. Cheers, Sarah Rodeo discussion: http://rodeoapps.com/rodeo-discuss-among-yourselves ___ 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: Quality Control Center - handling of bug reports
It seems if the bug report is not for the latest developer build the enterprise users are testing nothing gets fixed.. I understand about the issues and what-not but I have pretty much stopped submitting bugs a long time ago and just recently closed all my open bugs seeing as they will never get looked at let alone resolved.. ___ 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: Quality Control Center - handling of bug reports
On 28/07/2010 10:22, Wilhelm Sanke sa...@hrz.uni-kassel.de wrote: CCs of this post are sent to supp...@runrev.com and ke...@runrev.com. There are about 10 or more (minor to critical) bugs associated with the group object, which have cost me plenty of time and a huge amount of frustation to get to the details of these bugs and eventually to find out workarounds if possible. These bugs seem to be totally outside the scope and interest of the RunRev team. My bug report 8275 of Sept. 16, 2009, Groups: Bugs and features (last group broken)?, which listed 5 of these group bugs, is stiil shown as unconfirned as of today - nearly 11 months later! If they should indeed have looked at the report and cannot replicate the bugs, I would at least expect an organized attempt to communicate with the bug reporter, maybe asking him for more information or a sample stack etc.etc.. As an active supporter and user of Revolution since its beginnings I am of course aware of the difficulties and the multitude of tasks the Rev team has to address with limited personal resources. But I think there is an urgent need to re-organize the handling of bug reports and the management of the so-called Quality Control Center. To completely disregard valuable feedback from motivated users is not the way to keep up or build trust for Revolution and its developers. I agree. I have responded in more detail on this topic and on a number of other important points relating to the direction of the Rev platform on our revEnterprise improve-rev membership mailing list. Kind regards, Kevin Kevin Miller ~ ke...@runrev.com ~ http://www.runrev.com/ RunRev - Software construction for everyone ___ 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: Quality Control Center - handling of bug reports
Shao Sean wrote: It seems if the bug report is not for the latest developer build the enterprise users are testing nothing gets fixed.. I understand about the issues and what-not but I have pretty much stopped submitting bugs a long time ago and just recently closed all my open bugs seeing as they will never get looked at let alone resolved.. On the 14th I wrote here: As Jacque has noted here many times, the RQCC is a part of their workflow process but not all of it. Internally they use different systems for tracking progress, updating the RQCC in batches as time permits. You'll notice that every few months Oliver goes through the RQCC and marks dozens of things fixed in the span of a few hours. It's not that the team was sitting around drinking for months and then suddenly got a burst of energy and did everything in one day, but just that the system that helps them best internally is separate from the public convenience they provide in the RQCC. These two bug reports are good examples: http://quality.runrev.com/qacenter/show_bug.cgi?id=6264 http://quality.runrev.com/qacenter/show_bug.cgi?id=7490 One notes anomalies with the size of default buttons on Windows and Linux, and the other with OS X and Linux. The Win and OS X default button size issues were addressed long ago, and I know from contact with the team that the Linux variant of that bug has been addressed recently for v4.5 (see my post with screen shots from the team at http://mail.runrev.com/pipermail/use-revolution/2010-July/143647.html). Those two reports are effectively duplicates, but have not been marked as such. Moreover, half of each was addressed a long time ago, and the other half recently, yet both still have a status of New. I can fully appreciate why they use a different tool for tracking changes internally and why they don't make that public, and given that I can also understand that updating the status field for reports in the RQCC is a back-burner project done only as time permits, usually in batches and almost always long after the issue's status had actually changed. Without knowing the specific reports in question I have no opinion on those, but in general a key factor that makes the RQCC problematic is merely one of expectations management: if there was a header at the top of each page there that noted that the RQCC is provided only as a convenience for the community and not reflective of actual progress, then folks could use it for what it is without expecting it to be something else. This ongoing topic is illustrative of the reason so very few companies have any sort of public bug database at all. Personally, I like having access to the RQCC, warts and all. I find it helpful for a general gauge of scope, and some of the details posted in reports have been very useful in helping me find workarounds I need to get through the day. But if RunRev decided to follow the convention used by the rest of the industry in not publishing any bug database, I would understand. If the issues you reported actually still exist in the engine, closing those reports before they've been confirmed as fixed by you only makes them more obscure. Even if the lag between the RQCC and the internal process they use annoys you, it does a better service to the community to simply leave the reports in place. No one requires you to read them, but I read most of the reports there a couple times each year and learn a lot from them. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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
Tool palette bug?
This came up in one of the forums. I couldn't find it in the Q/A center, which surprised me The fill color, line weight and line size tools will not modify an existing graphic or bitmap. They will only set these properties for newly created ones. The colors and patterns pane in the inspector works fine, as does script control. Of course. It seem counterintuitive to me, unless this is a bug, that an existing, selected graphic is immune to the palette tools explicitly made to modify them. Craig Newman ___ 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: Tool palette bug?
On 7/28/10 9:24 AM, dunb...@aol.com wrote: This came up in one of the forums. I couldn't find it in the Q/A center, which surprised me The fill color, line weight and line size tools will not modify an existing graphic or bitmap. They will only set these properties for newly created ones. Correct. The tool palette only sets the properties of the template object, which controls how new objects look. To change the fill color of an existing object, use its property inspector. The same applies to any object; for example, setting a button style in the tool palette only controls how the new button looks. To change its style, use the property inspector. Selecting an existing button and clicking a different button style in the tool palette will do nothing. Images have a unique restriction. They are drawn with their own color palette, and only colors available in the color table can be used for the image properties. So you may not be able to set the border color of an image if that color does not exist already in the image. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Tool palette bug?
Thanks, Jacque. That the template object is what is set by those tools is completely understandable, and totally unresearchable. Longing for a Rev Goodman. Craig ___ 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: Tool palette bug?
Actually - this list is a kind of real-time Danny Goodman. I don't think one person can profitably write and publish an all-encompassing tome these days about Rev like Goodman did about HC - Rev is too big now and constantly being improved. Witness Dan Shafer not publishing volumes 2 and 3 ( or was there a pdf or online edition ever finished?). sqb On 28 July 2010 09:30, dunb...@aol.com wrote: Thanks, Jacque. That the template object is what is set by those tools is completely understandable, and totally unresearchable. Longing for a Rev Goodman. Craig Stephen Barncard San Francisco Ca. USA more about sqb http://www.google.com/profiles/sbarncar ___ 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: Tool palette bug?
On 7/28/10 11:30 AM, dunb...@aol.com wrote: Thanks, Jacque. That the template object is what is set by those tools is completely understandable, and totally unresearchable. Longing for a Rev Goodman. Like Stephen said, Rev got too big. I've considered writing a book a couple of times and couldn't face the task. It would take years and the book would cost $100 minimum. There's one search mechanism you may not be aware of though. It needs updating, but mostly still works. Under the Help menu, choose Revolution search engine. There are lots of options there for searching web sites (that's the part that needs updating,) lists, documentation, online search engines, and other resources. It's a more comprehensive search than just what the dictionary offers. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Quality Control Center - handling of bug reports
On Wed Jul 28, 2010, Kevin Miller kevin at runrev.com wrote: On 28/07/2010 10:22, Wilhelm Sanke sanke at hrz.uni-kassel.de wrote: As an active supporter and user of Revolution since its beginnings I am of course aware of the difficulties and the multitude of tasks the Rev team has to address with limited personal resources. But I think there is an urgent need to re-organize the handling of bug reports and the management of the so-called Quality Control Center. To completely disregard valuable feedback from motivated users is not the way to keep up or build trust for Revolution and its developers. I agree. I have responded in more detail on this topic and on a number of other important points relating to the direction of the Rev platform on our revEnterprise improve-rev membership mailing list. Kind regards, Kevin Kevin, Thank you very much for responding and agreeing. With your answer you made me look through your recent posts on the improve list to find a match for the subject of my own post. As the members of the use list are also entitled and interested to file bug reports and use the Quality Control Center, I assume it is allowed to quote from the enterprise list in this case. The closest match I could find is a passage in one of your posts about New roadmap (Pricing): Things are going to get simpler and we'll be able to use the new options to support the various things our professional developers want, like more communication, faster progress on features, a very different approach to bug management and closer co-operation with the community. (snip) All in all, a fresher, stronger, more nimble, more open company is in process of being born. Although these are very general statements, some of which I seem to have heard before, I appreciate very much that you intend a closer co-operation with the community. And I hope the different approach to bug management will be implemented in a way that takes into account the existing unfixed and unconfirmed bug reports, these maybe even with a certain priority and an indication of the timeframe for fixing them. Best regards, Wilhelm ___ 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: Tool palette bug?
There's one search mechanism you may not be aware of though. It needs updating, but mostly still works. Under the Help menu, choose Revolution search engine. There are lots of options there for searching web sites (that's the part that needs updating,) lists, documentation, online search engines, and other resources. It's a more comprehensive search than just what the dictionary offers. Never noticed it before... that's awesome! Thanks for sharing that Jacque! Best regards, David C. ___ 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: Quality Control Center - handling of bug reports
As I've just accidentally posted a message to the other list (that was meant to be private) touching this, it's timely to come back to the use list and find this discussion ongoing. In responding to another thread a month ago I checked stats for the reports that I've opened in RQCC over the years. Few I think for the latest developer build as for the last few years I've rarely had time to do proper testing, let alone proper reporting, on bleeding edge builds, and have somewhat guiltily been relying on others to do so. The current tally is: 34 unconfirmed (of which 22 enhancements) 3 pending 20 new 1 assigned 155 resolved I'm not happy about the 35, but I think the overall tally isn't bad. And I suspect that some of the 59 unresolved may have actually been fixed. But they're not updated. Richard Gaskin wrote: I can fully appreciate why they use a different tool for tracking changes internally and why they don't make that public, and given that I can also understand that updating the status field for reports in the RQCC is a back-burner project done only as time permits, usually in batches and almost always long after the issue's status had actually changed. I can't fully appreciate it. I'm not sure what would be so awful about seeing the interchange between engineers, the notes made etc. If it really needs it, I'm sure Bugzilla has some capability to make private notes that are only visible to certain users. While seeing a private note that one couldn't read would be frustrating, it would be great to see evidence of progress. And if it really is necessary to use a separate tool internally, then I think a much higher priority should be given to keeping RQCC status updated. As a minimum, if an issue has been adopted into the internal tracking tool, it should be 'confirmed' in RQCC with a note of the reference in the internal tracking tool. That would at a stroke relieve a deal of the frustration felt by users who've taken the time to report an issue and see it apparently or actually ignored. But I also don't think it's reasonable that updating the RQCC when time permits ... long after the status had actually changed. Time will never permit - if this isn't worth doing now, there'll always be something more important. The only exception to this that I would accept is that 'resolve-fixed' might be deferred until release of a new GM. Two reasons why I think this is worth the time: one is just PR. The second is to preserve a valued resource. RunRev is not Microsoft. It cannot employ hundreds of testers in a well equipped config lab. Rev is a fantastically complex product. There are inevitably masses of issues in Rev. RunRev cannot hope to find more than some of the ones in the new features that they are working on. They can keep adding new features, each with new bugs, and never fix (because never find) more than a few of the old ones; I doubt if this is a route to massive success. If they wish to do any better than this at improving the quality of the product, the work of their users in noting, isolating and reporting problems is absolutely essential. Users will do this for two reasons: selfish (they want this issue fixed) and unselfish (they've found a workaround so it doesn't bother them any more, but think it would help others and the product if it was fixed). Both motives will not survive the appearance that their efforts are wasted. Keeping these users motivated, by taking the time to record that the bug has at least been read; certainly by recording that it has been put on the internal tracking tool (assigned?); and by making part of the engineer's job when they change the status in the internal tool, to also update the external one, is far far cheaper than any other possible way of getting that level of testing done. Shao Sean wrote: I have pretty much stopped submitting bugs a long time ago and just recently closed all my open bugs seeing as they will never get looked at let alone resolved. Both clauses of that are a tragedy. Ben ___ 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: Quality Control Center - handling of bug reports
On 28/07/2010 21:59, Ben Rubinstein benr...@cogapp.com wrote: Two reasons why I think this is worth the time: one is just PR. The second is to preserve a valued resource. RunRev is not Microsoft. It cannot employ hundreds of testers in a well equipped config lab. Rev is a fantastically complex product. There are inevitably masses of issues in Rev. RunRev cannot hope to find more than some of the ones in the new features that they are working on. They can keep adding new features, each with new bugs, and never fix (because never find) more than a few of the old ones; I doubt if this is a route to massive success. If they wish to do any better than this at improving the quality of the product, the work of their users in noting, isolating and reporting problems is absolutely essential. Users will do this for two reasons: selfish (they want this issue fixed) and unselfish (they've found a workaround so it doesn't bother them any more, but think it would help others and the product if it was fixed). Both motives will not survive the appearance that their efforts are wasted. There will be a completely new approach to bug management introduced at the point that we ship 4.5. We'll elaborate on the details when we introduce it. Kind regards, Kevin Kevin Miller ~ ke...@runrev.com ~ http://www.runrev.com/ RunRev - Software construction for everyone ___ 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: Quality Control Center - handling of bug reports
Ben Rubinstein wrote: Keeping these users motivated, by taking the time to record that the bug has at least been read; certainly by recording that it has been put on the internal tracking tool (assigned?); and by making part of the engineer's job when they change the status in the internal tool, to also update the external one, is far far cheaper than any other possible way of getting that level of testing done. Well said, Ben. Because my expectations for the RQCC are different from others, it has been easy for me to overlook the role it could potentially play in keeping participants motivated. Your note was a good reminder along those lines. Thanks. -- Richard Gaskin Fourth World Rev training and consulting: http://www.fourthworld.com Webzine for Rev developers: http://www.revjournal.com revJournal blog: http://revjournal.com/blog.irv ___ 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: Quality Control Center - handling of bug reports
Let me just say that for a development environment, Revolution is about the most inexpensive one I found. It shouldn't surprise me that RunRev Inc. does not have the resources to do everything that everyone demands. No developer allows the public to see what they are doing internally to debug their software. No dev team makes their discussions about bugs public! That is just silly to expect that. I think the problem is we have such a real community of people here, we forget that unless we are getting a check from RunRev every month, we are, in fact, the public. So I say, thank you RunRev for adding all the cool features I whined about in the beginning, like a table object for instance, and not getting too hung up with squashing bugs that only affect one or two people and have a workaround anyway. And thanks to Trevor for making a database library that I can use without having to learn SQL shudders uncontrollably. And thanks to everyone else that makes cool things with Revolution so that RunRev doesn't have to. Bugs are a bummer, but I think the only bugs that really require immediate resolution are the fatal ones. Prompt attention should be given to non-fatal ones with no workaround. Non-fatal bugs with a workaround, bah! I'd rather see new features then have RunRev get hung up in those. Really, I think we need to quantify how many fatal bugs RunRev has left outstanding, and judge them on that. I don't know of any. When I started using Revolution I was getting hangs and crash to desktop pretty regularly. Now I rarely get them, and none have ever whacked my stacks, at least to my knowledge. 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: Quality Control Center - handling of bug reports
On Jul 28, 2010, at 11:51 PM, Kevin Miller wrote: There will be a completely new approach to bug management introduced at the point that we ship 4.5. We'll elaborate on the details when we introduce it. Sometimes when one goes through painful and chaotic periods in one's life they come out with fresh, vital, perceptive views on things. Clarity and perspective. Thank you Kevin for what seems to be a new approach, several new approaches really, on how Rev does things. Thank you, thank you. sims ___ 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
[Possible BUG] Can someone confirm that calling RevBrowserClose with wrong id will crash app in MacOS X
Hello, Can someone confirm that calling RevBrowserClose with wrong id will crash app in MacOS X? Here on 4.5.0-dp-3 if I call RevBrowserClose with a bad id it will lock the process and die. :-/ silly external... -- http://www.andregarzia.com All We Do Is Code. ___ 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: [Possible BUG] Can someone confirm that calling RevBrowserClose with wrong id will crash app in MacOS X
Hi Andre - no problem here. I just get an error message... External execution error: Error description: unknown browser id Rev 4.5.0-dp-3, OSX 10.6.4 Terry... On 27/07/10 7:32 AM, Andre Garzia an...@andregarzia.com wrote: Hello, Can someone confirm that calling RevBrowserClose with wrong id will crash app in MacOS X? Here on 4.5.0-dp-3 if I call RevBrowserClose with a bad id it will lock the process and die. :-/ silly external... -- Dr Terry Judd | Senior Lecturer in Medical Education Medical Education Unit Melbourne Medical School The University of Melbourne ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
On 02/07/2010 00:08, Andre Garzia wrote: I consider that a bug and you? will fill a bugzilla report after dinner... Is this a different issue from: http://quality.runrev.com/qacenter/show_bug.cgi?id=3926 ? ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Ben, I think it is the same bug... damn that bug is old... On Mon, Jul 5, 2010 at 10:41 AM, Ben Rubinstein benr...@cogapp.com wrote: On 02/07/2010 00:08, Andre Garzia wrote: I consider that a bug and you? will fill a bugzilla report after dinner... Is this a different issue from: http://quality.runrev.com/qacenter/show_bug.cgi?id=3926 ? ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
All are invited to pile in with comments on this bug report, in the interests of adding useful details ((and raising the activity level) that may help it make that difficult move from Unconfirmed to New! On 05/07/2010 14:51, Andre Garzia wrote: Ben, I think it is the same bug... damn that bug is old... On Mon, Jul 5, 2010 at 10:41 AM, Ben Rubinsteinbenr...@cogapp.com wrote: On 02/07/2010 00:08, Andre Garzia wrote: I consider that a bug and you? will fill a bugzilla report after dinner... Is this a different issue from: http://quality.runrev.com/qacenter/show_bug.cgi?id=3926 ? ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
added comments and votes. On Mon, Jul 5, 2010 at 11:19 AM, Ben Rubinstein benr...@cogapp.com wrote: All are invited to pile in with comments on this bug report, in the interests of adding useful details ((and raising the activity level) that may help it make that difficult move from Unconfirmed to New! On 05/07/2010 14:51, Andre Garzia wrote: Ben, I think it is the same bug... damn that bug is old... On Mon, Jul 5, 2010 at 10:41 AM, Ben Rubinsteinbenr...@cogapp.com wrote: On 02/07/2010 00:08, Andre Garzia wrote: I consider that a bug and you? will fill a bugzilla report after dinner... Is this a different issue from: http://quality.runrev.com/qacenter/show_bug.cgi?id=3926 ? ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Hi all, I do not have a computer with multiple monitors, but reading the documentation about export snapshot, i noticed: To export a snapshot for a portion of a stack you use the form: export snapshot from rect[angle] of window windowId to ... Where windowId is the windowId property of the required stack. Just for curiosity, Does this code works fine, if you add this windowId property? -- Test in your multiple monitor setup and report results export snapshot from rect tRect of window windowId to tSnapshot as PNG export snapshot from this card of window windowId to tSnapshot as PNG export snapshot from window windowId to tSnapshot as PNG Thanks in advance! Al -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/BUG-Confirmed-can-t-capture-screen-from-second-monitor-Was-Re-BUG-Can-anyone-here-confirm-that-RevBr-tp2275775p2278615.html Sent from the Revolution - User mailing list archive at Nabble.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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Alejandro, Tried that, didn't work... Cheers andre On Mon, Jul 5, 2010 at 1:54 PM, Alejandro Tejada capellan2...@gmail.comwrote: Hi all, I do not have a computer with multiple monitors, but reading the documentation about export snapshot, i noticed: To export a snapshot for a portion of a stack you use the form: export snapshot from rect[angle] of window windowId to ... Where windowId is the windowId property of the required stack. Just for curiosity, Does this code works fine, if you add this windowId property? -- Test in your multiple monitor setup and report results export snapshot from rect tRect of window windowId to tSnapshot as PNG export snapshot from this card of window windowId to tSnapshot as PNG export snapshot from window windowId to tSnapshot as PNG Thanks in advance! Al -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/BUG-Confirmed-can-t-capture-screen-from-second-monitor-Was-Re-BUG-Can-anyone-here-confirm-that-RevBr-tp2275775p2278615.html Sent from the Revolution - User mailing list archive at Nabble.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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Hi I did experience trouble with browser snapshot. I did not relate it to double screen I retested and found out the following that can help : 1) take the browser sampler, open on main screen, use snapshot. All works fine. 2) drag the pile to 2nd screen : use snapshot : there comes garbage (gray lines..) 3) drag back to main screen : use snapshot : PROBLEM REMAINS, yu still get garbage! 4) solution is to move to another card, and come back, in effect launching a new browser, and works again. = gray line snapshot garbage off the main screen seems to be persistent once it occurs. It's like Herpes.. -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/BUG-Can-anyone-here-confirm-that-RevBrowserSnapshot-works-tp2275672p2276274.html Sent from the Revolution - User mailing list archive at Nabble.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: Mac Standalone Bug
Bill Vlahos wrote: That doesn't fix it in 4.0. Here's one more way to deal with the problem. Keep destroystack set to false as before, and destroywindow as well. Add this to a preOpenStack handler: if the platform = macOS and the environment is not development then set the menubar of this stack to myMenuGroup Build your standalone with the menubar property turned off; that is, build it as though it were for Windows with the menu group showing. When your standalone launches, it will set the menubar on a Mac and the stack will resize as you'd expect. I've used this and it has always worked. Bill Vlahos _ InfoWallet (http://www.infowallet.com) is about keeping your important life information with you, accessible, and secure. On Jun 24, 2010, at 10:22 AM, J. Landman Gay wrote: Justin Sloan wrote: Jeff, I do have a menu. Is that the problem? How do I counter it? It's an ancient issue. If you have a menu, make sure the destroystack property of the stack is false. That fixes it. Then rebuild the standalone. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
[BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Folks, I have the following code here: local tSnapshot revBrowserSnapshot _W[browser id], tSnapshot set the imageData of img slide to tSnapshot This yields an image that looks like static noise, it is grayscale and I can see traces of the real image there... Any clue? -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Andre Garzia wrote: Folks, I have the following code here: local tSnapshot revBrowserSnapshot _W[browser id], tSnapshot set the imageData of img slide to tSnapshot This yields an image that looks like static noise, it is grayscale and I can see traces of the real image there... Any clue? This may be one of those cases where the sizes of the two images don't match. Img slide has to be the same dimensions as tSnapshot. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Jacque, They are the same size, I am setting the height and the width of both with the same variables... :-/ ARGH! On Thu, Jul 1, 2010 at 5:53 PM, J. Landman Gay jac...@hyperactivesw.comwrote: Andre Garzia wrote: Folks, I have the following code here: local tSnapshot revBrowserSnapshot _W[browser id], tSnapshot set the imageData of img slide to tSnapshot This yields an image that looks like static noise, it is grayscale and I can see traces of the real image there... Any clue? This may be one of those cases where the sizes of the two images don't match. Img slide has to be the same dimensions as tSnapshot. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
I am also having trouble with export snapshot as well... since the revBrowserSnapshot does not work, I decided to give old export snapshot command a try: thats the error I am receiving: Error description: export: no image selected, or image not open export snapshot from rect 1472,144,2112,624 to tSnapshot as PNG The code is the one above. I've tried exporting to files as well, same error... Any clues? Can both export snapshot commands be broken? On Thu, Jul 1, 2010 at 5:54 PM, Andre Garzia an...@andregarzia.com wrote: Jacque, They are the same size, I am setting the height and the width of both with the same variables... :-/ ARGH! On Thu, Jul 1, 2010 at 5:53 PM, J. Landman Gay jac...@hyperactivesw.comwrote: Andre Garzia wrote: Folks, I have the following code here: local tSnapshot revBrowserSnapshot _W[browser id], tSnapshot set the imageData of img slide to tSnapshot This yields an image that looks like static noise, it is grayscale and I can see traces of the real image there... Any clue? This may be one of those cases where the sizes of the two images don't match. Img slide has to be the same dimensions as tSnapshot. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 -- http://www.andregarzia.com All We Do Is Code. -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Andre Garzia wrote: I am also having trouble with export snapshot as well... since the revBrowserSnapshot does not work, I decided to give old export snapshot command a try: thats the error I am receiving: Error description: export: no image selected, or image not open export snapshot from rect 1472,144,2112,624 to tSnapshot as PNG The code is the one above. I've tried exporting to files as well, same error... Any clues? Can both export snapshot commands be broken? I was just trying out export snapshot to see if I could help, and I wasn't having any trouble with that part. I was using: export snapshot from the mousecontrol to tSnapshot put tSnapshot When I held the mouse over a button and executed that from the message box, the message box filled with image binary data. So that works. I didn't specify a format, I let the engine choose it. What I can't do is set an image from the variable. I know there's a way, but I don't remember it. If I use the imagedata I get something that is close but not correct. If I use put tSnapshot into img 1 or set the text of img 1 to tSnapshot, the image snaps to the correct dimensions as though it was accomodating the new image size, but nothing shows. The image is white. That's as far as I got. Where's Scott Rossi when you need him? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Thanks for the efforts Jacque, still having trouble though. That's as far as I got. Where's Scott Rossi when you need him? He's on a different thread right now... just above this message! :-D -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
[runs into nearest phone booth and puts on imageData suit] One thing I noticed with revBrowser is it doesn't seem capturable (is that a word?) using coords from the window in which it is displayed, but using global coords works: import snapshot from rect 200,200,400,400 So exporting to a variable using global coords should work: export snapshot from rect 200,200,400,400 to myVar as PNG set text of img test to myVar I tried these here and both seem to work. Regards, Scott Rossi Creative Director Tactile Media, UX Design Recently, Jacque Landman Gay wrote: Andre Garzia wrote: I am also having trouble with export snapshot as well... since the revBrowserSnapshot does not work, I decided to give old export snapshot command a try: thats the error I am receiving: Error description: export: no image selected, or image not open export snapshot from rect 1472,144,2112,624 to tSnapshot as PNG The code is the one above. I've tried exporting to files as well, same error... Any clues? Can both export snapshot commands be broken? I was just trying out export snapshot to see if I could help, and I wasn't having any trouble with that part. I was using: export snapshot from the mousecontrol to tSnapshot put tSnapshot When I held the mouse over a button and executed that from the message box, the message box filled with image binary data. So that works. I didn't specify a format, I let the engine choose it. What I can't do is set an image from the variable. I know there's a way, but I don't remember it. If I use the imagedata I get something that is close but not correct. If I use put tSnapshot into img 1 or set the text of img 1 to tSnapshot, the image snaps to the correct dimensions as though it was accomodating the new image size, but nothing shows. The image is white. That's as far as I got. Where's Scott Rossi when you need him? ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Recently, Andre Garzia wrote: Just tried this exact piece: set the width of me to presentationWidth() set the height of me to presentationHeight() set the imageData of me to tSnapshot put the rect of stack presentation into tRect export snapshot from rect tRect to tSnapshot as PNG set the text of me to tSnapshot I am receiving this on the message box: Message execution error: Error description: export: no image selected, or image not open Hint: By the way, which Rev version are you using? Here it is 4.5-dp-3 the screenshotable stack is on the second monitor, so the rect looks like: 1472,144,2112,624 Maybe you have not defined tSnapshot earlier in the handler so Rev doesn't know it's an empty variable? Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Scott, do I need something more than a: local tSnapshot to define it? I will try putting empty in there first... On Thu, Jul 1, 2010 at 6:45 PM, Scott Rossi sc...@tactilemedia.com wrote: Recently, Andre Garzia wrote: Just tried this exact piece: set the width of me to presentationWidth() set the height of me to presentationHeight() set the imageData of me to tSnapshot put the rect of stack presentation into tRect export snapshot from rect tRect to tSnapshot as PNG set the text of me to tSnapshot I am receiving this on the message box: Message execution error: Error description: export: no image selected, or image not open Hint: By the way, which Rev version are you using? Here it is 4.5-dp-3 the screenshotable stack is on the second monitor, so the rect looks like: 1472,144,2112,624 Maybe you have not defined tSnapshot earlier in the handler so Rev doesn't know it's an empty variable? Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
tried, not good... damn... On Thu, Jul 1, 2010 at 6:50 PM, Andre Garzia an...@andregarzia.com wrote: Scott, do I need something more than a: local tSnapshot to define it? I will try putting empty in there first... On Thu, Jul 1, 2010 at 6:45 PM, Scott Rossi sc...@tactilemedia.comwrote: Recently, Andre Garzia wrote: Just tried this exact piece: set the width of me to presentationWidth() set the height of me to presentationHeight() set the imageData of me to tSnapshot put the rect of stack presentation into tRect export snapshot from rect tRect to tSnapshot as PNG set the text of me to tSnapshot I am receiving this on the message box: Message execution error: Error description: export: no image selected, or image not open Hint: By the way, which Rev version are you using? Here it is 4.5-dp-3 the screenshotable stack is on the second monitor, so the rect looks like: 1472,144,2112,624 Maybe you have not defined tSnapshot earlier in the handler so Rev doesn't know it's an empty variable? Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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 -- http://www.andregarzia.com All We Do Is Code. -- http://www.andregarzia.com All We Do Is Code. ___ 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
[BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Folks, Just tested here, capturing a screen shot from first monitor works fine, capturing an screen shot from the second monitor fails. Can someone try this before I bugzilla it? Cheers andre On Thu, Jul 1, 2010 at 6:51 PM, Andre Garzia an...@andregarzia.com wrote: tried, not good... damn... On Thu, Jul 1, 2010 at 6:50 PM, Andre Garzia an...@andregarzia.comwrote: Scott, do I need something more than a: local tSnapshot to define it? I will try putting empty in there first... On Thu, Jul 1, 2010 at 6:45 PM, Scott Rossi sc...@tactilemedia.comwrote: Recently, Andre Garzia wrote: Just tried this exact piece: set the width of me to presentationWidth() set the height of me to presentationHeight() set the imageData of me to tSnapshot put the rect of stack presentation into tRect export snapshot from rect tRect to tSnapshot as PNG set the text of me to tSnapshot I am receiving this on the message box: Message execution error: Error description: export: no image selected, or image not open Hint: By the way, which Rev version are you using? Here it is 4.5-dp-3 the screenshotable stack is on the second monitor, so the rect looks like: 1472,144,2112,624 Maybe you have not defined tSnapshot earlier in the handler so Rev doesn't know it's an empty variable? Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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 -- http://www.andregarzia.com All We Do Is Code. -- http://www.andregarzia.com All We Do Is Code. -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Recently, Andre Garzia wrote: Just tested here, capturing a screen shot from first monitor works fine, capturing an screen shot from the second monitor fails. Can someone try this before I bugzilla it? If you move the stack to your main monitor, does the snapshot code work? Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
The main-monior-only feature has been true for years. [ 2.0,I think ] My solution for a dual screen capture is to move the stack to the main monitor, snap, then move back. There were a few other tricks I used wy back then, as I was using 3 monitors on my Mac G5 Dual tower. Browser screen capture was to set the target window on the main monitor. Jim Ault Las Vegas On Jul 1, 2010, at 3:05 PM, Andre Garzia wrote: Folks, Just tested here, capturing a screen shot from first monitor works fine, capturing an screen shot from the second monitor fails. Can someone try this before I bugzilla it? andre On Thu, Jul 1, 2010 at 6:51 PM, Andre Garzia an...@andregarzia.com wrote: tried, not good... damn.. On Thu, Jul 1, 2010 at 6:50 PM, Andre Garzia an...@andregarzia.comwrote: Scott, do I need something more than a: local tSnapshot to define it? I will try putting empty in there first... On Thu, Jul 1, 2010 at 6:45 PM, Scott Rossi sc...@tactilemedia.comwrote: Recently, Andre Garzia wrote: Just tried this exact piece: set the width of me to presentationWidth() set the height of me to presentationHeight() set the imageData of me to tSnapshot put the rect of stack presentation into tRect export snapshot from rect tRect to tSnapshot as PNG set the text of me to tSnapshot I am receiving this on the message box: Message execution error: Error description: export: no image selected, or image not open Hint: By the way, which Rev version are you using? Here it is 4.5-dp-3 the screenshotable stack is on the second monitor, so the rect looks like: 1472,144,2112,624 Maybe you have not defined tSnapshot earlier in the handler so Rev doesn't know it's an empty variable? Regards, Scott Rossi ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Recently, Andre Garzia wrote: Just tested here, capturing a screen shot from first monitor works fine, capturing an screen shot from the second monitor fails. Can someone try this before I bugzilla it? It does seem that a standard snapshot won't capture beyond the rect of the main display. Anything beyond the main display's rect gets truncated, so if the target rect falls outside the main display rect, Rev is unable to grab anything; if the target rect spans the main and secondary displays, Rev grabs only the portion of the rect that appears on the main display. Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
I consider that a bug and you? will fill a bugzilla report after dinner... On Thu, Jul 1, 2010 at 7:33 PM, Scott Rossi sc...@tactilemedia.com wrote: Recently, Andre Garzia wrote: Just tested here, capturing a screen shot from first monitor works fine, capturing an screen shot from the second monitor fails. Can someone try this before I bugzilla it? It does seem that a standard snapshot won't capture beyond the rect of the main display. Anything beyond the main display's rect gets truncated, so if the target rect falls outside the main display rect, Rev is unable to grab anything; if the target rect spans the main and secondary displays, Rev grabs only the portion of the rect that appears on the main display. Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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 -- http://www.andregarzia.com All We Do Is Code. ___ 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: [BUG] Confirmed, can't capture screen from second monitor (Was Re: [BUG?] Can anyone here confirm that RevBrowserSnapshot works?
Recently, Andre Garzia wrote: I consider that a bug and you? Me tu, Brute. I think Jim Alt provided a workable workaround. Regards, Scott Rossi Creative Director Tactile Media, UX Design ___ 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: Mac Standalone Bug
True, in 4.0 I disabled destroyStack but it still happens. The work around was to write a resizing routine on preOpenStack for all objects to get the to fit correctly within the stack. This slows down the spped at which the stack opens on initial launch but is otherwise unnoticed. - Justin ___ 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: Mac Standalone Bug
That doesn't fix it in 4.0. Bill Vlahos _ InfoWallet (http://www.infowallet.com) is about keeping your important life information with you, accessible, and secure. On Jun 24, 2010, at 10:22 AM, J. Landman Gay wrote: Justin Sloan wrote: Jeff, I do have a menu. Is that the problem? How do I counter it? It's an ancient issue. If you have a menu, make sure the destroystack property of the stack is false. That fixes it. Then rebuild the standalone. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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 ___ 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: Mac Standalone Bug
Bill Vlahos wrote: That doesn't fix it in 4.0. Odd, it's what I usually use. You could try setting the destroywindow to false too. I don't think you need to, but it's all I can think of. You saved the stack after resetting the destroystack, before building, right? Is the checkbox for destroystack NOT checked in the standalone settings? If that's checked, the SB will reset the property behind your back. The horrible, ugly workaround is to hide the stack on preOpenStack, set the height via script, and then show the stack. Bill Vlahos _ InfoWallet (http://www.infowallet.com) is about keeping your important life information with you, accessible, and secure. On Jun 24, 2010, at 10:22 AM, J. Landman Gay wrote: Justin Sloan wrote: Jeff, I do have a menu. Is that the problem? How do I counter it? It's an ancient issue. If you have a menu, make sure the destroystack property of the stack is false. That fixes it. Then rebuild the standalone. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
