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 this. I NEED lines to take any direction, including horizontal and vertical.
>
> And the arithmetic error can be hidden to the user, but it is still suspicious of something going badly wrong.
>
> Cheers,
> Helder
Hi Helder,
Don't give up!
Regarding your issues, the main problem is that we purposely limited the translation, scaling, and rotation when annotations are in the dataspace. The assumption is that if your annotation is in "data" coordinates then you don't want it to move. Perhaps we need to re-think this limitation...
Regarding the floating-point arithmetic errors, *sometimes* these are legitimate errors but most of the time they are just harmless noise that can be safely ignored. There are lots of places in the graphics code where a number will get rounded off to zero, or some calculation will make another number go to Infinity or NaN, and then IDL will dutifully report the exception. If you look through the graphics pro code, you will find many instances where we just quietly swallow those. So unless you actually see some visual "badness", I would just ignore them.
Cheers,
Chris
Exelis
p.s. keep posting your questions and feedback. We really do listen!
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
