SHCanada2

ok, I see what you would like. There was actually quite a bit of banter going around when this feature came out on how to use it, and a request to CA to auto generate that number. In my example, I have to type in DET A and keep track of B,C, D as to what is the last letter. AFAIK, the request to autogenerate was not implemented....but what was implemented was an x,y, position on layout that allows you to essentially number based on location on layout. It then gets shown back on the plan view. The theory here is that the details on layout would be sequential on the sheet. It does not work for people who want fixed labels for details to be consistent across plans, and those plans have different amounts of details. unless of course if you removed a detail from layout, it left an empty box If you search SHCanada2 as the author or the comment, and search words(search for all words) layout callout macro you should find the thread(s) which talk about this

place a callout on the plan and link to the CAD Detail. It is straightforward if your CAD details are named the same as you want the label to be on layout plan: View name is the CAD detail name

look up: roof baseline polyline same height eaves

did you check this: last page

turns out for this one, the answer is simpler, inline code in the label: %"%schedule_number%"["%schedule_number%".index('W'), 3]% that being said, with the advances in the schedule capability, my two cents is the schedules should not force their schedule number into the schedule_number property of the object. IMHO along with the schedule label options of Use both callout and label, use callout, use label, there should be a fourth: "None" and the good news is this just eliminated my macro which had a global variable which kept track of all the windows and cycled through the hash to find out which were on this elevation and then did the math

thanks, I appreciate it. I'll try a couple more things and may be headed your way. I am interested in general of getting rid of globals as much as possible, and try to limit them to transient purposes

I was looking to convert my macro for unprotected openings on a building face (which is the sum of the windows divided by a drawn pline on the elvation) to a schedule. All seemed good except when I create this new schedule my window labels, which currently have Wxx, now they have Wxx,Gyy as the windows are now on two schedules. I cant seem to be able to configure the schedule to not show the Gyy in the window label., so I wrote a macro to just look for the Wxx in the "schedule_number" and return that to the window label All is perfectly fine for the window label, but the schedule will not return a substring correctly, it either returns "Wxx,Gxx" which is the full string, or it returns EVAL ERROR if I try and return more than the first 2 characters (or it still returns the full string depending on what method I try), or if I return only the first 2 characters, it then returns !! where it should return W0. I tried a few different ways, from i) just using schedule_number[0..2], to ii) assigning it a global var in the label and then returning the first 3 characters from the global, to iii) calling a macro and passing the schedule number to it, to iv) calling an owner object macro. No luck Anyone tried this successfully or know a different way? option ii: I put this macro in the window label: EXAMPLE WINDOW: GLobal variable:%$gsched=schedule_number[0..2]% resulting window label: resulting line in schedule: if I change to EXAMPLE WINDOW: GLobal variable:%$gsched=schedule_number[0..1]% window label is correct (shows W0) but schedule has: I tried fiddling with different types of ruby methods to get substrings, and tried .to_s first before [0..2] and sequencing the calls, but no luck. also tried OIP, no different results. And if someone is wondering why I am assuming the Wxx will be the first and not Gyy, it is because when I first tried to search for a pattern match and get the string out, it would not work, so I started to check character by character and ended up with the above test, and odd results. i.e. If I just ask for $gsched[0] I get ! for the schedule line but $gsched gives W05,G06 for the schedule line, and $gsched[0..4] gives W05,G correctly for the window label, but gives W05,G06 for the schedule line. Basically it works properly for the window label, but the schedule line results do not match the window label its almost like CA is storing a reference to the string somewhere..

the least amount of click solutions is an image printer driver that once installed, allows you to print to image directly from the CA print dialog. I tried out imageprinter pro (I used to have a TIFF driver years ago). and you can easily zoom in to read the text: It is $35 perpetual license with all sorts of image formats. png below

try a image printer driver like imagePrinterpro print driver?

post the plan, something is going on

I share your frustration as I have had similar results...hopefully someone has the answer

Have you searched the forum? there have been a few threads on this in the past couple years

I have my regular window schedule, and my windows have the label: [%schedule_number%] %width%W x %height%H in plan and elevation viewe I have added a new schedule to calculate window area on a specific building face, which means I now have two schedules with the windows. See last few entries here: but now my window labels have both W01 and G0x in their labels. and the macro for schedule_number returns both. Is there a way to not have a specific schedule puts its schedule number against a window, but the other one does? switching it to callout does not help becuase the macro schedule_number always returns both If not I would have to peel out the "Wxx" from the schedule_number in macro closest I found in the sesrch was this: but I do not see a solution thanks

so is the part of the wall still considered "Exterior" that is above the soffit as it is enclosed. or is it part of the attic, or roof, or soffit ... black art of building code interpretation.... which for the 2015 edition (out of force now) had a "companion guide" to help with a consistent interpretation: measured to the ceiling is the winner

my understanding is it stops at the soffit...but that is why I say it is an "opinion" and not a science. All I know is I submit it this way and the DA never complains, but when I first did this macro I had an error and they caught it so for all I know they do it themselves everytime as well and may do it slightly differently