I'm gonna give the strongest hints I can on this exercise and it may even turn out to be a solution, so whether you want to read it or not is up to you. I recommend reading it, though!
You already know that you need a center point, and you have also shown that you know how to get it:
(setq pnt1 (getpoint "\nSelect Center Point: "))
Great, we are assuming that the user picked a point so now you have a point saved in the variable
pnt1. We don't want to know what a point is at this point (no pun intended) - it's just a point that AutoLISP knows how to handle.
The exercise states: "Create a new command that asks for a center point, a radius, a starting angle and an ending angle.", so next step is to get a radius from the user. You know now that it can be done with GETDIST - a function that either accepts a number that is typed directly at the command line or it accepts that the user picks two points on screen from which it calculates the distance automatically. Whatever way it gets the distance, it returns it as a number.
However, if the user decides to pick a distance on the screen, we don't want him to actually pick two points. Why? Because we already know the center point and it would be very natural that the user wants to see the center point when he specifies the radius. So, looking up GETDIST in the help reference, we notice that it can take two arguments - both optional:
(getdist [pt] [msg])The msg argument, you already know what is - it's the prompt written to the screen. The other argument, pt, is a point that serves as a starting point for the distance being dragged on screen. So, try to insert the center point,
pnt1, and see what happens. Try this sequence at the command line in AutoCAD:
Command: (setq pnt1 (getpoint "\nSelect Center Point: "))
Select Center Point: [pick a point]
(9.58282 4.83715 0.0)
Command: (setq rad (getdist pnt1 "\nEnter Radius of arc: "))
Enter Radius of arc: [notice the anchor point, the rubber band and go pick a point]
7.02746
Did you notice that GETDIST anchors the first point at the center point that you just specified? Also, it drew a rubber band between the anchor point and your crosshair cursor? This is exactly what e.g. the LINE command uses to draw a line segment; after giving it the first point and the second point, you don't need to specify a first point again if you stay in the command and decides to draw one more line segment.
Now we have code to get the center point and the radius. The latter even with a nice interface that holds on to the center point and draws a rubberband from it:
(setq pnt1 (getpoint "\nSelect Center Point: "))
(setq rad (getdist pnt1 "\nEnter Radius of arc: "))
Next we want a starting angle. GETANGLE works exactly like GETDIST: it either accepts a number typed at the command line or it accepts two points picked on screen. The only difference between GETDIST and GETANGLE is that GETANGLE returns the angle between the points (alternatively the angle typed at the command line) instead of the distance. GETANGLE can also anchor the first point by giving it a point as an argument. The syntax is no different than GETDIST:
(getangle [pt] [msg]) So, we will again make the assumption that the user would want to drag the angle from the center point - that would be a natural way to specify the angle for an arc. We simply supply the center point again and, of course, your nice prompt:
(setq ang (getangle pnt1 "\nSelect Angle of arc: "))
Oh wait, you had already supplied the point in your code?! Good job!
Now we have a center point, a radius and an angle from the center point to the start point. However, we do not know where the start point is. When the user dragged the radius, it didn't need to be the start point of the arc that he specified. Nor is it for certain that he specified the start point when dragging the angle.
If either really was the intended start point, then we have no way of intercepting the point a which he clicked because we used GETDIST and GETANGLE and they do not return a point. But we don't care. Why? Because we have data enough to calculate it!
POLAR takes a point, an angle and a distance. When you have those data, it is geometrically possible to calculate a unique point, and that is what POLAR does. It calculates the point that lies at x angle and in y units from the point. So giving POLAR our center point, our angle and our distance, it spits out the start point of the arc:
(setq pnt2 (polar pnt1 ang rad))
All we have to do now is to start the ARC command through AutoLISP, invoke the right choices in the command and feed it the data. This is where you should run ARC in AutoCAD to make sure that you get the sequence right.
Let's try it and let us use the exclamation mark to call out those variables that we setq'ed previously. First we would want to specify the center point, so in ARC we call the subcommand "CE" to make it accept the center point.
Then we give it the center point and notice that it will want a start point. Oh my, we do have start point! Cool. Give it the start point and then .. umm, then what? Then nothing. Let the user finish the command by letting him specify an end point.
Command: arc
Specify start point of arc or
: CE
Specify center point of arc: !pnt1
(9.58282 4.83715 0.0)
Specify start point of arc: !pnt2
(14.592 9.76599 0.0)
Specify end point of arc or [Angle/chord Length]: [pick an end point on screen]
And there you have a nice arc drawn with the specifications that we asked of the user. Only thing that remains is to write this with the help of the COMMAND function in AutoLISP. Oh, and to arrange all the expressions that we wrote into a DEFUN.
Will you do that, Andre?
