Leaderboard
Popular Content
Showing content with the highest reputation on 06/09/2021 in all areas
-
(defun convertDDms (n) (strcat (rtos (fix (setq n (abs n))) 2 0) "d " (rtos (fix (setq n (* (- n (fix n)) 60))) 2 0) "' " (rtos (* (- n (fix n)) 60) 2 2) "\"" ) ) If negative doesn't matter, you can avoid all the 'abs' by setting it in the beginning first.1 point
-
The error isn't with convertDDdms its most likely here in the function ade_projptforward when it sets the lat and lon (while (not (setq pnt (getpoint "\nSelect a point: ")))) (progn (setq ll (ade_projptforward pnt)) (setq lat (car ll) lon (car (cdr ll)) ) my guess its setting them as strings and not integers or doubles because that error is saying "40" isn't a number. "40" is a number to humans but its in string value so the program cant add, subtract, multiple, or divide it until you convert it into an real Test the following and see the difference ; Convert Decimal Degrees to dms. (defun convertDDdms (x1 / deg mins sec) (setq deg (rtos (fix X1) 2 0) ;- degrees mins (rtos (abs (fix (* (- X1 (fix X1)) 60))) 2 0) ; - minutes sec (rtos (abs (* (- (* X1 60) (fix (* x1 60))) 60)) 2 2) ;- seconds ) (strcat deg "d " mins "' " sec "\"") ) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun c:CooWnumbers (/ as_cor ll lat lon pnt) (setq lat -82.16197462765378 lon 56.07939295460651 ) (alert (strcat "Conversion:" "\n " "\nLatitude:" (convertDDdms lon) "\nLongitude: " (convertDDdms lat) "\nHorz Datum: NAD83" ) ) (princ) ) (defun c:CooWstring (/ as_cor ll lat lon pnt) (setq lat "-82.16197462765378" lon "56.07939295460651" ) (alert (strcat "Conversion:" "\n " "\nLatitude:" (convertDDdms lon) "\nLongitude: " (convertDDdms lat) "\nHorz Datum: NAD83" ) ) (princ) )1 point
-
Nope, can't do it that way. Annotative dimensions were invented to avoid that sort of thing. You are going to have to turn your dimensions into drawing objects and scale them manually for that, or use multiple dimension styles for the different scales. annotative scaling doesn't do that.1 point
-
One shop I worked with had one non-annotative dimstyle for each individual scale in the default scale list, and made up a new one if they needed a custom scale. That adds up to a minimum of 16 different text styles multiplied by mtext and leaders which is 48 styles. Then you get into user blocks for custom leaders.... >>gasp<< One immediate problem with that is, the text height for each style was never exactly accurate. Then you have template maintenance. In reality, most shops use about four or five non-annotative dimstyles, still too many. Custom scales are as big a mistake as dimension distance overrides. I have been told at more than one interview that discipline would be handed out if caught overriding dimension distances. I add content overrides all the time, but never change the actual distance, example 48'-0" CLEAR. Annotative scaling was developed to alleviate the PROBLEM of multiple annotation styles. I have used annotative style since 2007 when I first discovered its existence and never really had any difficulty with it after the learning curve was defeated. For years now, I have used one text style, one dimstyle and one basic leader style. There are other leader styles using attached blocks, but the blocks use the same text style. If annotative styles are not your bag, you can always put your dimensions and leaders in paperspace where one style can work for you. I have worked directly with several interior designers. That should be self explanatory why paperspace dimensions are not feasible for me. If not, this will be. Recently I worked with Flitty Flighty Schisms Are Us Designers of Orlando Inc. They regularly sent me extensive revisions after I submitted a project for approval. At that point I should be getting back APPROVED AS NOTED at the worst. Instead I get back floorplan redesigns, and no real redlines of the submission, nor addressing of outstanding RFI's, nor an acceptance that drawing time will increase. "Well, yes. Shortening the break room by nine feet will effect the custom cabinets along that wall that you have just forced into an "L" shape." They will do this three or four times during a project, often after final shop drawing approval, thus generating thousands of dollars of change orders. This firm has gotten into an actual argument with the architect about where a sawbucks coffee machine needs to be, resulting in redraws and re-redraws of the same changes. How they find clients willing to suffer through that sort of thing is beyond me. They were the reason I finally completely retired. If there are any interior designers in the audience, please don't be offended, but you know who you are. Multiple changes can render paperspace dimension associativity useless, especially if something is moved all the way out of the viewport. I've had them end up looking like a shotgun blast through a birds nest. So, I have not used paperspace dimensions routinely for many years.1 point
-
To clarify, the issue of user overrides, specifically, is problematic for annotative scales for a few reasons. For one, it isn't always easy to tell which objects have had user overrides applied and which haven't. Especially when you have hundreds of annotative objects in a drawing all on a multitude of various layers. Another problem is if someone manually applies an annotative scale (aka user override) to a specific object it will no longer rescale to correspond with the viewport scale on the other viewports because the user override takes precedence. Which kind of defeats the purpose of having annotative scales in the first place - annotative scales more or less being created with the intent of having an automated scaling system (letting you create 1 object instead of multiple objects on different layers specifically for other viewports). Then, if someone applies those user overrides and copies that object hundreds of times, it makes editing/changing anything much more difficult - Which, altogether, defeats the purpose of having styles. The idea is that if you want to change something about an object's style, you can tweak the style, click apply and it will change the properties of all of those objects of that style at one time and it will apply throughout your drawing to all objects of that style (dimensions, multileaders, etc..) Making your life easier. But user overrides create a roadblock that prevents you from easily being able to change those objects all at one time. Which basically just creates more work for you that doesn't need to be there. Dimensions are one example but there are many. Annotative scaling is just another thing that someone can override thinking they are doing the right thing. And may also be why your objects are not scaling properly in your example. -ChriS1 point
-
Yeah annotative scaling has its own advantages and disadvantages. This is one big reason I almost never use annotative scaling. It does have its uses but more often than not, at least for me, it's just too obnoxious. The idea is that if you have, say, 3 different viewports on a sheet tab, all 3 with different scales, an object like a dimension can show up scaled properly in all 3 viewports (just as an example). The annotative scale of the object becoming tweaked to correspond with the viewport's scale. There are potential issues with this, however, that simple rescaling of the object doesn't always resolve. And it also can pose some extremely obnoxious strangeness. Especially when you get into a DWG where people have implemented tons of user overrides and you have like 600 layers. -ChriS1 point
-
Annotation scale in model space does not affect the size of your objects. It does change the size of your dimension text and arrowheads, IF you have different scales assigned to each one, not all assigned to each one as you have yours. The annotation property is only an assignment attached to your dimensions. ALWAYS DRAW FULL SIZE. Like Cyberangel says, you have to use viewports in paperspace to get annotative dimensions to work. Do not try to set up scaled objects in modelspace. That's why paperspace layouts came to be. I've never done it and never will. A lot of shops will frown upon scaling objects in modelspace to the point of handing out disciplinary actions. Another thing, if you set ANNOALLVISIBLE to zero, the dimensions that do not have the same property as the modelspace current annotation scale will disappear in modelspace and only be visible in the viewport with that scale. Toggle the current modelspace annotation scale back and forth between 1:2 and 1:1 in the version of your drawing that I attached here to see what I mean. The dimension will change size because it has more than one scale. The way you had it before with two dimensions and two scales each caused no difference to show up. Needing only one object and one dimension was the whole point of inventing annotative dimensions in the first place. More than one viewport per layout is just fine also. They don't have to both have the same scale applied, and the drawing can be presented in more than one viewport, each with a different scale. I think you can go up to 24 viewports on one layout. Did you know you can apply annotative scaling to text, mtext, dimensions, leaders and blocks? Here's your drawing back. One object, one dimension, two viewports, two different scales on layout1. This is the only way it works. You can add more scales to these dimensions too, if needed. Test.dwg1 point
-
1 point
-
1 point
-
No code but an idea using Nentsel you can pick the attribute and get its value and tagname, you can also get the actual block id required for a field. Two options just put current att value in leader, or it must be a field in case changed, the 1st is simple, 2nd a bit harder. Need some time.1 point