All Activity

@Steven P what do you mean by "startup suit"?

FYI, I used to run the LIST command quite a bit to give me information about the object(s) in question. But with the introduction of the Properties command in AutoCAD 2000, I slowly got used to leaving the Properties window opened/docked in the drawing area. Then as an object is selected, it's "properties" would automatically be filled out for me to inspect inside the Properties window. There's no need to run an extra command sequence like the LIST command which then would have to display the information on on a separate Text screen. In addition, the Properties window makes it possible for you to enter new values into those property items that can be modified.

Just thought of another trick I've used in the past. I would let AutoCAD create a brand new outline of the area to be hatched for me with the Boundary command. But in the Boundary Creation window under Boundary set, do not use the default Current viewport setting. But instead click on the New button and then select only the objects that form the hatch area outline. This restricts AutoCAD to only consider those objects selected to generate the new boundary. Leave the Object type as Polyline and usually with this new Pline boundary generated, the Hatch creation completion success rate would increase just a tad more.

The LIST command is useful when I need to inspect an entity’s properties, such as its coordinates, length, radius, or object type. It can help when a drawing looks correct but I need to verify the actual geometry. However, one limitation is that LIST reports geometric data rather than explaining why an operation failed. For example, if a 3D Boolean operation fails, the LIST output alone may not reveal whether the problem is caused by intersecting geometry, invalid solids, or another modeling issue. When troubleshooting a difficult 3D modeling problem, how far do you rely on LIST before switching to other inspection methods?

Good point. Using the object option can simplify things when the existing geometry already defines a usable boundary.

That’s a smart workaround, especially when you’re up against a deadline! Using a polyline on a nonplotting layer seems much easier than trying to fix every tiny gap in the original boundary.

Breaking a complicated area into smaller sections makes sense, especially when only part of the boundary is causing trouble. Mirroring a hatch across a symmetrical part is also a useful workaround I’ll keep in mind.

Interesting point about different hatch patterns behaving differently with the same boundary. I hadn’t considered that moving the geometry or changing the pattern could sometimes help. It shows that the issue isn't always just the boundary itself.

Green line should follow white curve path instead the duplicating lines are offsetting in opposite direction of curve

After launching VedaCAD and talking with several developers here, I noticed a universal architectural bottleneck we all face in the CAD industry: 99.9% of our custom plugins are strictly local and tightly coupled. Traditionally, if you build a tool that relies on specific external data—like a slide library (.SLB), a steel shape parameter table (.CSV), or a layer standard dictionary (.INI)—you hardcode that data into the .LSP or compile it directly into the .VLX. When a profile dimension changes or a new standard block is added, you have to modify the source code, recompile, and email a new ZIP file to everyone. This rigid "Logic + Data" coupling inevitably leads to a version fragmentation nightmare across an office. The obvious solution is to fetch data from a cloud API on the fly. But as we all know, writing WinHttp requests in AutoLISP is incredibly fragile. Because AutoLISP is single-threaded, waiting for a network response usually freezes the AutoCAD UI—a terrible user experience. The "Pseudo-Cloud" Architecture I realized that with VedaCAD acting as the underlying infrastructure, we can achieve true "Cloud-Native" behavior without writing any network code in LISP, simply by decoupling Logic from Data. Because VedaCAD handles the secure transmission and silent hot-swapping of physical files in the background, you can build tools like this: The Logic (Asset A): You publish your core .LSP plugin. The Data (Asset B): You publish your external data file (e.g., Shapes.csv, Blocks.slb, or Standards.ini). Instead of making risky network calls, your LISP simply reads the local data file from the isolated VedaCAD sandbox directory. To locate the data file dynamically, you can use these two lines of code (AutoCAD example): ;; Find the isolated VedaCAD Plugins and Assets sandbox paths dynamically (setq vc_plugins_path (strcat (getenv "APPDATA") "\\VedaCAD\\AutoCAD_R" (substr (getvar "ACADVER") 1 2) "\\Plugins\\")) (setq vc_assets_path (strcat (getenv "APPDATA") "\\VedaCAD\\AutoCAD_R" (substr (getvar "ACADVER") 1 2) "\\Assets\\")) How the Sync Loop Works (The Magic) Because AutoLISP releases the file handle as soon as you (close) the file, the data is never locked. When the data needs to change, the developer (requires a PRO account to unlock the push-update feature) simply updates the Shapes.csv or Blocks.slb file in their VedaCAD Client. Here is what happens on the users' end globally: For PRO Users: VedaCAD's background engine (24h heartbeat cycle) detects the version drift and silently hot-swaps the data file in the background. The next time the user runs your command, the LISP reads the new datasets instantly. For FREE Users: The engine (72h heartbeat cycle) receives the update beacon. It won't annoy them with popups, but an "Update" card will silently appear in their VedaCAD panel, allowing them to pull the latest data with one click. 5 Wild Possibilities with this Architecture: By relying on VedaCAD to handle the file delivery and background syncing, developers can breathe new life into traditional CAD formats: The "Live" Visual Block Library (.SLB / .DWG): You have a custom DCL with image tiles (slide_name) for inserting standard doors or mechanical parts. By separating the .SLB file, when the company introduces 5 new part models, the admin just pushes a new .SLB and .CSV index. Everyone's visual menu updates automatically the next time they open the dialog, without touching the core LISP. Dynamic Engineering Parameter Sets (.CSV / .XML): A structural plugin that draws H-beams or piping based on manufacturer catalogs. If the manufacturer updates their standard sizes, you just push a new .CSV. The plugin remains lightweight and eternally accurate. Auto-Updating Drafting Standards (.INI / .JSON): A "CAD Checker" routine that reads a dynamic .ini file mapping Layer Name -> Color -> Linetype. As the BIM Manager evolves the company standards, the ruleset updates silently across the fleet. The checker script always enforces the latest rules. Live Quoting / Pricing Engines: A cost-estimation LISP that reads a Prices.csv file to calculate the bill of materials (BOM). The CAD Manager updates the material costs quietly in the background each month. Remote Feature Toggles & Team Kanban: You publish a simple Config.ini. Change ENABLE_BETA=1 to unlock experimental features for your users, or add NOTICE="Server maintenance this weekend", which your LISP prints to the command line upon loading. You can even use a Tasks.txt that pops up a DCL dialog showing the team's drawing assignments for the day. We built VedaCAD to be an invisible infrastructure so that you guys can focus purely on solving engineering problems rather than fighting network protocols, UI freezes, and file locks. Has anyone else experimented with decoupling data from their LISP routines to mimic a cloud architecture? I’d love to hear your thoughts and see what else we could build with this!

@BIGAL Appreciate the thought! I actually went down that exact rabbit hole during early R&D. We deliberately decided against dynamic CUI generation because messing with AutoCAD's menu tree on the fly is a notorious recipe for workspace corruption across different releases. We'd much rather keep VedaCAD strictly as an unbreakable, lightweight delivery pipe (like npm) and leave the bespoke UI craft in the hands of creators like you and Paul! --- @Steven P Definitely not! The VCID is strictly a one-time install code (like an Amazon tracking number). Once installed, you simply type your normal LISP command name in the command line as usual(or the custom shortcut keys you have configured)—zero VCID to memorize!

@Steven P yes email a lsp and a ZIP file, with all the other stuff MNU CUIX lisp's dwg's dwt's etc. If using a server based solution then don't need a ZIP. One thing I did look at was making a custom CUI & CUIX file, they are xml files the later zipped and named CUIX. As mentioned before copy a CUIX rename to zip and have a look inside. Was looking at using Excel to write the menu then convert to XML code -> CUI, CUIX. For a custom mnu just need to work out how to write the XML code. Avoiding the CUI command. @VicoWang maybe have a look at making a CUI would be very helpful.

A lot of times if you use the object option it does better. When I get back to work, I'll see how many old threads are around on hatch and boundary issues.

Some times with very odd shaped boundaries AutoCAD just has a hard time filling it with any hatch pattern. That's when I would break the single hatch area up into different area sections. The boundary would be drawn using a PLINE and placed onto a non-plot layer. This usually resolves the issue. Another solution that worked for me involves odd shaped boundaries that are symmetrical. The hatch area when broken up in half hatches perfectly on the left side but refuse to hatch properly on the right. So I would just create the hatch pattern on the side that works and then mirrored that to the other side.

AutoCAD is terrible at hatching in several ways, that at least usually is reported by BricsCAD users to do better with the same shape(s). Several threads here and other forums of quirks for this and that on hatching. On another forum, someone posted a spline shape that didn't hatch correctly, though I was able to "FIX" it by offsetting it (with delete option) and then offset it back where it was also with delete option), it also worked fine originally with several hatch patterns and failed on a few others, it also had no issues in BricsCAD reportedly. Sometimes zooming in or zooming out and/or moving closer to 0,0,0 works. Sometimes just using a slightly different pattern works better. I mostly use Solid, Gradient, Steel, Aluminum, et. al. made of straight lines and usually they work better in most instances, seldom do I need Earth, Gravel, Sand, etc. which seems to be the type to have issues.

It would still be needing manual tweaking or if by LISP still more coding. As I mentioned above I fixed the sizing portion of the original LISP for lines, I will post that version if getting CENTERMARKS automatically placed is too much for me. I think I actually made one once, it's not a bad idea for most and probably, better than the old manual method. I just never understood why you would have a center crosshair or mark or whatever and it not allow associativity. That's the place where you would dimension a feature with a radius. P.S. for @BIGAL and other Aussies, my grandkids are headed back to the States, leaving today getting back Wednesday evening Eastern USA Time. They had a lot of fun and enjoyed Australia, at least what they saw of it. I may have to head over sometime.

Yes, I already mentioned that. Easy enough to place them manually, but replacing the dimrad/dimdia marks are not as easy as I was hoping, or I am going about it wrong. I set the Layer I create Centermark to Bylayer and the CENTERMARK layer on that with CENTERLTYPE to ByLayer and that issue is fixed. CENTERLTYPEFILE, I think I have a way to detect Metric and change that to acadiso.lin, so that's solved. I have to get it to find the object, since CENTERMARK works by getting the Circle or Arc object. I am thinking about just turning off the Dimrad/Dimdia Mark/Line and placing a CENTERMARK on all circles and arcs in current space or entire drawing, though that would have concentric objects with more than one, so I have to still sort for the largest for correct size. I have the original using lines working better and properly sizing automatically now, but still tweaking, I am leaving the crosshair lines option for older AutoCAD and CAD's that don't have CENTERMARK option.

Please use Code Tags when posting code. (use <> in the Editor) Do you have a drawing with a before and after?

@SLW210 Note - There are several system variables (saved in the drawing) you can change to make the CENTERMARK command behave the way you want: CENTERLAYER = Default Layer CENTERLTYPE = Default LT (can be set to CONTINUOUS) CENTERLTSCALE = Centermark LT Scale CENTERLTYPEFILE = Center LT File used (like acad.lin) CENTERMARKEXE = Centermark Extensions ON/OFF CENTERCROSSGAP = Centermark Cross Gap value (can be relative or hard number) CENTERCROSSSIZE = Centermark Cross Size (can be relative or hard number) CENTEREXE = Centermark Extension Distance

When I run into a situation like this, the complexity or the effort can become too much, especially if there's a deadline. In that case I'll draw a polyline along the border and use that as the boundary for the hatch. Of course the polyline goes on a nonplotting layer.

I’ve said it here before: I never know where I’ll get the inspiration for a Tuesday Tip. This time it came from an old friend and colleague thanks to an interesting LinkedIn post. It demonstrated an alternate method for creating arrays, without using the actual array command. Intrigued yet? Asking why you would do such a thing? As you are aware, there are a lot of controls to create a modern array. Maybe whatever you’re doing doesn’t really require all of those features. It kind of reminds me of a Lambda function in AutoLISP programming, which is an unnamed function that most manuals describe as being used “when the programmer doesn’t need to go to the overhead of creating a full function.” Heh, that’s always stuck with me for some reason. So while you may not use these two methods often, it is kind of fun, and it helps to drive home a couple of points, so let’s get started. Creating a Linear Array With AutoCAD Grips For my two examples, I’ll be using the chair block as found in the Floor Plan Sample drawing. The workflow is pretty simple, and illustrated in the animation below. First, select the block to display its insertion point grip. Select the grip to make it “hot”. Now, recall that hot grips always start with the Stretch command. I’ll click on Copy in the Command Line, and with Ortho on, I’ll pull to the right and specify 1 unit for the grip copy. Here’s a really cool keyboard trick. I press the Control key, and my 1 unit spacing will lock into place, and I can continue clicking to the right to complete my linear array. Creating a Polar Array with AutoCAD Grips Let’s use a similar method to create a polar array. This time, we’ll imagine using our chair block to surround a table with eight equally spaced chairs. I’ll start in the same manner, selecting the block, then selecting its grip. Since I want the chair “array” to go around the table, I’ll type in B to activate the Base Point option, then select the center of the circle using a Center Object Snap. Once that is defined, I want the Rotate option of the grip, so I press Enter to cycle through the available options, stopping when the Rotate option is current. Now, we want to copy our chair, but do it multiple times, so I’ll enter C (copy option) into the Command Line. You’ll see the prompt change from ** ROTATE ** to ** ROTATE (multiple) ** I’ll enter my rotation angle of 45, and the second chair will appear. Now, I’ll again use that handy Control key trick to lock in the rotations, and continue to place the remaining blocks. Granted, these alternate arrays (I think I’ll call them Lambda Arrays going forward) don’t have the cool dynamic functionality of a real array object. “But Frank”, you might also be saying, “my real arrays act as a single object, so it’s easier to copy or move them. These are all individual objects.” I’ve got you covered there too. Just use an unnamed group to turn them into a single, selectable object. Click on the big Group icon in the Groups panel of the ribbon’s Home tab. Select your objects and press Enter. If you decide later that you don’t want them grouped anymore, just click the icon in the panel’s upper right corner, and select any item in the group. A Suitable Ending While these methods may or may not be useful to you, they helped me to show some important concepts. One was to remember to use the options available with Grip editing. Access them via the Command Line, cycle through them with the Enter key, or if you have Dynamic Input turned on, use the arrow down button to see your options. While Stretch is the default for all object types, your other options can differ, so remember to check them out. You should know by now that I’m a big fan of keyboard shortcuts. Don’t forget about using the Control key as described here. Prior to the inspiration that drove this post, I was not aware of it. The final point is this. If you’re just getting started, training from an experienced professional can make a real difference. The author of the original referenced LinkedIn post was none other than one of the most well-known CAD trainers out there. You’ve probably heard of him; his name is Michael Beall. Michael is known as The CAD Trainer Guy, and he’s trained thousands of people over the years on AutoCAD, and chances are, he may have even trained you. Thank you for your continued inspiration, Michael! More Tuesday Tips Check out our whole Tuesday Tips series for ideas on how to make AutoCAD work for you. The post Fun With AutoCAD Grip Options for Arrays: Tuesday Tips With Frank appeared first on AutoCAD Blog. View the full article

(defun c:AUTOHPA ( / objLayer pathLayer objSS pathSS objToArray pathCurve pathLength ) (setvar "CMDECHO" 0) ;; Define your custom layer names here (setq objLayer "V1") ; <-- Replace with your object layer name (setq pathLayer "P1") ; <-- Replace with your path layer name ;; Number of items (setq items 10) ;; Automatically select everything on the object layer (setq objSS (ssget "_X" (list '(0 . "*") (cons 8 objLayer)))) ;; Automatically select the first/only object on the path layer (setq pathSS (ssget "_X" (list '(0 . "*") (cons 8 pathLayer)))) (princ "working01") ;; Check if both selections actually found objects (if (and objSS pathSS) (progn ;; Get the first entity name from the path selection set (setq pathCurve (ssname pathSS 0)) ;; 3. Calculate the exact length of the path object automatically (setq pathLength (vlax-curve-getDistAtParam pathCurve (vlax-curve-getEndParam pathCurve))) (princ pathLength) (princ "working02") ;; Execute the array using the full object selection set (command "._ARRAYPATH" objSS "" pathCurve "M" "M" "I" items pathLength "" "X") (princ "\nArray completed successfully using layers.") ) (princ "\nError: Objects or Path curve not found on the specified layers.") ) (setvar "CMDECHO" 1) (princ) )

I got 80% of the way there with appload in the registry - work got in the way - I'll have to remember to ask you about the other 20% when I get time to go back to that (to add to my single 'upgrade' LISP - page, menus, ribbon, plotter settings all in a single LISP file, emailed to myself, dragged and dropped into the new installation, don't even have to remember where it is saved really)

... lightweight... 800+ in just over 100 files... but most of them are to create a specific piece of kit in the drawing. Remembering - I've stuck to a naming structure which helps a lot (c:txt.... for texts LISPS, c:blk... for block LISPS, c:Z... for zoom LISPS, and so on, and other parts that are common, TT (To Text), CB (Clip Board), 2 (To) so long as I know what I want to do remembering isn't so bad... but also have a DCL 'help' file that will list them all and also list all in a file (Files are similarly named). But yes, without a system I'd be struggling. (as an example, this week I am creating cable long sections, c:LS.... LSProfile to create the profile, LSChainage to add chainage marks to a route, LSPT to add surface points, LSSurface to create the surface, LSSop to add setting out points, LSDepth (LSD) to 'bury' a service at a depth, and so on). All mine are on the OneDrive which is copied to any new computer, I don't need to worry about that, just to add the 3 or 4 I use all the time to the startup suit.. a one off event every 5 years. Update the load on demand, fairly instant for all users in that directory. I tend to use the command line a lot, type in the name, LISP runs, similar to BIG Al, I have struggled to work out how a random 6 digit code translates to my typing the LISP Name in a command bar (and also how I would remember 100+ / 800+ 6 digit codes if I need to type each in for each LISP that I want to run, Do I need to type that in to load a LISP for each drawing?). Seeing comments on Ribbons, I think in my office the ribbon is mostly redundant, takes up valuable screen real estate!