I mention this because I seem to often make errors when dealing with ArcShape.
There is a concept in trigonometry of “standard position” when discussing angles/arc.
When you speak of a 45° angle conventionally you are speaking of an arc that starts at 0° (pointing to the right on the positive x axis) and extends 45° counterclockwise from this start position. This arc “points”, as it were, up and to the right.
In Xojo, the ArcShape is defined in what I consider a “peculiar” way. You specify a StartAngle and an ArcAngle. The StartAngle is by default 0° [in Xojo these are expressed in radians so that is 0 radians]. That is in line with the “standard position” of trigonometry.
But if the ArcAngle is 45° (in radians Pi / 4) you will be specifying an arc that is clockwise from that zero position. This arc “points”, as it were, downward and to the right.
I don’t understand why Xojo adapted this convention of “clockwise” rotation when most of the trigonometry world adheres to a different one. But it is something to look out for.
The Documentation only explains things in Notes at the end where it is easily missed. It does not emphasize that its decision is “unconventional” in the context of trigonometry. It is in accord with how positive angles are considered with other Object2D entities.
The example for StartAngle offers:
Var a As New ArcShape
a.Height = 150
a.Width = 150
\\ a.Rotation = 0.90
a.ArcAngle = 1.57
a.StartAngle = -1.57
a.BorderOpacity = 100
a.BorderColor = Color.Black
a.BorderWidth = 2.75
a.FillOpacity = 50
a.FillColor = Color.Red
g.DrawObject(a)
The 1.57 is radians for 90°. Throw out the Rotation line that just works to confuse the example. This relates in a 90° arc oriented up and to the right. With the 90° negative start angle, this is not what I would have anticipated from the standard conventions of trigonometry.
I contribute this because I wasted a lot of time stumbling around with “unexpected” results. Perhaps I can save someone else this frustration. At the very least, the Documentation on this issue should be expanded.
I guess this is because the Y is upside down on the screen compared to a paper we use in the real world.
On the screen (a Xojo window for example) X, Y at 0, 0 is top left, and Y positive goes down. On a paper you can set 0, 0 at bottom left and Y positive goes up.
If you see the results of your code by ‘flipping’ the result vertically, then it match the paper.
But still this difference (paper vs screen) would be worth being mentioned in the documentation. I remember months ago having the exact same frustration and learning path as Robert.
Shapes are a mess IMHO and I’ve ended up writing all my own replacements for splines, arcs and the rest.
Issues:
Angles do not conform to basic high-school conventions;
The anchor point (X,Y) is unnecessary vs the coordinate to draw the graphic,
Lacks fundamental events like mouseDown, MouseUp;
Needs options to show the control points when drawn,
Needs a “clickedOn” event when a mouseclick was on the line of a curve or polygon, within say +/- 3 pixels;
Needs a “clickedWithin” event, when a mouseclick was within the line of a curve or closed polygon;
Needs to expose a “y = f(x)” function to return the y coordinate for an arbitrary curve or polygon given an x value, though this gets tricky when it can be multi-valued.
Needs an event when a control point was dragged, as distinct from the object.
Needs functions to JOIN or TRIM arcs/polygons to line intersections and produce a new object. For example, try drawing a cloud icon using Xojo curves which is resizable, draggable, and has a couple of control points - it is painful. Yet it’s easy as a bitmap.
The geometry of line endpoints and intersections has to be looked at, ie square ends or rounded end, what to do when lines join at a right angle (avoiding “staircasing”), etc.
The lack of these leaves me thinking nobody used vector graphics in Xojo much, and what we have was ill-conceived.
Go take a good look at PowerPoint, for starters. Over many years I’ve implemented much of what PPT does, in Xojo, but it’s all drawn as bitmaps. Not a vector anywhere.
And no I will not share the source so please don’t ask.
I use Shapes extensively and find them very useful and preformant. As the original poster, I was confounded by ArcShape’s StartAngle and ArcAngle because when visualized in a canvas, the results, for me , were confusing, and I thought unconventional. But Alberto provided the explanation. It is due to the fact, common to computer graphic conventions, that Y is “upside down” in a canvas. For me, this was much easier to understand and deal with when I was drawing lines and ovals and such, but the ArcShape caught me by surprize, and I had difficultly grasping all the issues.
I heartily second Arnaud’s comment that the documentation should be expanded to help the user grok the issues around this Shape.
It is helpful to know that the transformation that you need when going from paper to a canvas on screen is to transform the StartAngle and ArcAngle from how you would specify it on paper to its screen equivalent.
StartAngle_screen = 2π - StartAngle_paper (2π is the radians version of 360°)
ArcAngle_screen = - ArcAngle_paper
Once you utilize these simple conversions then things go pretty smoothly. You can conceptualize your graphics mentally and on paper with the conventions that you are familiar with and then convert StartAngle and ArcAngle in such a way as to display on screen as you expect.
I am not sure what this point is. The anchor point is necessary if you want to rotate a graphic object around something. I also anchor points to implement in my own code some of the functionality that Nicholas refers to. Taking clicks on the canvas and interpreting their “meaning” relative to the graphic objects on the canvas. This imposes work on the programmer, but allows flexibility when dealing with issues like overlapping graphic objects.
I deal with modifiable Bezier curves and it would be nice, as per Nicholas, if there was more “built-in” help in the graphic object. You end up having to to a lot of coding.
Nicholas has moved to bitmaps. I have stayed with vector shapes and find them extremely useful. Diversity of opinion. . And am currently rewritting a project from 2005 that did not use Graphic2D shapes, I was doing everything “manually” with a multitude of “lines” often small enough to create curves. The subsequent introduction of CurveShape (with Bezier), ArcShape etc. has been fantastic for my application.