If the goal is to work with (entmake), then fine. If it's just to make the Block, the (entmake) approach is obviously hugely complicated. Is there any reason not to just do something like one of these?
(defun C:DotR1H ()
(command
"_.circle" "non" (getvar 'viewctr) 1
"_.hatch" "Solid" "_last" ""
"_.block" "NKT-H" "_non" (getvar 'viewctr) "_last" "_previous" ""
)
(prin1)
)
(defun C:DotR1D ()
(command
"_.donut" 0 2 "_non" (getvar 'viewctr) ""
"_.block" "NKT-D" "_non" (getvar 'viewctr) "_last" ""
)
(prin1)
)I used differentiated Block names to distinguish between them. The first is as described [and could probably have the Circle deleted], the second is a little simpler and should be indistinguishable in use, and I expect uses a little less memory.
@Mesut_Akcan wrote:
Performing operations with the "command" function may be a practical solution for beginners, but sometimes problems may occur when performing operations with the "command" function.
for example;
osnap problems,
Different autocad command parameters in different autocad versions. etc.
Yes, but as you discovered, complications may also arise when performing operations with the (entmake) function ["how many of the DXF code entries do I really need to include?" being one of the big ones]. Osnap problems are easily controlled in (command) functions [as is done in my suggestions]. Certain parameters may change, but usually they involve added options, and spelling out option names as I typically do avoids problems with those. I have never yet had such changes affect routines that I have been using for decades.
But by all means go ahead with (entmake), if it's worth the need for several times as much code to do it that way.
@CADaSchtroumpf wrote:
.... I draw what I want to achieve then I use this little code which returns me the list which I just have to copy and paste into the code ....
The approach you describe ends up using sometimes many more entries than you need to make something. For a LINE, for example, it's enough to include only the DXF 0, 10, and 11 entries -- if you're willing to go with current conditions for the rest, you don't need to include anything for 330 and the couple of 100's [entity stuff], 8 [Layer], 67 & 410 [space], or 210 [extrusion direction]. I expect that some of the (entmake) ingredients in this topic could be dispensed with, without making any difference to the result, and some of the long code could be shortened.
And sometimes it's surprising what's needed. A recent example for me: I had a reason to use [in this case] (entmakex) to make a Polyline, which involved the "basic" ingredients as an initial list, to which was repeatedly (append)ed a changing set of 10 entries for vertices, and a changing number of them. I thought I should dispense with the 90 entry for the number of vertices, since it couldn't be known in the basics list, when the (append)ing of the vertices hadn't happened yet. I assumed it would establish that from the completed list in making the Polyline, just as it establishes things like the Layer if that's not specified. But no -- an entry for that is required, even if it turns out to be different in the end result. Since the most common situation was likely to be 3 vertices, I put in (90 . 3), and that allows the Polyline to be created, even when it is wrong with some other number of vertices (append)ed. Somehow the (entmakex) list can be self-contradictory, but still work.
