Strange Button Behavior
#1
Lightbulb 
I'm finding when working with button controls that the onclick event is being triggered even if the button isn't actually 'clicked'.

Example Code:
Code:
            <!-- Option Labels -->
            <control type="list" id="9000">
                <onup>9000</onup>
                <ondown>9000</ondown>
                <orientation>vertical</orientation>
                <itemlayout height="38" width="380">
                    <control type="label">
                        <label>$INFO[ListItem.Label]</label>
                    </control>
                </itemlayout>
                <focusedlayout height="38" width="380">
                    <control type="label">
                        <label>$INFO[ListItem.Label]</label>
                    </control>
                </focusedlayout>
                <content>
                    <item id="1">
                        <description>Home</description>
                        <label>$LOCALIZE[10000]</label>
                        <onclick>SetFocus(9001)</onclick>
                    </item>
                    <item id="2">
                        <description>Views</description>
                        <label>$LOCALIZE[40001]</label>
                        <onclick>SetFocus(9002)</onclick>
                    </item>
                </content>
            </control>

This renders a list of items/buttons that you can scroll through, however while scrolling the onclick event is being triggered. It almost seems as if 'onclick' is being handled as 'onfocus'.

NOTE: I just realized the items were being rendered as 'label'. I realize this is probably why, not my code, and now that I notice that I will fix it and check if the behavior is the same. Is the whole 'onclick' vs 'onfocus' point not still valid though?

Here's a a bit a code from a different portion, yet still using 'label' controls where 'onclick' functions as desired.
Code:
        <control type="fixedlist" id="9000">
            <onup>9000</onup>
            <ondown>9000</ondown>
            <viewtype>list</viewtype>
            <orientation>vertical</orientation>            
        <itemlayout width="700" height="86">
            <control type="label">
                <label>$INFO[ListItem.label]</label>
            </control>            
        </itemlayout>
        <focusedlayout width="700" height="104">
            <control type="label">
                <label>$INFO[ListItem.label]</label>
            </control>
        </focusedlayout>
            <content>
                <item id="1">
                    <description>Videos</description>
                    <label>$LOCALIZE[3]</label>
                    <onclick>ActivateWindow(videofiles)</onclick>
                </item>
                <item id="2">
                    <description>Movies</description>
                    <label>$LOCALIZE[342]</label>
                    <onclick>ActivateWindow(videolibrary,movietitles,return)</onclick>
                </item>
            </content>
        </control>

The only difference I can see is that one is a 'fixedlist' and one is a 'list', but why would this change the way the 'label' functions? Am I missing something obvious or is there a bug in the function of a 'label' where it's properties are altered based on it's parent type?

Here is a ZIP archive with three files demonstrating the functionality mentioned above.
CustomSettings.xml exhibits what I consider improper behavior.
Includes_HomeVertical.xml exhibits proper behavior.
Includes.xml has a few chunks of code required the complete the two files above.

I'm noticing this with XBMC for Windows DX (r30515).
Reply
#2
The <onclick> event should certainly not be triggered while you scroll in the list, only if you actually click it. Change the <onclick> to something more obvious perhaps (eg ActivateWindow) to ensure that this is true - the change of focus you're seeing may be due to something else.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#3
You're right. Looking through the rest of the code, I noticed the menu's that were meant to be activated by the <onclick> event are also visible based on the selection of the list. The redundancy was confusing in this case and will be dealt with.

While investigating this issue, I also came across another peculiarity with lists.
These controls are part of a 'grouplist'
Code:
                    <control type="radiobutton" id="102">
                        <include>SettingsLabel</include>
                        <label>$LOCALIZE[40033]</label>
                        <onclick>Skin.ToggleSetting(HideHomeFanart)</onclick>
                        <selected>Skin.HasSetting(HideHomeFanart)</selected>
                    </control>
                    <control type="image" id="111">
                        <height>2</height>
                        <width>840</width>
                        <texture>special://skin/media/common/divider.png</texture>
                    </control>
                    <control type="radiobutton" id="103">
                        <include>SettingsLabel</include>
                        <label>$LOCALIZE[40014]</label>
                        <onclick>Skin.ToggleSetting(HideVideos)</onclick>
                        <selected>Skin.HasSetting(HideVideos)</selected>
                    </control>

When the image control in between the two radiobuttons has an 'id' value it scrolls as expected, however if you remove the 'id' value (Which seems un-necessary in the first place) then the list won't scroll past the image control. However you can go up and wrap around to the bottom to get to the bottom radiobutton.

So why do grouplists require each control in them to have an 'id'? It's not so much a problem, but I have issue as a programmer giving objects an 'id' if I don't plan of referencing them elsewhere. I would really like to do away with giving all these buttons 'id's for no reason.
Reply
#4
I think you'd have to add <ondown>103</ondown> to radiobutton 102 to get it to scroll down past the image.
Reply
#5
Hitcher Wrote:I think you'd have to add <ondown>103</ondown> to radiobutton 102 to get it to scroll down past the image.

Oddly that doesn't work, which I'm somewhat surprised by. You would think explicitly telling it where to scroll would work fine, but the fact that it doesn't suggests something else is going on here.

I went through the wiki hoping for some hint as to what is happening, but didn't find much information.

NOTE: I also tried playing with the <enable> tag with no luck in fixing the behavior.
Reply
#6
The reason is that the grouplist takes care of navigation for you, which implies that everything should be navigable, and thus they MUST have id's (everything that is navigable must have an ID.

Now, this is a peculiar situation in that image controls are never focusable, thus you can't actually navigate to them. Will contemplate whether or not we should take care of this case in the code (there's 2 ways to handle it - add an ID or logic so that it's not required).

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#7
Ok, makes sense. For the time being I will roll over and add ids in these situations, though handling this in the code seems like a good long-term solution.

Shall I open a trac ticket for this?
Reply
#8
Sure, feel free to open a ticket and cc me - at least we won't lose trac(k) of it then Smile

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply

Logout Mark Read Team Forum Stats Members Help
Strange Button Behavior0