WD and FPM local edit mode - help needed

[matteo_montalto]

Hello gurus,

not sure this is the proper section to start the following thread, anyway in case I kindly ask moderators to move the discussion into the FPM section, thanks.

I'm dealing with a specific requirement in SRM that sounds as follows:

on a document (e.g, a Bid), we need that some (custom) fields can be modified.

Such modifications should NOT trigger any update on the document by means of PROCDOC_UPDATE because we would like that such changed values are stored directly @ DB without changing document's status or creating a newer version.

(we could think at a "raw" function which commits eventual changes on the current document version).

Looking for the "cleaner", most effective and functional way to achieve such a behaviour.

The idea we has was as follows:

- create, in the WD view which contains the fields we'd like to change, a custom button, say "Local Edit", which opens the desired fields for modification without changing the access mode (Display/Edit) of the main component ;

- once the button is pressed, then all the identified fields will become enabled for modification;

- another button , say "Commit", should retrieve all fields values and update the DB.

Sounds quite tricky, and the main problem is how to overcome standard management of display/edit mode which is proper of the standard OIF FPM component.
Did a bit a trials without success; even if I dinamically set a field as ENABLED, if we're in FPM display mode, then the standard's behaviour wins and the field is set as read-only.

Maybe I'm exploring a wrong path, but... I've seen there's an FPM event, which is called FPM_LOCAL_EDIT, which should override the standard behaviour of FPM_EDIT/FPM_DISPLAY mode on the local UIBB.

This could be helpful, in our scenario, for opening a section for modification without switching the document itself to EDIT mode.

However, I tried it without success, as even though FPM_LOCAL_EDIT event is triggered, once in DISPLAY mode no fields became modifiable.

Any suggestion on the task will be highly appreciated

[matteo_montalto]

Does anyone has any clue/hint on the issue?

What I forgot to mention is that each custom field is added in the view dynamically (dynamic programming), so there's no "explicit" way to use the BINDING property of each UIElement... I have to make everything via coding.

I tried to:

-1- set the ENABLED property for the specific UIElement ( or, by casting, each UIElement subtype).

Specifically;

DATA: lo_wd_input_field TYPE REF TO CL_WD_INPUT_FIELD,

            lo_ui_element_attr TYPE REF TO cl_wd_uielement,

....

*assuming lo_ui_element_attr contains the specifc input field.

lo_wd_input_field   ?=  lo_ui_element_attr.

CALL METHOD LO_WD_INPUT_FIELD->SET_ENABLED

   EXPORTING

     VALUE  = 'X' .

but without success; when in DISPLAY mode, it seems this call doesn't make the field editable.

-2- create a binding with a context attribute, say FIELD_EDITABLE:

CALL METHOD LO_WD_INPUT_FIELD->BIND_ENABLED

   EXPORTING

     PATH   = 'FIELD_EDITABLE'.

which is set to "X" by a button press ("Enable editing"), and then calls an FPM_REFRESH in order to process WDDOMODIFYVIEW again.

This also doesn't work . And I'm trying to understand if I'm doing it wrong or if the cause is that the DISPLAY mode overrides any change I make,

Could anyone provide me an hint or suggestions, maybe examples of code, to manage the task?

Thanks in advance.