Topic: ATTEDIT my way?

[CAB]

I was looking for a routine that uses a dialog box to edit the attributes of a block
just like ATTEDIT does. The reason I was looking was that I wanted to control which
attributes were displayed & edited.   

i know you could temporarily set the value of the attribute to 'Constant' and send the
block to Command 'ATTEDIT' but if you are going to do that why not just use your own
dialog box?

Anyone have a routine like that or have another idea to limit user access to a given
attribute while using the ATTEDIT dialog box?

[MP]

<RambleOn>

What I've done in the past for some custom blocks I defined (via code) is to define the geometry only in the block definition. All attributes are created on the fly. Since AutoCAD (attedit) looks to the block definition when populating the attedit dialog it comes up empty, which is exactly what I want: I want the attributes to display on the drawing but want them to be read-only, but not constant per se, as they need to have different values per block instance. Side note: if you make attributes on the fly you can make them constant, yet the values can differ instance to instance. Anyway, I've not created a dialog for this, as the data I push to the attributes comes from a database, but it's a good idea Alan. You could track changes (without need for a reactor), pushing historical data (call 'em attribute revisions if you will) to a LIFO dictionary etc.

</RambleOn>

[Keith™]

I am not sure what you are looking for exactly .. maybe I am just not understanding your needs ... anyway check out this program it is an attribute editor that allows you to change the flags of the attributes along with a whole lot of other things.

[CAB]

Very interesting, as always...

I now remember you touching on this in previous threads. If I understand you correctly,
The attributes are added via a entmake for the INSERT and the locks out the casual user.
If they INSERT a new copy of that block it is without attributes.
The inserts with attributes are only accessible vis lisp.
This is very interesting stuff.. Thanks

Michael,
My original thought (original to me ) was to have a subroutine that you could send a list
of tag names along with the block ename and the routine would display a dialog box much
like the ATTEDIT dialog box. This would limit the access to attributes that you don't want
have the user change or attributes you are changing via your calling lisp routine.

This would be a universal routine & would work with your stealth attributes. On second thought
your stealth attributes would have no "Prompt" because it is stored in the block definition.
I think the "default Value" may be stored there as well.

Thanks Keith, I'll take a look....
I did not have an immediate need but was thinking about a universal subroutine.
Like i have nothing better to do!

[MP]

If I understand you correctly, the attributes are added via a entmake for the INSERT and the locks out the casual user. If they INSERT a new copy of that block it is without attributes. The inserts with attributes are only accessible vis lisp (mp: or vb, arx ...).

You got it right.

My original thought (original to me ) was to have a subroutine that you could send a list of tag names along with the block ename and the routine would display a dialog box much like the ATTEDIT dialog box. This would limit the access to attributes that you don't want have the user change or attributes you are changing via your calling lisp routine.

Sounds useful. The only thing is if user x calls attedit your security, if we want to call it that, is bypassed. Still, if you had a block with umpteen attributes, yet only 3 were applicable for a particlular use your CABATTEDIT would be perfect.

This would be a universal routine & would work with your stealth attributes. On second thought your stealth attributes would have no "Prompt" because it is stored in the block definition. I think the "default Value" may be stored there as well.

All you'd have to do is walk the attributes following the insert and then construct a dcl on the fly to reflect the attributes you wanted to expose. Very do-able.

[CAB]

The only thing is if user x calls attedit your security, if we want to call it that, is bypassed. Still, if you had a block with umpteen attributes, yet only 3 were applicable for a particlular use your CABATTEDIT would be perfect

Well my reasons were not for security but convenience & to avoid having a clumsy user
from entering data that should not be changed.
Using the title block as an example, the 'Drawing Title'  'Author' & 'Subject' should be
changed in Drawing Properties & updated via the lisp. These would not be offered in the
CABATTEDIT dialog box but would exist in the block as attributes. Just an example.

[MP]

'Kay, ya got me curious Alan, I agree on the convenience issue (I acknowledged that in my last post) but how does "security" differ from "avoid having a user modify data that should not be changed"?

[CAB]

security
 noun
 1  security, security_measures
 
   measures taken as a precaution against theft or espionage or sabotage etc.;
    "military security has been stepped up since the recent uprising" 

I suppose it's the same thing. In my case it's security against accidental alteration
of an attribute. BUT, I had no intentions of preventing the user from using the ATTEDIT
command and changing the value. I was a case of the value does not need to be changed
in the situation, so don't give the user the opportunity to screw up.

Back to the Open.

[MP]

I was thinking more like "secure data from unauthorized viewing, modification or deletion; combinations thereof", like drawing title, author, revision number etc.

6 of one, half a dozen of the other.

[CAB]

Yes, my use of 'secure' was too narrow.
The edit routine would deal with secure & unsecure INSERTs & the security
would be up to the block creators. In the secure Insert scenario the calling
routine would have to supply the Prompts as there would be none to retrieve.

[MP]

Uncle.

[CAB]

Sorry Michael, was not my intent..

[MP]

There's no need to apologize Alan.

[CAB]

After some homework here is version 1.00

It does not support the stealth attributes yet.

It does support paging & selective attribute editing.
;;;  Note, that the Tag Names must be in Upper case & no spaces allowed.
;;;  If you pass nil then all non-constant tag will be edited
;;;  Flag if true, only tags in the list will be edited
;;;  Flag if nil,  Tags in the list will be excluded

No error checking for incorrect tag names.

;;; ARGUMENTS
;;; ename   entity name of the block to edit
;;; taglst  list of tag names to edit, nil = edit all
;;; editflg T edit names in list, nil = exclude names in list

 [    OK    ] Update the block
 [  Cancel  ] Quit without changes
 [   Next   ] Display the next page
 [   Prev   ] Display the previous page
 [   Help   ] Display help
While in a field the ENTER key will send you
to the next field.

[MP]

Lookin' good Mr. Butler, as usual.

Suggestion: Add a state field to indicate whether a particular attribute value has been modified from the original, for example, a red asterisk: