Use attributes window to edit standalone table

[AlexanderGray]

I have a standalone table that is version with read-write permission.  It is loaded in ArcMap 10.0.  I have a featureclass that is non-version and read-only permission.  I have a 1-1 join between the featureclass and the table. 

I want to users to only have edit capability on the attributes in the table.  I also want to be able to use the attributes window to set some values.  I want to batch set a value on a field for all the user.  The users do not want to use the field calculator (too complicated) and do not want to use the table view. 

Can I use the attributes window to edit one or many rows selected either in the join layer or directly from the table (I can have the select done in code.)

Thanks

[RichardFairhurst]

Can I use the attributes window to edit one or many rows selected either in the join layer or directly from the table

The answer to both questions is no.  The joined table cannot ever be edited and the StandAlone Table cannot be seen in the Attribute window as long as it is a StandAlone table.  However, there is a trick that will make the StandAlone Table itself into an in memory feature class and visible in the Attribute window.  Use the Make XY Event table on the StandAlone Table to make it into an in memory point layer.  The XY values can be from any numeric field and can be 0 or random (if you make their symbol invisible), or the XY of the related feature class's centriod (if you want them visible in a position related to the actual features), as long as they come from a numeric field in your StandAlone table.  As long as you select the records in the XY event layer, they will appear in the Attributed window.

The edits in the XY Event layer are actually edits to the StandAlone table itself, so there is no need to code any data transfers.  Joins can be to the original StandAlone table and you can use a relate from the selections in the XY Event table to transfer selections to the joined features.  Edits appear in the joined features as soon as you leave the field you are editing in the XY Event Table's Attribute window.

[AlexanderGray]

Hmm, If I am going do that, I might as well write my own editor, this is getting very complicated for a simple problem. 

The problem is I have a featureclass that I want to only allow edit to two or three fields, all attribute fields.  Users need to see the shape but I don't want them messing with them.  The feature class also contains lat/lon of the shape centroid but that is read only.  The name of the shape is read-only too.  Only one value is read-write and another which flags a change has a occured, then maybe the date the change occured and the user.  Archive featureclass are actually a good candidate for this but I need to restrict the user's edits.  I can write a featureclass extension to abort any edit on the other fields but that is not really what I want to do, I want to prevent them from making the change before they even try to do it.  What I really want to do is grant permissions per field.  The join to standalone was a work-around.  The creation of the event layer is a work-around to the work-around...  I will try it out though, Maybe if I join the feature class to the table...  Means I will have two layers in an opposite join configuration...

[RichardFairhurst]

Hmm, If I am going do that, I might as well write my own editor, this is getting very complicated for a simple problem. 

The problem is I have a featureclass that I want to only allow edit to two or three fields, all attribute fields.  Users need to see the shape but I don't want them messing with them.  The feature class also contains lat/lon of the shape centroid but that is read only.  The name of the shape is read-only too.  Only one value is read-write and another which flags a change has a occured, then maybe the date the change occured and the user.  Archive featureclass are actually a good candidate for this but I need to restrict the user's edits.  I can write a featureclass extension to abort any edit on the other fields but that is not really what I want to do, I want to prevent them from making the change before they even try to do it.  What I really want to do is grant permissions per field.  The join to standalone was a work-around.  The creation of the event layer is a work-around to the work-around...  I will try it out though, Maybe if I join the feature class to the table...  Means I will have two layers in an opposite join configuration...

Nothing you are saying above could possibly have been known from your original post.  My answer is actually fairly straight forward and answers your original question.  It is no where near as complicated as writing your own editor, but you are welcome to do that if you have requirements that are not going to fit with the normal design of ArcMap.  It sounds like you should design this for a much more restricted environment that the full ArcMap application anyway and uninstall ArcMap from these users, since with the full application you will be spending all of your coding time trying to block things and these people are not actual ArcMap users if they want this much customization.

[AlexanderGray]

There is nothing wrong with your post, it has a lot of valid information, I am just using to forum as a sounding board for things I wouldn't have thought of or things I don't know, like a discussion.  I am more interested in ideas than answers.  Like I hadn't seriously considered using the table as an event layer, it is a good idea, I am currently experimenting with that in my design phase.  I don't have an engine developer license, I only have 20 arcinfos so esri thinks that is not enough to qualify me to develop engine applications so I am developing desktop.