FPM error message- Not able to highlight field

[Former Member]

Hi Experts,

I have got a strange problem in my OIF application. I am raising errors by writing code inside my feeder class for form GUIBB.

I am doing it the 'usual' way which is by modifying the changing parameter et_masseges.

The error is coming all right but the respective field is not getting highlighted. The below code I have used..

CLEAR lwa_message..

lwa_message-msgid = c_msgid1.     "Invalid entry'.

lwa_message-msgno = c_msgno10.                    "010..

lwa_message-severity = c_error. "'E'..

lwa_message-ref_name = 'DESCSHRT'..

APPEND lwa_message TO et_messages..

I have used the parameter ref_name where  'DESCSHRT' is the field name but still the field is not getting highlighted.

Is there anything I am missing..?

Many thanks in advance.

Saikat

[former_member208288]

Hi Saikat,

1. Is it a LIST UIBB? if yes, you need to ti define "line_index"

lwa_message-line_index = 1 "(e.g. the first line has error)

2. If its not a List, then try to change the field to input field temporary, as for my experience only the field input will be highlighted (@experts: please suggest a better idea )

Steve

[Former Member]

HI Steve,

Thanks for your response.

I have List as well as Form GUIBBs but whatever that you are saying, I have done. In case of List I have assigned the index field and all my fields in the form are input fields only- thus the dilemma.

Any more ideas guys..?

Thanks,

Saikat

[jens_boeckenhauer]

Hi Saikat,

in the FPM_LIST_UIBB the field references get lost if the messages are issued in PROCESS_EVENT and new data are set in GET_DATA (as EV_DATA_CHANGED = ABAP_TRUE). If you do not indicate data change (typically not necessary in case of errors), the reference should not get lost. This - somewhat uncomfortable - limitation is fixed with the new FPM_LIST_UIBB_ATS. Maybe the old from UIBB has the same limitation. Please check whether it is necessary to set EV_DATA_CHANGED = ABAP_TRUE or try to issue the messages in GET_DATA in any case.

Regards

Jens

[Former Member]

Hi Jens,

Again, very helpful answer.

But, I am not quite able to implement it.

When I don't set ev_data_changed to true then also the ref fields are getting lost. So, I tried to put all validation in get_data.

Your idea was right- when I give the error in GET_DATA then the fields get highlighted correctly. But there is a problem - this is an old application and we have around 6 UIBBs and all of them are using the same feeder. So, when we are appending  lines in ET_MESSAGE  that code runs 6 times and same message gets added 6 times.

Now, one way to handle this is if we can know what is the current UIBB for which get_data is getting triggered. Then we can write condition and add fields to be validated for specific UIBBs.

Is there any other way this can be handled.

Again, many thanks for your help this far.

Regards,

Saikat

[former_member208288]

I can think the possibility to use the abap command "delete adjacent duplicates" to eliminate the duplicate error messages. If all the messages are the equal. you might need to sort the error messages first (the command work only if the data adjacent)

[Former Member]

Hi Steve,

Thank you for your response.

In this case, the delete adjacent wont work. I checked this and found out that inside your feeder class methods when the control comes the et_message parameter is always blank. So when you are adding some messages you don't get to see messages which are already there(added in the previous call).

So, will be have to think of something else. Any more ideas?

Thanks,
Saikat

[jens_boeckenhauer]

Hi Saikat,

if there are six UIBBs with the same feeder - do they all issue the error for the same field (REF_NAME)? This sounds a little strange, but maybe I miss something. If they all refer to the same backend field only one of them should be editable for UX reasons e.g. configured as an input field - and this information comes with IT_SELECTED_FIELDS in method GET_DATA.

Anyway, if you have the same instance of the feeder class (in case there is no wiring and no or identical feeder parameters in all six configurations) you can simply introduce a flag (instance attribute) MV_MESSAGE_SENT: Set it to X when sending the message in GET_DATA and don't send if the flag is set already. Clear the flag in PROCESS_EVENT. This way the message is sent only once.

If you have separate instances it is easy to distinguish them anyway e.g. by storing the config key given in method INITIALIZE.

Best regards

Jens