comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: FG-arithmetic error and moving objects
items: Re: FG-arithmetic error and moving objects

FG-arithmetic error and moving objects
type: item
description: Hi, as already discussed in previous posts, I'm having trouble with annotations on images. I have a minimal example to show three problems. First the example: pro mouseMovetest img = dist(500) tlb = widget_base(/column) wWindow = widget_window(tlb, xsize=500.0, ysize=500.0) widget_control, tlb, /realize widget_control, wWindow, get_value=oWin io = image(img, image_dimensions=[500.0,500.0], current=oWin, margin=0) nPoints = 100.0 points = (2.0 * !PI / float(nPoints-1.0)) * findgen(nPoints) x = 0.5 + 0.2 * cos(points) y = 0.5 + 0.2 * sin(points) pl = polygon(x*500.0,y*500.0, '-b2', fill_background=0, /data, target=io) pl = polyline([0.25,0.75]*500.0,[0.25,0.75]*500.0, '-r2', /data, target=io) end Now the problems: 1) If I select the circle (blue data) and I try to move it, I can only do that for specific mouse positions. These positions are not consistent with the line. Is this a feature or a bug? 2) I cannot move the line at all except if I try to rescale it. Is this a feature or a bug? 3) With the above code I get inconsistent math error messages that I cannot pin down to a specific operation. The errors look like: % Program caused arithmetic error: Floating overflow % Program caused arithmetic error: Floating illegal operand % Detected at IDLITVISDATASPACE::DRAW 2385 C:\Program Files\Exelis\IDL84\IDL84\lib\itools\framework\idlitvisdatasp ace__define.pro % Program caused arithmetic error: Floating overflow % Detected at IDLITVISDATASPACE::DRAW 2385 C:\Program Files\Exelis\IDL84\IDL84\lib\itools\framework\idlitvisdatasp ace__define.pro % Program caused arithmetic error: Floating illegal operand % Detected at IDLITVISDATASPACE::DRAW 2385 C:\Program Files\Exelis\IDL84\IDL84\lib\itools\framework\idlitvisdatasp ace__define.pro And it happens when I move the mouse to about the center of the image and click. *If* it happens once, then it keeps on throwing errors when moving the mouse on the image. Notice that I set: !DEBUG_PROCESS_EVENTS = 0 !EXCEPT = 2 before testing this…
creator: Helder Marchetto
date: 2015-03-03T12:23:55-00:00

Re: FG-arithmetic error and moving objects
type: item
description: After a .reset, I copy-pasted your code and got similar errors, but from the IDLitSymbol object. The error occurs always when I select the image (mouse motion events cause the error), but do not occur for the circle unless I drag it over to the edge of the window (which was hard to do). % Program caused arithmetic error: Floating divide by 0 % Program caused arithmetic error: Floating illegal operand % Detected at IDLITSYMBOL::DRAW 1 /Applications/exelis/idl82/lib/itools/components/idlitsymbol __define.pro The only thing I can image that causes this are the symbols that indicate where stretches and rotates can occur when a graphic is selected. Perhaps the smallness of these symbols within the data space causes the errors? As for the other items, 1) I cannot move the circle unless the mouse is near the outlining selection border 2) I cannot translate the line at all using the mouse (although I can with the Translate method). IDL> help, !version ** Structure !VERSION, 8 tags, length=104, data length=100: ARCH STRING 'x86_64' OS STRING 'darwin' OS_FAMILY STRING 'unix' OS_NAME STRING 'Mac OS X' RELEASE STRING '8.2' BUILD_DATE STRING 'Apr 10 2012' MEMORY_BITS INT 64 FILE_OFFSET_BITS INT 64
creator: Matthew Argall
date: 2015-03-03T13:10:33-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Tuesday, March 3, 2015 at 2:10:36 PM UTC+1, Matthew Argall wrote: > After a .reset, I copy-pasted your code and got similar errors, but from the IDLitSymbol object. The error occurs always when I select the image (mouse motion events cause the error), but do not occur for the circle unless I drag it over to the edge of the window (which was hard to do). > > > % Program caused arithmetic error: Floating divide by 0 > % Program caused arithmetic error: Floating illegal operand > % Detected at IDLITSYMBOL::DRAW 1 /Applications/exelis/idl82/lib/itools/components/idlitsymbol __define.pro > > > The only thing I can image that causes this are the symbols that indicate where stretches and rotates can occur when a graphic is selected. Perhaps the smallness of these symbols within the data space causes the errors? > > > As for the other items, > > 1) I cannot move the circle unless the mouse is near the outlining selection border > 2) I cannot translate the line at all using the mouse (although I can with the Translate method). > > > IDL> help, !version > ** Structure !VERSION, 8 tags, length=104, data length=100: > ARCH STRING 'x86_64' > OS STRING 'darwin' > OS_FAMILY STRING 'unix' > OS_NAME STRING 'Mac OS X' > RELEASE STRING '8.2' > BUILD_DATE STRING 'Apr 10 2012' > MEMORY_BITS INT 64 > FILE_OFFSET_BITS > INT 64 Hi, maybe at the end of the init method of idlitsymbol__define.pro one should change the line: ; Mac sometimes throws floating underflows... to: ; Mac and windows sometimes throw floating underflows, or floating overflow... Cheers, Helder
creator: Helder Marchetto
date: 2015-03-03T13:39:54-00:00

Re: FG-arithmetic error and moving objects
type: item
description: Helder writes: > Now the problems: > 1) If I select the circle (blue data) and I try to move it, I can only do that for specific mouse positions. These positions are not consistent with the line. Is this a feature or a bug? > 2) I cannot move the line at all except if I try to rescale it. Is this a feature or a bug? > 3) With the above code I get inconsistent math error messages that I cannot pin down to a specific operation. As I pretty much expected, your example doesn't work at all in the version of IDL (8.2.3) I have. On the other hand, it doesn't throw errors when I move the mouse. ;-) What it does do, and this made me think I was either going crazy or the coffee was especially strong this morning, is cause faint (you might say subliminal) yellow copies of the circle to appear at random locations in the window, even when I stop moving the mouse! It is one of the damnedest things I've ever seen in IDL. :-) Oh, now as I stare at the window, I occasionally see a cyan version of the line popping into momentary existence, too. This must be what it is like to chase subatomic particles in a bubble chamber. I thought at first this must have something to do with my glasses, but it happens when I hold my head completely still. It is like a memory of the two objects flickering into and out of existence. Fascinating! Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
creator: David Fanning
date: 2015-03-03T14:00:11-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Tuesday, March 3, 2015 at 9:00:15 AM UTC-5, David Fanning wrote: > > Oh, now as I stare at the window, I occasionally see a cyan version of > the line popping into momentary existence, too. Is the line gold and white or blue and black?
creator: wlandsman
date: 2015-03-03T14:07:17-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Tuesday, March 3, 2015 at 3:07:19 PM UTC+1, wlandsman wrote: > On Tuesday, March 3, 2015 at 9:00:15 AM UTC-5, David Fanning wrote: >> >> Oh, now as I stare at the window, I occasionally see a cyan version of >> the line popping into momentary existence, too. > > Is the line gold and white or blue and black? I +1 this! h
creator: Helder Marchetto
date: 2015-03-03T14:15:57-00:00

Re: FG-arithmetic error and moving objects
type: item
description: Sounds like some kind of event loop bug in combination with the FG equivalent of this: http://www.exelisvis.com/docs/DEVICE_Procedure.html#devices_ 517620971_499029 On Tuesday, 3 March 2015 15:00:15 UTC+1, David Fanning wrote: > What it does do, and this made me think I was either going crazy or the > coffee was especially strong this morning, is cause faint (you might say > subliminal) yellow copies of the circle to appear at random locations in > the window, even when I stop moving the mouse! It is one of the > damnedest things I've ever seen in IDL. :-) > > Oh, now as I stare at the window, I occasionally see a cyan version of > the line popping into momentary existence, too. This must be what it is > like to chase subatomic particles in a bubble chamber. I thought at > first this must have something to do with my glasses, but it happens > when I hold my head completely still. It is like a memory of the two > objects flickering into and out of existence. Fascinating! -- Yngvar
creator: Yngvar Larsen
date: 2015-03-03T14:28:26-00:00

Re: FG-arithmetic error and moving objects
type: item
description: > yellow copies of the circle to appear at random locations in > the window, even when I stop moving the mouse! > > Oh, now as I stare at the window, I occasionally see a cyan version of > the line popping into momentary existence, too. Recently, I have noticed that the Symbol and Polyline objects in 8.2 do not obey the refresh state of the window. I can say win -> Refresh, /DISABLE then call the SetData method of a Symbol or a Polyline and the window will update automatically, first at the wrong scaling, then at the proper scaling. Since a version changes of 0.0.1 any time after 8.0 make previous versions of IDL obsolete, I have not brought it up. I have also not brought up the fact that the IDL help pages are not backwards compatible, which is extremely frustrating -- it is impossible to make an Axis() in versions prior to 8.2.2 without scrolling all the way to the bottom of the page and reading "The old LOCATION behavior (with a 3-element vector) is no longer documented, but will continue to work" in the version history.
creator: Matthew Argall
date: 2015-03-03T14:37:52-00:00

Re: FG-arithmetic error and moving objects
type: item
description: Hi Helder, I will bet that Exelis folks are taking notes from this (Hi, Chris!), so I'll add some more to your report. On Tuesday, 3 March 2015 04:23:57 UTC-8, Helder wrote: > Hi, > as already discussed in previous posts, I'm having trouble with annotations on images. I have a minimal example to show three problems. > Now the problems: > 1) If I select the circle (blue data) and I try to move it, I can only do that for specific mouse positions. These positions are not consistent with the line. Is this a feature or a bug? > 2) I cannot move the line at all except if I try to rescale it. Is this a feature or a bug? > 3) With the above code I get inconsistent math error messages that I cannot pin down to a specific operation. The errors look like: > > % Program caused arithmetic error: Floating overflow > % Program caused arithmetic error: Floating illegal operand > % Detected at IDLITVISDATASPACE::DRAW 2385 C:\Program Files\Exelis\IDL84\IDL84\lib\itools\framework\idlitvisdatasp ace__define.pro > [etc.] Here's my setup (Windows 7, same IDL as you): IDL> help,!version ** Structure !VERSION, 8 tags, length=104, data length=100: ARCH STRING 'x86_64' OS STRING 'Win32' OS_FAMILY STRING 'Windows' OS_NAME STRING 'Microsoft Windows' RELEASE STRING '8.4' BUILD_DATE STRING 'Sep 27 2014' MEMORY_BITS INT 64 FILE_OFFSET_BITS INT 64 I do see the problems that you describe (but, as Matthew, from the IDLitSymbol object), and further: if I resize the red line, then things change, and we're now in a 3-D world. I can grab the image and end up rotating the whole space around. What is also revealed then is that the red line is no longer on the Z=0 plane. At the command line (I just pasted the lines from your procedure in there), I can do this: (before resizing red line) IDL> pl.getdata,xx,yy,zz IDL> print,xx,yy,zz 125.00000 375.00000 125.00000 375.00000 0.00000000 0.00000000 (after resizing red line) IDL> pl.getdata,xx,yy,zz IDL> print,xx,yy,zz 125.00000 414.00000 125.00000 180.00000 0.000…
creator: Dick Jackson
date: 2015-03-03T16:52:49-00:00

Re: FG-arithmetic error and moving objects
type: item
description: Dick Jackson writes: > And to David: I'm going to guess that what you're seeing is yellow complementary afterimages. (it's all in your head! :-) Since the world is suddenly interested in our visual system this past week, I'll toss out this barely-relevant (but fascinating) link: > https://en.wikipedia.org/wiki/Lilac_chaser Totally weird. Is it coincidence that the sun is shining and it is snowing simultaneously here? :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
creator: David Fanning
date: 2015-03-03T17:29:59-00:00

Re: FG-arithmetic error and moving objects
type: item
description: > I do see the problems that you describe (but, as Matthew, from the IDLitSymbol object), and further: if I resize the red line, then things change, and we're now in a 3-D world. I can grab the image and end up rotating the whole space around. What is also revealed then is that the red line is no longer on the Z=0 plane. At the command line (I just pasted the lines from your procedure in there), I can do this: > > (before resizing red line) > IDL> pl.getdata,xx,yy,zz > IDL> print,xx,yy,zz > 125.00000 375.00000 > 125.00000 375.00000 > 0.00000000 0.00000000 > > (after resizing red line) > IDL> pl.getdata,xx,yy,zz > IDL> print,xx,yy,zz > 125.00000 414.00000 > 125.00000 180.00000 > 0.00000000 1.7147294 > > That's odd, but it explains why we can suddenly rotate the space. And it's then hard to do any of the usual things with the annotations, and that's when I start seeing the arithmetic errors. (It's a good thing Ctrl-Z works at this point to Undo changes... quite dependably, but not perfectly, I find) > > And to David: I'm going to guess that what you're seeing is yellow complementary afterimages. (it's all in your head! :-) Since the world is suddenly interested in our visual system this past week, I'll toss out this barely-relevant (but fascinating) link: > https://en.wikipedia.org/wiki/Lilac_chaser > > Cheers, > -Dick > > Dick Jackson Software Consulting Inc. > Victoria, BC, Canada --- http://www.d-jackson.com Hi Dick, we've got that bug of the 2d->3d when resizing a line a few days ago: https://groups.google.com/d/msg/comp.lang.idl-pvwave/fmtuiHN 031M/m1tNLK1YJQUJ or if you prefer: http://idl.marchetto.de/bug-and-fix-for-a-2d-image-with-a-li ne-rotates-in-3d/ Thanks to Chris @ Exelis the fix was pretty easy and came quickly! Cheers, Helder PS: looks like I got a FG-bug-magnet under my keyboard... I just keep on bumping onto these sort of stuff.
creator: Helder Marchetto
date: 2015-03-03T20:06:21-00:00

Re: FG-arithmetic error and moving objects
type: item
description: Helder writes: > PS: looks like I got a FG-bug-magnet under my keyboard... I just keep on bumping onto these sort of stuff. > A +1 for this. Cheers, David P.S. Let's just say this is not the most surprising thing I've heard today. :-) -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
creator: David Fanning
date: 2015-03-03T20:20:16-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Tuesday, March 3, 2015 at 9:20:20 PM UTC+1, David Fanning wrote: > Helder writes: > >> PS: looks like I got a FG-bug-magnet under my keyboard... I just keep on bumping onto these sort of stuff. >> > > A +1 for this. > > Cheers, > > David > > P.S. Let's just say this is not the most surprising thing I've heard > today. :-) > > -- > David Fanning, Ph.D. > Fanning Software Consulting, Inc. > Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ > Sepore ma de ni thue. ("Perhaps thou speakest truth.") Hi, frustrated by these errors I just found one workaround and I understood where 4-arrows mouse cursor used to move objects appears. First the (partial) workaround for not being able to move the line. Easy. Just use pg2 = polygon([0.25,0.75,0.25]*500.0,[0.25,0.75,0.25]*500.0, '-r2', /data, target=io) instead of pl = polyline([0.25,0.75]*500.0,[0.25,0.75]*500.0, '-r2', /data, target=io) This only works only partially because now you cannot make the line horizontal or vertical... As for the moving of objects, I realized (and this is obvious with the polygon line) that polygons can be moved when the mouse is on the edges of the minimum bounding box. As far as I'm concerned, point 1) in the original post is clear: it's not a bug, it's a feature. Objects movement respond to the minimum bounding box, not the edges of the polygon. [Note: I switched some months ago to FG graphics. It's easier to make nice plots/images, to save them and I like the idea of not having to handle the movements of complex objects myself. I'm slowly realizing, at my own loss of time, that appearances have tricked me. Direct graphics has been tested for over ... well before I even knew IDL existed. And I have the feeling I'm getting to be the official bug-finder* of FG (I say this without pretenses, only frustration)]. As far as the polyline to polygon fix, I'm not happy with this. I NEED lines to take any direction, including horizontal and vertical. And the arithmetic error can be hidden to t…
creator: Helder Marchetto
date: 2015-03-04T08:44:18-00:00

Re: FG-arithmetic error and moving objects
type: item
description: Helder writes: > And I have the feeling I'm getting to be the official bug-finder* of FG (I say this without pretenses, only frustration)]. The good news is, things have greatly improved. When I had this job, all I could get to work correctly was a simple line plot: http://www.idlcoyote.com/ng_tips/onion.php It's a good job. It will keep you employed for years. ;-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thue. ("Perhaps thou speakest truth.")
creator: David Fanning
date: 2015-03-04T14:40:13-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Wednesday, March 4, 2015 at 1:44:23 AM UTC-7, Helder wrote: > On Tuesday, March 3, 2015 at 9:20:20 PM UTC+1, David Fanning wrote: >> Helder writes: >> >>> PS: looks like I got a FG-bug-magnet under my keyboard... I just keep on bumping onto these sort of stuff. >>> >> >> A +1 for this. >> >> Cheers, >> >> David >> >> P.S. Let's just say this is not the most surprising thing I've heard >> today. :-) >> >> -- >> David Fanning, Ph.D. >> Fanning Software Consulting, Inc. >> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ >> Sepore ma de ni thue. ("Perhaps thou speakest truth.") > > Hi, > frustrated by these errors I just found one workaround and I understood where 4-arrows mouse cursor used to move objects appears. > > First the (partial) workaround for not being able to move the line. Easy. Just use > pg2 = polygon([0.25,0.75,0.25]*500.0,[0.25,0.75,0.25]*500.0, '-r2', /data, target=io) > instead of > pl = polyline([0.25,0.75]*500.0,[0.25,0.75]*500.0, '-r2', /data, target=io) > > This only works only partially because now you cannot make the line horizontal or vertical... > > As for the moving of objects, I realized (and this is obvious with the polygon line) that polygons can be moved when the mouse is on the edges of the minimum bounding box. > > As far as I'm concerned, point 1) in the original post is clear: it's not a bug, it's a feature. Objects movement respond to the minimum bounding box, not the edges of the polygon. > > [Note: I switched some months ago to FG graphics. It's easier to make nice plots/images, to save them and I like the idea of not having to handle the movements of complex objects myself. I'm slowly realizing, at my own loss of time, that appearances have tricked me. Direct graphics has been tested for over ... well before I even knew IDL existed. And I have the feeling I'm getting to be the official bug-finder* of FG (I say this without pretenses, only frustration)]. > > As far as the polyline to polygon fix, I'm not happy with …
creator: chris_torrence@NOSPAM
date: 2015-03-05T16:42:26-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Thursday, March 5, 2015 at 5:42:29 PM UTC+1, Chris Torrence wrote: > On Wednesday, March 4, 2015 at 1:44:23 AM UTC-7, Helder wrote: >> On Tuesday, March 3, 2015 at 9:20:20 PM UTC+1, David Fanning wrote: >>> Helder writes: >>> >>>> PS: looks like I got a FG-bug-magnet under my keyboard... I just keep on bumping onto these sort of stuff. >>>> >>> >>> A +1 for this. >>> >>> Cheers, >>> >>> David >>> >>> P.S. Let's just say this is not the most surprising thing I've heard >>> today. :-) >>> >>> -- >>> David Fanning, Ph.D. >>> Fanning Software Consulting, Inc. >>> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ >>> Sepore ma de ni thue. ("Perhaps thou speakest truth.") >> >> Hi, >> frustrated by these errors I just found one workaround and I understood where 4-arrows mouse cursor used to move objects appears. >> >> First the (partial) workaround for not being able to move the line. Easy. Just use >> pg2 = polygon([0.25,0.75,0.25]*500.0,[0.25,0.75,0.25]*500.0, '-r2', /data, target=io) >> instead of >> pl = polyline([0.25,0.75]*500.0,[0.25,0.75]*500.0, '-r2', /data, target=io) >> >> This only works only partially because now you cannot make the line horizontal or vertical... >> >> As for the moving of objects, I realized (and this is obvious with the polygon line) that polygons can be moved when the mouse is on the edges of the minimum bounding box. >> >> As far as I'm concerned, point 1) in the original post is clear: it's not a bug, it's a feature. Objects movement respond to the minimum bounding box, not the edges of the polygon. >> >> [Note: I switched some months ago to FG graphics. It's easier to make nice plots/images, to save them and I like the idea of not having to handle the movements of complex objects myself. I'm slowly realizing, at my own loss of time, that appearances have tricked me. Direct graphics has been tested for over ... well before I even knew IDL existed. And I have the feeling I'm getting to be the official bug-finder* of FG (I sa…
creator: Helder Marchetto
date: 2015-03-05T20:50:28-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Thursday, March 5, 2015 at 1:50:33 PM UTC-7, Helder wrote: > On Thursday, March 5, 2015 at 5:42:29 PM UTC+1, Chris Torrence wrote: >> On Wednesday, March 4, 2015 at 1:44:23 AM UTC-7, Helder wrote: >>> On Tuesday, March 3, 2015 at 9:20:20 PM UTC+1, David Fanning wrote: >>>> Helder writes: >>>> >>>> > PS: looks like I got a FG-bug-magnet under my keyboard... I just keep on bumping onto these sort of stuff. >>>> > >>>> >>>> A +1 for this. >>>> >>>> Cheers, >>>> >>>> David >>>> >>>> P.S. Let's just say this is not the most surprising thing I've heard >>>> today. :-) >>>> >>>> -- >>>> David Fanning, Ph.D. >>>> Fanning Software Consulting, Inc. >>>> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ >>>> Sepore ma de ni thue. ("Perhaps thou speakest truth.") >>> >>> Hi, >>> frustrated by these errors I just found one workaround and I understood where 4-arrows mouse cursor used to move objects appears. >>> >>> First the (partial) workaround for not being able to move the line. Easy. Just use >>> pg2 = polygon([0.25,0.75,0.25]*500.0,[0.25,0.75,0.25]*500.0, '-r2', /data, target=io) >>> instead of >>> pl = polyline([0.25,0.75]*500.0,[0.25,0.75]*500.0, '-r2', /data, target=io) >>> >>> This only works only partially because now you cannot make the line horizontal or vertical... >>> >>> As for the moving of objects, I realized (and this is obvious with the polygon line) that polygons can be moved when the mouse is on the edges of the minimum bounding box. >>> >>> As far as I'm concerned, point 1) in the original post is clear: it's not a bug, it's a feature. Objects movement respond to the minimum bounding box, not the edges of the polygon. >>> >>> [Note: I switched some months ago to FG graphics. It's easier to make nice plots/images, to save them and I like the idea of not having to handle the movements of complex objects myself. I'm slowly realizing, at my own loss of time, that appearances have tricked me. Direct graphics has been tested for over ... well before…
creator: jimuba
date: 2015-04-16T00:38:00-00:00

Re: FG-arithmetic error and moving objects
type: item
description: On Thursday, March 5, 2015 at 1:50:33 PM UTC-7, Helder wrote: > On Thursday, March 5, 2015 at 5:42:29 PM UTC+1, Chris Torrence wrote: >> On Wednesday, March 4, 2015 at 1:44:23 AM UTC-7, Helder wrote: >>> On Tuesday, March 3, 2015 at 9:20:20 PM UTC+1, David Fanning wrote: >>>> Helder writes: >>>> >>>> > PS: looks like I got a FG-bug-magnet under my keyboard... I just keep on bumping onto these sort of stuff. >>>> > >>>> >>>> A +1 for this. >>>> >>>> Cheers, >>>> >>>> David >>>> >>>> P.S. Let's just say this is not the most surprising thing I've heard >>>> today. :-) >>>> >>>> -- >>>> David Fanning, Ph.D. >>>> Fanning Software Consulting, Inc. >>>> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ >>>> Sepore ma de ni thue. ("Perhaps thou speakest truth.") >>> >>> Hi, >>> frustrated by these errors I just found one workaround and I understood where 4-arrows mouse cursor used to move objects appears. >>> >>> First the (partial) workaround for not being able to move the line. Easy. Just use >>> pg2 = polygon([0.25,0.75,0.25]*500.0,[0.25,0.75,0.25]*500.0, '-r2', /data, target=io) >>> instead of >>> pl = polyline([0.25,0.75]*500.0,[0.25,0.75]*500.0, '-r2', /data, target=io) >>> >>> This only works only partially because now you cannot make the line horizontal or vertical... >>> >>> As for the moving of objects, I realized (and this is obvious with the polygon line) that polygons can be moved when the mouse is on the edges of the minimum bounding box. >>> >>> As far as I'm concerned, point 1) in the original post is clear: it's not a bug, it's a feature. Objects movement respond to the minimum bounding box, not the edges of the polygon. >>> >>> [Note: I switched some months ago to FG graphics. It's easier to make nice plots/images, to save them and I like the idea of not having to handle the movements of complex objects myself. I'm slowly realizing, at my own loss of time, that appearances have tricked me. Direct graphics has been tested for over ... well before…
creator: jimuba
date: 2015-04-16T00:43:36-00:00