Choosing between multiple MessageArea-items

[Former Member]

Hi,

I want to use several MessageArea-items for multiple tabs but when more than 1 MessageArea exists the first is choosen for message output.

Is there any possibility to choose which area is used for message output?

I'd be very thankful for help!

Greets,

Robert Schulz

[Former Member · Accepted solution]

Hi,

I don't think we can choose the message area as we don't give ny refernce to the message area.

I feel it would be a better idea to create the message area dynamically.

Regards

Noufal

[Former Member · Accepted solution]

Hi,

but that would be just a work around and no real solution...

After dynamicaly creating a message area I would have to "destroy" it afterwards, wouldn't I!?

Greets,

Robert

[Former Member · Accepted solution]

Yes that is true.

Check if the enabled property would be of any help.

[Former Member]

Hi Robert Schulz

I am also facing the same problem. I am not able to remove the message area in tab1 and add it to tab2 in wddomodify. I did not generate dynamically the message area, i inserted it. Also i wanted to place it to the appropriate position. Can u send the code used to remove and add. I am able to get the selected tab but add and remove is the only problem.

Thanks in advance.

[Former Member]

Do I understand you correctly, that you want a separate message area for each tab of a tabstrip?

You might try the following:

1. Bind the TabStrip.selectedTab-property to a context attribute of type "string". This ensures that this attribute will always contain the ID of the currently selected tab.

2. Foreach tab: create value node "<tabID>State" (cardinality 1:1, selection 1:1) with a calculated attribute "MessageEnabled" of type "boolean". The get-method of the attribute should return true iff the corresponding tab is the currently selected tab.

3. For each message area, bind the MessageArea.enabled-property to the "MessageEnabled"-attribute of the corresponding node.

I did not try this myself.

Armin

[Former Member]

You've understood it perfectly!

I've tried the solution you described in almost every way but for some reason it does not work!

I tried to bind only one MessageArea via enabled-property to the context and enable it by setting the value to TRUE within the "wdDoModifyView" or the "wdDoInit" but it didn't work.

I will try another (unpretty) work-around: one MessageArea below the TabStrips! That's not a bit of what I wanted but I'm kind of frustrated by now!

...I just hope they will add a functionality to do things like this in one of the next releases!

Greets,

Robert

PS: If anybody knows a solution that works for sure, I'd be grateful for the information although!

[Former Member]

Don't give up.

Bind all message areas as described. If binding the "enabled" property does not work, try also binding the "visible" property such that exactly the message area corresponding to the selected tab has visibility "VISIBLE" and all others "NONE".

To check if the data binding is correct, simply place a TextView on each tab that displays the values of the "enabled" and "visible" properties for the message area in this tab.

And if all this does not help, you still have the option to dynamically destroy/create the message areas (in wdDoModifyView) when the tab selection changes.

Armin

Message was edited by: Armin Reichert

[Former Member]

The binding of the visible-property as well as the enabled-property didn't change the situation --> none of the two MessageAreas (in two different tabs) I tried to activate this way in the wdDoModify-method were accepted/displayed the messages.

I tried to dynamically generate the two areas and it worked...at least partially. Means that it worked in one way (=first tab --> second tab) but when I tried to return(= [first tab -->] second tab --> first tab) it crashed!

Reason: "com.sap.tc.webdynpro.services.exceptions.WDCreationFailedException: Cannot create view element implementation com.sap.tc.webdynpro.clientserver.uielib.pattern.impl.MessageArea"

In the debugging mode it seemed as if the MessageArea-object I created still existed after removing it from the element it was added to first. But I do not have any idea of how I could "destroy" the MessageArea-element within the view.

[Former Member]

Concerning the "Cannot create view element implementation":

This means the component that tries to create a view element (like MessageArea) has not declared the library of this view element ("Pattern" in this case).

A component by default has access to the libraries "Core", "Standard" and "BusinessGraphics". Unfortunately, the MessageArea belongs to "Pattern" so you have to declare this explicitely:

In NWDS right-click on the component name, choose "Edit UI element library reference" and select the libraries you need. This should solve the exception problem.

Another remark: If you want to destroy and recreate UI elements, use the destroy() and not the remove() method. Removing leaves the UI element in the view and its ID remains so you cannot create another element with this ID:

Last remark: if you don't care about the ID, simply pass NULL in createElement().

Armin

[Former Member]

Concerning the "Cannot create view element implementation":

The "Pattern"-library had been included.

Thank you for the information on how to destroy ui-elements "for sure"!

I finally managed to recieve my goal!!!

It worked this way:

I created a MessageArea item in the layout-editor within NWDS (it could also have been created dynamically). In the wdDoModify-method I

(1) remove the area from its current container (to know the right container I used the getContainer-method) and

(2) add the area to the right tab using the selectedTab-method of the TabStrip-element

It's like pushing one MessageArea from one place to where you need it.

That you very much for the advice and ideas!!!

PS: For everybody who would have done it that way from the start: Sorry for troubling you!

Greets,

Robert

[thomas_chadzelek]

Hello,

may I kindly point you to the Javadoc of IWDMessageArea? It tries to tell us that context binding of enabled and visible property will only work if the context attribute is made read-only! If it is not, then the message area is useless.

Best regards,

Thomas