Lee Mac Posted April 15, 2009 Author Posted April 15, 2009 Also for some reason the text angle changes in the middle of executing the program... :confused: Text angle changing? Middle of which part? Quote
Lee Mac Posted April 15, 2009 Author Posted April 15, 2009 Very nice, Lee. You know what would make a program like this truly powerful? In addition the current option which creates new text, an option to edit existing text (or attributes). Yes, CAB's Incremental Numbering Suite does this - but it takes a lot more coding to recognise the numbers within existing text I suppose I could add one that replaces existing text/attributes, but to edit it may be hard. Quote
Lee Mac Posted April 15, 2009 Author Posted April 15, 2009 OK, this version includes a Replace Text/MText/Attribute Option Just type "R" or "r" during text placement. Quote
The Buzzard Posted April 15, 2009 Posted April 15, 2009 Lee, When I edit an attribute it works fine until you select outside the attribute and the numbers are inserted on a slight angle. Also please see my previous post about the zero's in the suffix unless you did spot this (I am not sure). Thanks, The Buzzard Quote
The Buzzard Posted April 15, 2009 Posted April 15, 2009 Forget about the angle thing. I see what I did wrong. Quote
Lee Mac Posted April 15, 2009 Author Posted April 15, 2009 When I edit an attribute it works fine until you select outside the attribute and the numbers are inserted on a slight angle. I can't seem to replicate this... if you select outside the attribute, surely it will just exit the "replace text mode" and return to just standard placement? Also please see my previous post about the zero's in the suffix unless you did spot this (I am not sure). Yes, thank you for this suggestion, I apologise for not replying - I am just thinking of the best way to implement it. Quote
Lee Mac Posted April 15, 2009 Author Posted April 15, 2009 Forget about the angle thing. I see what I did wrong. No problem Quote
Lee Mac Posted April 15, 2009 Author Posted April 15, 2009 Ok, sorry for all these new versions - but just added the facility to use Leading Zeros on the incrementing text Quote
The Buzzard Posted April 15, 2009 Posted April 15, 2009 Perfectionists have nothing to appologize for. Quote
The Buzzard Posted April 15, 2009 Posted April 15, 2009 Lee, This is the greatest thing since the invention of the sandwich. Now we can all eat our words and like too. Quote
Lee Mac Posted April 15, 2009 Author Posted April 15, 2009 Lee, This is the greatest thing since the invention of the sandwich. Now we can all eat our words and like too. Thanks Buzzard It still can't edit existing text, but I think I shall have to leave that task to CAB - as I said earlier, it takes a ton more coding But I am happy with this one so far Quote
uddfl Posted April 16, 2009 Posted April 16, 2009 I'd like to second The Buzzard's praise. Only one question: is it really necessary to regen after editing the text/attribute? Can't entupd be used? Quote
Lee Mac Posted April 16, 2009 Author Posted April 16, 2009 I'd like to second The Buzzard's praise. Only one question: is it really necessary to regen after editing the text/attribute? Can't entupd be used? I find entupd very unreliable - whereas a regen 9 times out of 10 works. Quote
Lee Mac Posted April 16, 2009 Author Posted April 16, 2009 As quoted from the ACAD help file: Note: If entupd is used on a nested entity (an entity within a block) or on a block that contains nested entities, some of the entities might not be regenerated. To ensure complete regeneration, you must invoke the REGEN command. Quote
Lee Mac Posted April 16, 2009 Author Posted April 16, 2009 A minor update - fixes an issue brought to my attention when using decimal increments. Although this now relies on values of LUPREC, LUNITS, UNITMODE and DIMZIN (something to bear in mind). Quote
MikeP Posted April 16, 2009 Posted April 16, 2009 is there a work around so that it wont rely on the units maybe it can read the number of decimals you want in the increments box. and temporarily set the units to be that much. then once the command is finished it restores back to original. Quote
Lee Mac Posted April 16, 2009 Author Posted April 16, 2009 is there a work around so that it wont rely on the units maybe it can read the number of decimals you want in the increments box. and temporarily set the units to be that much. then once the command is finished it restores back to original. I suppose I could do something like this, although you may end up with results say, with an increment of 0.5 of: 1.0, 1.5, 2.0 instead of 1, 1.5, 2 Quote
The Buzzard Posted April 16, 2009 Posted April 16, 2009 Hey Lee, There goes your leading zero fix. I enter a prefix: 01, middle: N, and suffix: 001 and end up with 01N001 01N2.0000 01N3.0000 01N4.0000 and so on. Can the decimal add-on be made to an option with a toggle or something? The Buzzard Quote
The Buzzard Posted April 16, 2009 Posted April 16, 2009 I just found that I would need to set my units precision to 0 for it to work correctly. I think setting it up as an option would be better. What are your thoughts on this Lee? Quote
MikeP Posted April 16, 2009 Posted April 16, 2009 I suppose I could do something like this, although you may end up with results say, with an increment of 0.5 of: 1.0, 1.5, 2.0 instead of 1, 1.5, 2 no never mind. the last version was even better. It just depends on how you enter the info in. to create 1.1 - 1.2 - 1.3 - 1.4 and so on. Just enter "1." into the prefix. then, "1" into the middle, then use "1" as an increment. this will cause it it say "1." "1" = 1.1 - 1.2 - 1.3 hope that makes sense. you can still do anything like "Item 1." for the prefix to get a result of "Item 1.1" - "Item 1.2" and so on. now what would really be sick to see is if we could enter fields into one of the prefix, middle or suffix... Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.