Removing IModifiableSimpleType at runtime...

[tom_cole3]

I have a simple Context node that is defined like this:

CharValues
     |
     -- ClassName
     | 
     -- Charact
     |
     -- Value

All attributes are type string.

This node is bound to a table with the Value cell editor being an input field. The trick is this...as the user selects different rows in the table, we need to value list for that attribute to be different. Some rows will have lists, some will still be freetext.

Creating the value lists (using IModifiableSimpleType) is working fine. Where we have the problem is when the user clicks on a cell and the field should become freetext. We are calling clear() on the modifiable simple type to remove the list, but then the user gets the error "String 'XXX' does not match the enumeration" when they enter any value.

Is there any way to remove the ModifableSimpleType completely from the attribute so it stops trying to validate? Or better yet, is there any way we can write our own class to prevent this validation (i.e. always return true)? We want the user to pick from a list, but we don't care if they enter a value that is not on the list.

Any help would be greatly appreciated. If code would help I'd be glad to post it.

[Former Member · Accepted solution]

Such a functionality (input field with list of proposals) is only available in releases >= 7.11 (or 7.20, I don't remember exactly).

In earlier releases you must use some workaround. You could for example use an extra column with a drop-down list that has the proposals and an additional entry "<other value>". You could then use this drop-down list to either select a proposal and let the input field read-only, or select the "<other value" entry and make the input field editable. Maybe there are also nicer ways to solve your requirement...

Armin

[tom_cole3 · Accepted solution]

Thanks Armin. I had considered such an option (providing two input fields, one with assigned enumeration, one without) and hiding/displaying the appropriate editor based on whether it was freetext or value set.

I was hoping to avoid this, but it may be my only option.

[tom_cole3 · Accepted solution]

>

> Such a functionality (input field with list of proposals) is only available in releases >= 7.11 (or 7.20, I don't remember exactly). 
> 
> In earlier releases you must use some workaround. You could for example use an extra column with a drop-down list that has the proposals and an additional entry "<other value>". You could then use this drop-down list to either select a proposal and let the input field read-only, or select the "<other value" entry and make the input field editable. Maybe there are also nicer ways to solve your requirement...
> 
> Armin

Yes I wish we were on 7.1+, but unfortunately the majority of our client base is not...so 2004s it is

We are going to go with this approach, providing two input fields and hiding/displaying the relevant field based on whether there is input help or not. It's not ideal (as I can't give them an either/or approach) but as this was not part of the original specification, other options seem like more work than is necessary.

[siarhei_pisarenka3]

Hi Tom

Point1: If you use attribute with enumeration in a table the same enumeration will be displayed for all table rows. This means that the same list of help values will be displayed in each table row for Input Fields or Drop-Downs. You cannot have one help value list in one row and another list in another row (within the same cell editor).

Point2: Unfortunately, you cannot disable the validation against the enumeration type. The validation runs by WebDynpro automatically and before any custom logic - the validation runs before any event handler, the validation runs before any custom attribute setter. Read the articles for reference: [Yet Another EVS Valuehelp: Showing Display Texts for Keys|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/391ee590-0201-0010-1c89-f1193a886421?quicklink=index&overridelayout=true] & [Minus EVS, Plus OVS == value help + "smart" input|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3309] [original link is broken] [original link is broken] [original link is broken] [original link is broken];

Point3: The blog shows a solution with disabled validation, but build with OVS: [Minus EVS, Plus OVS == value help + "smart" input|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/3309] [original link is broken] [original link is broken] [original link is broken] [original link is broken];

Point4: If you still want to use EVS, the help value list should be common for all table rows. If you do this all the rows will pass the validation.

BR, Siarhei

[tom_cole3]

Thanks Siarhei,

I will follow your links and see if I can use the OVS option. I was curious where exactly the validation occurred as I was unable to "catch" it beforehand. So it makes sense that it happens before any events, etc. are called.

Typically I do have the same valueset assigned to every row (which would be standard behaviour as the enumeration is actually assigned to the attribute, not the individual instance of the attribute within an element), but this is a unique situation. What we are trying to do for our customer is to basically "flip" a table, making the original columns rows, and vice versa. There is similar functionality in the backend whenever you look at the Property Tree in EH&S.

I will post back in a little bit.