Segmented button fails to identify selected button -> crashes

[sap]

Segmented button fails to identify selected button -> crashes

[wombling]

amusingly enough (and as a temp work-around the following works:

               <html:div id="grid-header-container">
                <html:div id="grid-layout-option-container">
                    <SegmentedButton id="grid-layout-option-container-seg-button"
                        selectedButton="list">
                        <Button id="grid-header-container--list" text="List View" />
                        <Button id="btn-layout-option-network" text="Network View" />
                    </SegmentedButton>
                    <html:div class="clr"></html:div>
                </html:div>
             </html:div>

[Michadelic]

Hi Wombling,

i tried to reproduce your issue, but it worked fine for me. The id of the button was "list" with the code you specified above.

Could you please copy your code into a working JSBin example so that we can have a closer look?
There is an "OpenUI5" entry in the "add library" list on the top left or you can use this example with an XML view as a base:
http://jsbin.com/yuferedi/1/edit

It might have to do something with the internal behaviour of this control. It accepts "sap.m.Button" as an interface but internally renders

tags for the buttons for technical reasons. Both should have the same id however.

Kind Regards,
Michael

[wombling]

Hi Michadelic (Michael)

I will try to create a JSBin - perhaps if I include the rest of my page and split app it will cause the issue.

if not, I can provide to a limited group access to the application that is causing the issue. Let me get back to you.

Cheers,

Chris

[blaesius]

Hi,
please reopen the ticket if the issue still exists.
Kind regards,
Janina

[wombling]

Hi Janina.

please see http://jsbin.com/yuferedi/2/ which replicates this issue.

lots of JS errors occuring when buttons pressed.

[wombling]

Sorry but I can't reopen my own issue @Michadelic @blaesius could you please now that I have (finally) provided an example of the problem?

Thanks,

Chris

[blaesius]

Hi Chris,
I just had a look into your example and found the reason.
The property selectedButton is set before the buttons are set. This leads to your problem.
But you are right, this is a bug. The order should not influence the result.
I will talk to the control owner and we will provide a fix for this.
To avoid you problem you can change the order, first set the buttons and then the selectedButton. Or just leave the seletecedButton empty, by default the first button is selected.
The internal ticket number is: 0120061532 0001429454 2014

Thanks for reporting this. We will inform you when this issue is fixed.

Kind regards,
Janina

[blaesius]

Hi Chris,
the issue is even more complicated then we thought. But we are working on it.
There seems to be something mixed up with the ids internally.
Kind regards,
Janina

[Michadelic]

Hi Chris,

fixed! Thanks for reporting this issue and sending us the JSBin example, great!
With the example it could be debugged and there were actually two problems:

1. The "selectedButton" state was not handled properly in all cases. The
   renderer changed the property directly, i fixed this to happen in
   "onBeforeRendering" instead and the handling of invalid ids was also
   fixed.

2. And this is the root cause for the issue: When mixing HTML-Tags with
   Control tags in XMLViews, technically a new view is created in the
   background for each HTML Tag. The Ids were composed differently for
   controls (inner id) and associations (outer id). That is why the
   selected button was never found.

Both issues were fixed internally and will get into the next patch set
of OpenUI5 which is 1.22.7 and will most likely be built in the next
week.

Michael Graf
OpenUI5 Developer

[se38]

Where's the "like" button if you need one ;)

[akudev]

next patch set of OpenUI5 which is 1.22.7 and will most likely be built in the next week

In case someone is confused because the current one is 1.22.5: patch 1.22.6 of OpenUI5 is not released, it is an SAPUI5-only interim patch required for an urgent issue in a control in the sap.me library, which is not contained in OpenUI5.

[wombling]

😄 Thanks guys, and sorry it took me so long to provide a working example 😊

[Michadelic]

No Worries, i'm closing the issue now!

[wombling]

@Michadelic I'm sure that this is your usual practice to close issue once code has been fixed, but given that code has yet to be released to community - I'd suggest it perhaps shouldn't be closed, perhaps given flag "pending release" and then closed when solution available for general use?

[blaesius]

You are right.
On GitHub we normally leave the issue open until the fix is relased.

[akudev]

Currently it is practice to close the issue when all work from our side is done, so it is gone from our radar. Sure, this causes a mismatch between bugs fixed in the tracker and bugs fixed in the code, but soon there should be code available here which corresponds to our nightlies or so, so this mismatch will be solved.
We also write explicitly which version will contain the fix when closing an issue. This should make it easy enough to understand which version is fixed and which one is not.
That's at least current practice, in order to avoid additional process steps going back to issue tickets later again. I guess this practice can be adjusted, but then it should be agreed and done by all.

Andreas