Visual LISP, AutoLISP and General Customization
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Default distance + insdie - Offset Lsp

13 REPLIES 13
Reply
Message 1 of 14
Shanskvm
1803 Views, 13 Replies

Default distance + insdie - Offset Lsp

Hi,

How to write offset lsp default  distance and inside.

 

thank in advance.

 

thanks

shanskvm

13 REPLIES 13
Message 2 of 14
pbejse
in reply to: Shanskvm

What do you mean by inside?

 

 

Message 3 of 14
Shanskvm
in reply to: pbejse

I need a lsp. but default distance

Message 4 of 14
pbejse
in reply to: Shanskvm

here's a simple and easy to understand snippet

 

(defun c:def  ()
      (if (not dist)
            (setq dist 1.00))
      (setq dist (cond
                       ((getreal
                              (strcat "\nEnter Distance <"
                                      (rtos dist 2 2)
                                      ">: ")))
                       (dist)))
      )

 

to use include the local command at the end

 

(defun c:dOff  ()
      (if (not dist)
            (setq dist 1.00))
      (setq dist (cond
                       ((getreal
                              (strcat "\nEnter Distance <"
                                      (rtos dist 2 2)
                                      ">: ")))
                       (dist)))
      (command "_offset" dist)
      (princ)
      )

  

You can use Getint/Getstring in place of getreal. but then you need to use the proper function in translating numbers to string. also notice (rtos dist 2 2)? you can use the proper units depending on your current settings. like (rtos 4 2) will give you feet and inches.

 

Hope this helps

 


For a more comprehensive explanation for defualt pormpt
Check out Lee Mac's website found on his signature

Prompting with a Default Option

Message 5 of 14
Kent1Cooper
in reply to: Shanskvm


@Shanskvm wrote:

How to write offset lsp default  distance and inside.

....


I assume you mean that you want a Lisp routine that will let you select an object that has some definable difference between inside and outside, and it will Offset that object by the default distance, to the inside, without the User needing to do anything except pick the object.  If that's correct, here are some thoughts:
 

You would need to have an Offset distance other than "Through" established already.  If the default Offset distance is "Through", there would need to be User selection of a point for the new object to go through, or the routine would need to have a way of making some choice for the User.
 

Feeding the default distance to the Offset command [or a (vla-) version of it] is easy enough.

 

Determining what is "inside" is easy for a Circle, and for an Arc if that is a possibility.  However, for something like a closed Polyline, it can be more of a challenge to find a point that is guaranteed to be "inside" it, because of all the possibilities for shapes of Polylines, and the fact that they can be drawn in different directions.  That question has come up before -- search the Discussion Group history and you'll find several threads about it.

 

However, if you would only be using it on things like Circles and convex closed Polylines [such as rectangles], it would not be difficult to calculate a middle point that would be inside, and use it for the side-to-offset prompt in an Offset command.

Kent Cooper, AIA
Message 6 of 14
Lee_Mac
in reply to: Kent1Cooper

The attached should work for Circles, Arcs, Ellipses, Closed LWPolylines, and Closed Splines.

 

Note that results may be erratic for self-intersecting polylines since the inside/outside is not defined.

Message 7 of 14
Kent1Cooper
in reply to: Lee_Mac


@Lee_Mac wrote:

The attached should work for Circles, Arcs, Ellipses, Closed LWPolylines, and Closed Splines.

....


That (vla-offset) is a great little tool, eliminating the need for User indication of a side or calculation of a point guaranteed to be on a particular side, as long as there's some way of figuring out whether to go positive or negative, like that clockwise-or-not check.  I use it in an Offset-to-both-sides routine, with both the positive and negative values.

 

I was wondering whether that could be made to include "heavy" 2D Polylines [such as originally-LW Polylines that have had Pedit's Fit or Spline option used on them].  Those are at least offsettable, and maybe should be allowed, unlike, say, 3D Polylines which should rightly be excluded.  But they don't have a usable Coordinates Property, so it would require a different way of making the list of points to check for [if I may coin a word] clockwisdom.  It should be doable by building a list with a series of (entnext)'s as long as what that returns continue to be Vertices, because they do have those as sub-entities.  But I wouldn't go to the trouble unless and until the OP indicates a need to be able to do it on such objects.

 

There's also the question of objects for which the offset distance is too great to Offset inward [e.g. equal to or greater than the radius of a Circle or Arc].  If the routine runs into one of those in a selection set, it stops before it gets to later things that it could work with.  But again, the OP would have to say whether that's a realistic possibility for them.

Kent Cooper, AIA
Message 8 of 14
Lee_Mac
in reply to: Kent1Cooper


@Kent1Cooper wrote:

@Lee_Mac wrote:

The attached should work for Circles, Arcs, Ellipses, Closed LWPolylines, and Closed Splines.

....


But they don't have a usable Coordinates Property, so it would require a different way of making the list of points to check for [if I may coin a word] clockwisdom.  It should be doable by building a list with a series of (entnext)'s as long as what that returns continue to be Vertices, because they do have those as sub-entities.


I don't follow your point with regard to the Coordinates Property, unless I am overlooking something?

 

The attached should fix all issues.

Message 9 of 14
Kent1Cooper
in reply to: Lee_Mac


@Lee_Mac wrote:

@Kent1Cooper wrote:

....

But they ["heavy" 2D Polylines] don't have a usable Coordinates Property, so it would require a different way of making the list of points to check for [if I may coin a word] clockwisdom.....


I don't follow your point with regard to the Coordinates Property, unless I am overlooking something?

....


Well, that's curious....  I had found that Splined or Fitted Polylines give a routine the vapors if you use (vlax-get obj 'coordinates) on them. I made a closed Polyline, then used Pedit and the Spline option on it, then tried (vlax-get obj 'coordinates) on that.  I got an error message:

 

; error: AutoCAD.Application: Invalid class

 

When I "dump" the object, I get this among its Properties:

 

;   Coordinates = AutoCAD.Application: Invalid class
 

And the same is true on that one when edited with the Fit option instead of Spline.  And the error message comes up when I use the revised OffInside that allows heavy 2D Polylines on it, and it doesn't Offset it.

 

But experimenting a little, I find that it doesn't always behave that way -- some other Polylines don't have that problem -- and I couldn't tell you what the difference is.  They're all closed, drawn originally as LWPolylines with all line segments, in the WCS XY plane, on the same Layer, even about the same size, and the Offset distance was always small enough for them.  Maybe it has something to do with the particular shape -- the troublemaker has one rather sharper corner than the others, and its original line-segment version has one concave bend -- but it's hard to imagine why that should matter, and OffInside works fine on the un-Pedited line-segment version of it.  I might experiment a little further, later.

 

But to cover for whatever that difference may be, even if it might only sometimes be a problem, one could build a list of the vertices of such an object using (entnext) repeatedly, if it's worth the trouble, instead of using (vlax-get obj 'coordinates), and check that list for clockwisdom.

Kent Cooper, AIA
Message 10 of 14
Lee_Mac
in reply to: Kent1Cooper

I've tried almost every combination of PEDIT's 'Fit' and 'Spline' option on many different shapes of closed LWPolylines, some extremely 'spiky' and I haven't been able to replicate the return of:

 

;   Coordinates = AutoCAD.Application: Invalid class

 

For any of the resultant 2D Polylines. I'm using AutoCAD 2010 to test, with Windows7 32-bit.

 

I would add that I've never not been able to use the Coordinates property for 2D Polylines, and furthermore, I've never had this bug reported whenever I've used the property in my programs...

Message 11 of 14
pbejse
in reply to: Kent1Cooper

and there's me assuming all the OP wants is a lesson in default

 

ohwell 🙂

Message 12 of 14
Kent1Cooper
in reply to: Lee_Mac


@Lee_Mac wrote:

I've tried almost every combination of PEDIT's 'Fit' and 'Spline' option on many different shapes of closed LWPolylines, some extremely 'spiky' and I haven't been able to replicate the return of:

 

; Coordinates = AutoCAD.Application: Invalid class

 

For any of the resultant 2D Polylines. I'm using AutoCAD 2010 to test, with Windows7 32-bit.

 

I would add that I've never not been able to use the Coordinates property for 2D Polylines, and furthermore, I've never had this bug reported whenever I've used the property in my programs...


See whether the attached gives that error for you as it does for me.  It's not the same drawing I was experimenting in yesterday [which I didn't save], but it's about the same shape Polyline.  This time, the Fit one worked, but the Splined one still didn't.  But I also find that if I adjust the shape of the plain Polyline in various small ways, the Splined version of that doesn't cause a problem.  [I'm using ADT 2004, Windows XP Pro.]

 

And yes, pbejse, part of the OP was about using the default Offset value, which is the far easier part of the question than the always-inside part.  If Lee's routine omitted the part asking for the distance, this line later on:

 

                            *dist* (- *dist*)

 

could be replaced with:

 

                            (getvar 'offsetdist) (- (getvar 'offsetdist))

 

Or, something that used the Offset command could do this to answer the distance prompt for the User, accepting the default distance:

 

(command "_.offset" "" ....

 

There remains the question of whether that might be Through at the time, or too great a distance for some selected object(s).  The former could be handled by checking whether OFFSETDIST = -1 for Through, and if so, asking for a distance.

Kent Cooper, AIA
Message 13 of 14
pbejse
in reply to: Kent1Cooper


@Kent1Cooper wrote:
And yes, pbejse, part of the OP was about using the default Offset value, which is the far easier part of the question than the always-inside part.  If Lee's routine omitted the part asking for the distance, this line later on:

 

                            *dist* (- *dist*)

 

could be replaced with:

 

                            (getvar 'offsetdist) (- (getvar 'offsetdist))

 

Or, something that used the Offset command could do this to answer the distance prompt for the User, accepting the default distance:

 

(command "_.offset" "" ....

 

There remains the question of whether that might be Through at the time, or too great a distance for some selected object(s).  The former could be handled by checking whether OFFSETDIST = -1 for Through, and if so, asking for a distance.


 

Thank you for the info kent

 

Silly of me 🙂

 

Message 14 of 14
Lee_Mac
in reply to: Kent1Cooper


@Kent1Cooper wrote:

@Lee_Mac wrote:

I've tried almost every combination of PEDIT's 'Fit' and 'Spline' option on many different shapes of closed LWPolylines, some extremely 'spiky' and I haven't been able to replicate the return of:

 

; Coordinates = AutoCAD.Application: Invalid class

 

For any of the resultant 2D Polylines. I'm using AutoCAD 2010 to test, with Windows7 32-bit.

 

I would add that I've never not been able to use the Coordinates property for 2D Polylines, and furthermore, I've never had this bug reported whenever I've used the property in my programs...


See whether the attached gives that error for you as it does for me.  It's not the same drawing I was experimenting in yesterday [which I didn't save], but it's about the same shape Polyline.  This time, the Fit one worked, but the Splined one still didn't.  But I also find that if I adjust the shape of the plain Polyline in various small ways, the Splined version of that doesn't cause a problem.  [I'm using ADT 2004, Windows XP Pro.]


 

All three shapes worked for me (see the GIF below), so perhaps this is a bug that has been fixed in a version since 2004, or maybe an ADT related bug.

 

OffInside.gif

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost