Mutual behavior issue in Buttons group

[Gauleiter]

PRECONDITIONS: we have 2 buttons attached to _root MC.

Both buttons track events: press, release, rollOut, rollOver, - in order to animate properly the proper events, happening with ‘hit area’.“Track” means that in .fla source file action script (enclosed in /* as */ for LWFS) contains proper handlers, e.g.:

/* as
on(press){
    tellTarget("button_mc"){
        gotoAndPlay("click");
    }
}
on(release){
    tellTarget("button_mc"){
        gotoAndStop("norm");
    }
    fscommand("event","<unique_event_name>");
}
on(rollOver){
    tellTarget("button_mc"){
        gotoAndPlay("click");
    }
}
on(rollOut){
    tellTarget("button_mc"){
        gotoAndStop("norm");
    }
}
*/

User touches 1st button and moves finger off from it (keeping it touched)

ISSUE DETAILS:

• 1: If we want to animate button click state when user gets his finger back over touched button, but we don’t want other button to be animated when ‘rollOver’ed (behavior of Apple’s UIKit):
  • User drags his finger over the 2nd button, and it animates as if it was touched (the ‘pressed’ object is still the 1st button) - which is not good. What’s more, if user releases his finger over 2nd button,‘release’ event according to current logic is not issued for neither of buttons and the 2nd one remains in ‘clicked’ UI state :)
• 2: If we don’t want to handle any rollover, i.e. after the very first ‘rollOut’ from pressed button we want to consider it as‘releaseOutside’ed and not to react on any ‘rollOver’:
  • User drags his finger back over the 1st button, and (as we decided before) we don’t highlight button. But if he releases his finger at this moment, ‘release’ event is fired (even though the button was not highlighted) - which is not good;

Pull request solves the problem, making group of buttons interact in mode, described in 1st case (UIKit buttons behavior).

As an alternative, to make buttons behave as it’s described in the 2nd case, instead of pull requested code we can make the code:

if (!found && focus) {
    focus->RollOut();
    focus = 0;
}

(in the same method as pull requested code is) to look like below:

if (!found && focus) {
    focus->RollOut();
    focus = 0;
    pressed = 0;
}

[splhack]

(modified comment for markdown layout)

Thanks. It seems good. I'll check it later.

[splhack]

I'm experimenting to have appropriate behavior about it. But I noticed the behavior of iOS calculator.

• touch button [press,rollOver] -> roll out [rollOut] -> roll over the same button [rollOver] -> release [release]
• touch button [press,rollOver] -> roll out [rollOut] -> roll over the other button [rollOver] -> release [release]

[Gauleiter]

Yep, that is true, that iOS calculator is made to keep this behavior, I was inspecting a lot of sources (iOS out_of_pack programs, OS-X system programs, Android system apps and a lot of 3rd party apps). Though I would admit, that this behavior is not typical for any of operation systems, it was confusing me a lot. This is a customized one, since for calculator it is particularly convenient. To get iOS system examples you can tap on any edit box to open a system keyboard - there iOS won't react on any rollOver over the other button (there are some exceptions as Shift + Key). Also you can open Game Center and see its buttons, Camera would give the same result, and in general almost any iOS app implemented with UIKit. Also you can see the behavior in OS-X. What's interesting, even a calculator in OS-X doesn't support "other button rollOver" release.

But even with that, from the issue description above you can read:
"What’s more, if user releases his finger over 2nd button,‘release’ event according to current logic is not issued for neither of buttons and the 2nd one remains in ‘clicked’ UI state :)"
So even if we wanted the calculator-like behavior, currently it won't work.

[Gauleiter]

Here's an example to test (source .fla plus .lwf created with LWFS). It contains only two buttons.
(sorry for the way I share a file (using github), this is the best approach I could use technically right now)
https://github.com/Gauleiter/lwf/blob/efd38f507cf2d68e1ae342a63f92b66b49520c59/buttons_group.zip?raw=true

P.S. Provided .lwf file is tested on cocos2dx renderer

[stari4ek]

Hi,
Any chances to have resolution here?

[splhack]

@stari4ek This pull request already solved the problem, right? I'll add something to solve it if I came up with a good idea.