Auto number attribute lisp fix

[irneb]

that's why i stopped using entmod on text and attributes. vla won't do that.

I finally got round to modifying the lisp to work with annotative scaled text / blocks as well. The trick is either to use VLA or if you use the entmod to only send it the values which should change - see the 175th line. It's still caling entmod, but only with the ename & text value.

The problem is if you get the DXF data list of the anno text, you get the currently displayed text height. When you send this to the entity using entmod it gets interpreted as the Paper Space Height. And if you thus do this the usual way (i.e. entget to get the list, subst to change the list & entmod to modify the entity) it also then changes the text height to the larger size (i.e. scale X already scaled height). Even though you haven't subst the DXF code 40 for the height. So in the lisp (seeing as I'm not modifying the height) it doesn't form part of the list sent to entmod.

It gets hairy when you want to modify the height! You basically have to find out by how much the value is scaled and then convert so your new height is what's meant for the Paper Height. Fortunately you can use the vla/vlax methods through the entity's ActiveX object reference and change it's height property, but you need to be wary of this problem! So if you know the needed Paper Space height of the text (irrespective of what scales are attached to it) use entmod, if you know the needed Model Space height at the currently displayed scale (not necessarily CANNOSCALEVALUE) then use the vla-put-Height method.

[samtom123]

I finally got round to modifying the lisp to work with annotative scaled text / blocks as well. The trick is either to use VLA or if you use the entmod to only send it the values which should change - see the 175th line. It's still caling entmod, but only with the ename & text value.

The problem is if you get the DXF data list of the anno text, you get the currently displayed text height. When you send this to the entity using entmod it gets interpreted as the Paper Space Height. And if you thus do this the usual way (i.e. entget to get the list, subst to change the list & entmod to modify the entity) it also then changes the text height to the larger size (i.e. scale X already scaled height). Even though you haven't subst the DXF code 40 for the height. So in the lisp (seeing as I'm not modifying the height) it doesn't form part of the list sent to entmod.

It gets hairy when you want to modify the height! You basically have to find out by how much the value is scaled and then convert so your new height is what's meant for the Paper Height. Fortunately you can use the vla/vlax methods through the entity's ActiveX object reference and change it's height property, but you need to be wary of this problem! So if you know the needed Paper Space height of the text (irrespective of what scales are attached to it) use entmod, if you know the needed Model Space height at the currently displayed scale (not necessarily CANNOSCALEVALUE) then use the vla-put-Height method.

dear sir,
missing (i & o ) alphabet in increment

[irneb]

dear sir,
missing (i & o ) alphabet in increment

That's purposefully done, we usually omit these so it doesn't conflict with 1 and 0. If you need to add these, modify the lisp, change the following:

(setq    INCRset     '(1 "" "" 1 1 t)
            alphalst
                             '("A" "B" "C" "D" "E" "F" "G" "H" "J" "K" "L" "M" "N" "P" "Q" "R" "S" "T" "U" "V" "W" "X" "Y" "Z"
                                )
) ;_ end of setq

to include the I and O:

(setq    INCRset     '(1 "" "" 1 1 t)
            alphalst
                             '("A" "B" "C" "D" "E" "F" "G" "H" "I" "J" "K" "L" "M" "N" "O" "P" "Q" "R" "S" "T" "U" "V" "W" "X" "Y" "Z"
                                )
) ;_ end of setq

[manuel-lemos]

I just had to throw in my 2 cents here, this is exactly what I have been after! When dealing with numbering an entire building, editing my custom room number blocks took forever. This is going to save so much time. Many thanks!

[irneb]

I've had yet some more problems with annotative text. Not sure why this happens. Anyway I took alanjt's advise and now use the ActiveX object to change the text string instead of the older entmod method.

Another thing was to incorporate the dialog DCL file into the LSP. So now you only need the one LSP file. No need to keep the DCL in a support path.

[niharhm]

My problem is a bit different.... I have dynamic blocks inserted with attributes that display Cable Nos. i.e. for color 30 the cable no. is 1-2 (2nos. if it is to start with 1) and similarly for other colors of cables which can go upto max 5 i.e. sometimes one encounters cable no 133-137+138-139 (For Extra Cables).. hence numbering sequence is maintained its' just that attributes text is variable depending on the colors of cables.... attached files shall clarify the same.... I need help in compiling a LISP Routine which helps editing the attributes numbering within the blocks that is if increment is 2 and the cables no block selected for editing is 1-2 it should automatically become 3-4 and simultaneously all the numbering should be updated automatically with final count ending as 135-139 +140-141...
I am not much comfortable using DCL but can at least understand some basic LISP coding... ANY HELP shall be greatly appreciated....

THANX in ADVANCE

[irneb]

I'm having difficulty figuring out how those could get implemented. Mainly I'm not sure how 1 increments to 2, 3, 4 ... Should it maybe be a list, e.g. 1=1-2, 2=3-4, etc.? If so it might be doable using an association list. But I think you're not actually after an incrementing routine at all .

One problem I see with your block is its visibility states, which turn off 3 of 4 attributes. This could get a bit hectic, since those turned off attributes actually disappear from the drawing if the state changes. It would be a pain to have this be updated automatically. I'd suggest reworking the DB and using a Lookup Table instead of the VStates. That way you could try to move one attrib instead of turning on / off. BTW, there's also an error: If the VS is set to right and you've moved the box containing the attib, the box gets skewed if you stretch it larger. It seems you have to first stretch the box to the desired size and only then move it into position. Another possibility would be to have a hidden attribute, each of the displayed attribs would simply link to that using fields. Then no matter which is shown, it'll always show the same value. However, there's a new problem with this: the user could edit the displayed attribute and thus break the link (since a field is only a one-way link).

Anyhow the automatic incrementation idea is something I've been working on for a while now. Finally got that to an acceptable state. This also made me think it's a good idea to collect my routines for public sharing. And this seemed a good starting point. So I created an open source project at sourceforge called Caddons. I'm not sure if it's allowable to link to it here, but seeing as it's open source (LGPL) and I'm not asking anything for it I can't see why not. If it's deemed unacceptable, I apologize and ask that a moderator remove these links.

Anyhow, the description of the new Auto Increment routine can be found here: https://sourceforge.net/apps/mediawi...Auto_Increment

It remembers which text / attribs you've selected persistently between sessions, in which order, and what your settings were. You can add / remove text from this at any position and have them all renumbered in one go, as well as changing the settings. All the incrementing text are also highlighted while you're editing the series. And as an added I've included extra numbering systems: the usual integer & alphabetic (upper & lower case), floating point decimal, as well as roman numerals (upper & lower) and Binary, Octal & Hexadecimal (for those who "really" want that ).

If you want to download the file, see the project's files page. I'd appreciate testing and comments on the Bug Report forum. Or if you've got an idea you'd like added, post on the Feature Request forum, I've made a few I could think of already.

[niharhm]

Thanx... I shall give it a try and report within due course of time... But Thanks so much for your concern and efforts

[xiaxiang_2004]

Anyhow, the description of the new Auto Increment routine can be found here: https://sourceforge.net/apps/mediawi...Auto_Increment

YES,VERY NICE!
I like this routine
Thanks,irneb!
But in the "Octal numbering" mode
"I0.0"Appears twice,
"I0.4"Appears twice,
"I0.7"Appears twice,
Why?
I hope you can solve this problem

[irneb]

Thanks for the complement. For those finding similar problems, see my answer on the Caddons forum:
http://sourceforge.net/tracker/?func...7&atid=1400471

A fix is in the pipeline, but may take some time.