Haxeui-flixel doesn't listen to parent state being paused by flxsubstate

[greysondn]

Again this has a readme writeup that's not too terrible that I've included after the break.

In my repo: 03-cantstopwontstop Specific commit: 8a59958 Zipped version attached to this issue: 03-cantstopwontstop.zip

---

Substates pause their parent classes by default. Haxeui doesn't listen to when its parent class is paused due to a substate being opened.

This is built to demonstrate that. You can click add all day, even with the substate open, and the counter will continue to increment.

haxelib versions from git...

flixel, 984124c4
haxeui-core, f601c051
haxeui-flixel, 6cc3b3f4

Tested targets

air      - SDK not installed
android  - SDK not installed
electron - haxelib not installed
flash    - has this bug.
html5    - has this bug.
hashlink - build fails (probably different error)
neko     - has this bug
windows  - MSVC not installed

haxelib list...

dox: [1.1.0]
flixel-addons: 2.7.1 2.7.3 [2.7.5]
flixel-demos: 2.6.1 2.7.0 [2.7.1]
flixel-templates: 2.5.3 2.5.4 2.5.5 [2.6.2]
flixel-tools: 1.4.2 1.4.3 [1.4.4]
flixel-ui: 2.3.1 [2.3.2]
flixel: 4.5.1 4.6.0 [git]
flxscrollablearea: [0.4.0]
formatter: 1.5.1 [1.6.0]
haxeui-core: [git] old
haxeui-flixel: 0.0.0 [git]
haxeui-openfl: [0.0.2]
hscript: [2.3.0]
hxColorToolkit: [1.6.1]
hxcpp-debug-server: [dev:c:\Users\Dorian Greyson\.vscode\extensions\vshaxe.hxcpp-debugger-1.2.4\hxcpp-debug-server]
hxcpp: 4.0.4 [4.0.8]
lime-samples: [7.0.0]
lime: 7.2.0 7.2.1 7.3.0 [7.5.0]
openfl: 8.7.0 8.8.0 [8.9.1]
thx.color: [0.19.1]
thx.core: [0.43.0]
yaml: 1.3.0 [fix-your-lib] git

---

Update: 1 July 2019

Some potentially useful insight was dumped into the chat.

Typically when discussing pausing a state in flixel, we expect something like setting state.active = false. As it turns out, this isn't how substates are handled.

The logic is here: https://github.com/HaxeFlixel/flixel/blob/master/flixel/FlxState.hx#L169

And the actual opening of the substate is here: https://github.com/HaxeFlixel/flixel/blob/master/flixel/FlxState.hx#L76

As I wrote in the chat:

Anyway, what it does do is if you check the logic, only the substate really seems to get updated while it's open, while the parent just kinda sits there doing a lot of nothing. It's written so that it checks to see if there's a substate and then... if substate - update substate... if not substate, update self. Well, something like that, anyway. I'm not quite awake yet, and a maintainer could give much better than I could just glancing at it.

This was followed up with some examination.

The conditional worth interest for "do we want parent doing things right now?" seems to be:

if (persistentUpdate || subState == null)

for the state itself. You can find this on line 171 in FlxState, as part of its logic for handling update checking around substates.

https://github.com/HaxeFlixel/flixel/blob/master/flixel/FlxState.hx#L171

Specific implementation from that note I don't know. But it appears that properly setting substates to null when they're closed is going on, and that would mean that check is the one we're interested in here.

[MSGhero]

So I don't forget... the best solution I thought of today was for each HaxeUI object (maybe the ones added to the main container group or maybe all of them) to keep track of the last time they were updated. If they were updated in the previous frame or something (compare to FlxG.ticks), then HaxeUI should consider them valid for mouse events. Otherwise, ignore them. The tick setting could occur within the normal overridden update(). This would fix substates and sprites/groups not added to the stage.

[greysondn]

I've updated my haxe version, haxelibs, and this thing's code since it was last visited. I could zip a new bundle if necessary, but that is in my repo no later than commit 0e93b20. (Specific folder: link)

The specific versions now, which are of interest for looking back over this thing's history, are:

flixel, git 4d23ed84 haxeui-core, haxelib 1.0.7 haxeui-flixel, git 110fd2ac

There's really nothing to observe as far as I can tell, other than that this still persists. I wish I had good news.

The copy/paste is strong with this one, I know.

---

Edit: I did come up with a workaround, but it's... kinda silly, honestly.

Specificially, the titlestate is changed from the above in this same comment: link

Comment out line 43 and uncomment line 46 to test the workaround version.

The substate in that specific project has no haxeui code in it... but haxeui apparently doesn't really care much about that when it comes to being told where to draw, so we just tell it where to draw the surface. So we treat it like a normal switch for context in haxeui and it just doesn't complain.

The total alt onclick is two functions there, lines 60 - 73:

    public function onSubAlt(ignored:UIEvent):Void
    {
        // this works by using haxeui's surface properties
        // and msghero's method of swapping in and out substates
        var _sub:ASubState = new ASubState(0x20000000);
        Toolkit.screen.options = {container : _sub};
        _sub.closeCallback = this.onSubAlt_close;
        this.openSubState(_sub);
    }

    public function onSubAlt_close():Void
    {
        Toolkit.screen.options = {container: this.uiGroup};
    }

I don't think I find this ideal, but at least as far as this testcase goes, it seems to work as a workaround. Victories wherever we can get them, right?