Topic: Linetype scale

[2e4lite]

   I has been trouble  in the  linetype scale all along .  Those of some lines such as CENTER and DASH  shown with continuous. The length of objects have a large range in a drawing .So I want  a lisp routine that can automatically adjust it using the proper  scales according  to the length of  every object for the whole drawing . It will go a long way in my work . How to acheive it?

[snownut2]

Why not start by doing a little searching on here, Google and the other CAD sites....

[2e4lite]

I 've done it ,but some  lisp routines  are not to adjust the  scales  by  length,it is different from what I want.

[Kerry]

Computer programs need rules.

To achieve what you want : What are the rules, exactly ?

[2e4lite]

 Thanks to Kerry, Perhaps the words have a distance . I just want to achive the result like the following attachment.(ps: It also effect to block)

[Kerry]

Great pictures, but what are the rules ?

What LineTypeScale do you want to use for different length lines ?
Does your setup change the global LTSCALE variable depending on DIMSCALE for the document ?
Can we assume you want to select the lines to modify ?

[2e4lite]

   Under the result premise ,You can have a think to the rules.Whatever LineType scales will to be set , I think , It is good as long as it can be easily distinguish between non-continuous and continuous shown on computer and in drawing sheet .It seems not change the global LTSCALE variable depending on DIMSCALE for the document .We usually draw the plant using the scale of 1:1 . the DIMSCALE and ltscale are set 1 in general . It is required to have two chooses to modify the non-continuous for users: to modify the whole drawing automatically (default) and to give ranges in the drawing to modify automatically.

[Kerry]

OK, so you want to set the individual LinetypeScale property for specific objects.

What LineTypeScale do you want to use for different length lines ?

[2e4lite]

Yeah...

[Kerry]

The path to quality software begins with excellent requirements. Slighting the processes of requirements development and management is a common cause of software project frustration and failure.

[dgorsman]

The path to quality software begins with excellent requirements. Slighting the processes of requirements development and management is a common cause of software project frustration and failure.

My version: code is the end result, not the starting point.

[irneb]

You could try this I suppose

Code - Auto/Visual Lisp: [Select]

1. (defun Get-Entity-Linetype  (eObj / lt)
2.   (if (wcmatch (strcase (setq lt (vla-get-LineType eObj))) "BYLAYER")
3.     (cdr (assoc 6 (tblsearch "LAYER" (vla-get-Layer eObj))))
4.     lt))
5.  
6. (defun Get-LineType-Pattern-Length  (ltName)
7.   (apply '+
8.          (mapcar '(lambda (c)
9.                     (cond ((= (car c) 49) (abs (cdr c)))
10.                           (t 0)))
11.                  (tblsearch "LTYPE" ltName))))
12.  
13. (defun Set-Entity-Min-LtScale  (eName / eObj len ltlen)
14.   (vla-put-LinetypeScale
15.     (setq eObj (vlax-ename->vla-object eName))
16.     (if (< (setq len (vla-get-Length eObj))
17.            (setq ltlen (Get-LineType-Pattern-Length (Get-Entity-Linetype eObj))))
18.       (/ len ltlen)
19.       1.0)))
20.  
21. (defun c:SetMinLtScales  (/ ss n)
22.   (if (setq ss (ssget '((0 . "LINE"))))
23.     (repeat (setq n (sslength ss)) (Set-Entity-Min-LtScale (ssname ss (setq n (1- n))))))
24.   (princ))

Should work for Lines. Might need a bit more for other types of objects (e.g. circles / arcs / polylines / etc.)

[irneb]

You could try this I suppose

Code - Auto/Visual Lisp: [Select]

1. (defun Get-Entity-Linetype  (eObj / lt)
2.   (if (wcmatch (strcase (setq lt (vla-get-LineType eObj))) "BYLAYER")
3.     (cdr (assoc 6 (tblsearch "LAYER" (vla-get-Layer eObj))))
4.     lt))
5.  
6. (defun Get-LineType-Pattern-Length  (ltName)
7.   (apply '+
8.          (mapcar '(lambda (c)
9.                     (cond ((= (car c) 49) (abs (cdr c)))
10.                           (t 0)))
11.                  (tblsearch "LTYPE" ltName))))
12.  
13. (defun Set-Entity-Min-LtScale  (eName / eObj len ltlen)
14.   (vla-put-LinetypeScale
15.     (setq eObj (vlax-ename->vla-object eName))
16.     (if (< (setq len (vla-get-Length eObj))
17.            (setq ltlen (Get-LineType-Pattern-Length (Get-Entity-Linetype eObj))))
18.       (/ len ltlen)
19.       1.0)))
20.  
21. (defun c:SetMinLtScales  (/ ss n)
22.   (if (setq ss (ssget '((0 . "LINE"))))
23.     (repeat (setq n (sslength ss)) (Set-Entity-Min-LtScale (ssname ss (setq n (1- n))))))
24.   (princ))

Should work for Lines. Might need a bit more for other types of objects (e.g. circles / arcs / polylines / etc.)

And you'd need to accommodate for the global LTScale factor, or even the paper-space factor (if PSLTSCale=1) or even worse - what about AnnoScales?

[Kerry]

< .. >
And you'd need to accommodate for the global LTScale factor, or even the paper-space factor (if PSLTSCale=1) or even worse - what about AnnoScales?

Yes.

And there is still my original question .. What individual LTScale will be used for differing line lengths.
And he'd need to consider several different line types and variation in stroke length within each basic type.

The actual code is pretty basic ... setting the rules is where the work needs to be done.

It astounds me that anyone can ask [us] to code a routine like this and is not prepared to do the work involved in actually explain what is required.

Some problems are interesting in themselves technically and are worth spending the time on, but I really hate wasting time trying to extract basic design data related to the problem.
I see it all too often and it continues to piss me off.

[tedg]

..
It astounds me that anyone can ask [us] to code a routine like this and is not prepared to do the work involved in actually explain what is required.

Some problems are interesting in themselves technically and are worth spending the time on, but I really hate wasting time trying to extract basic design data related to the problem.
I see it all too often and it continues to piss me off.

I'm not sure the op got the hint ....
 
"Hey 2e4lite, can you respond with a clear explaination of what you would like for the rules for this program to run under, and maybe you could get some help here?"

[2e4lite]

   Thank you all very much for your attention and I apologize for my late reply.  irneb,The method of your code is nice . In fact , There is just a feeling about the scales to me, many changes and condition . Luckily, I had resolved it by myself in the end with a long time .

[irneb]

And there is still my original question .. What individual LTScale will be used for differing line lengths.

At a guess I'd say the object ltscale should be 1.0 for all objects longer than the linetype's pattern-length. And the (segment-length ÷ pattern-length) for all objects shorter. That should display at least one set of dashes & dots no matter how long a line is. But these lengths are affected by 3 things:

• The global LTScale value, only if 1.0 doesn't it affect anything
• If the PSLTScale = 1, then the viewport's zoom factor affects linetype pattern lengths. Then what about the situation where the line is visible in 2 / more VPs at different zoom factors? Should the widest zoom be used to calculate this, or would that start looking weird?
• If using Annotative Scaling, is the MSLTScale = 1. Is the viewports set to a CAnnoScale? Then the same principles apply as per (2) above.

And as mentioned, this only applies to lines. Some more needs to be done for other objects. E.g. what about polylines ... they could have short sectors, but their object LTS is set for the entire PL - should LTGen be turned on for these? Things like blocks may even throw another spanner into the works with their own scale factor per instance. It can get to a very complicated permutation of scaling factors, 2 or 3 levels deep. There are probably other issues which may need further clarification, but I can't think of much more for now.

So yes, the OP needs to answer some questions before any further coding could be written. The code I posted is simply a starting point to show what "can" be done.

I've found that usually when making an addon / full program you always start with these incomplete specifications. It's very seldom that an OP / boss / client has a complete idea regarding what they actually want. It's usually some vague notion of "Can such be done?" And as something gets developed it then also fleshes out the spec, since only once they notice how things intertwine do they realise what they're after.

The previous paragraph is my most important reason for encouraging any poster to start learning to make these things for themselves. Much easier and faster to do something exactly as you want it instead of trying to explain to someone else about something you (and possibly them too) hardly understand.

   Thank you all very much for your attention and I apologize for my late reply.  irneb,The method of your code is nice . In fact , There is just a feeling about the scales to me, many changes and condition . Luckily, I had resolved it by myself in the end with a long time .

That's great! This is the best way of going about it ... doing it yourself or modifying something to suit your needs.

Could I just request that you post your solution here? For others who may have similar problems in the future?