Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating a long label inside a scrollable and then switching states causes a crash #16

Open
greysondn opened this issue Jun 13, 2019 · 2 comments

Comments

@greysondn
Copy link

greysondn commented Jun 13, 2019

Please feel free to rename that. I suck at naming bugs.

This is in my repos as 02-textflownull - the version attached to this post is just commit b671345 zipped up.

Here is the same attachment: 02-textflownull.zip

I've done a decent writeup in the readme, so I'm just going to dump that here.

Edit: Special attention should be given to FAQSubstate, line 45. If you comment out this line, the error no longer occurs. Here it is linked in my repos at the specific commit. Link.


For some odd reason, text reflow in haxeui-flixel just breaks in flash. So this
is an attempt at a minimal case for that.

Open the substate and close it. It should fail for sure in Flash if I did my job right.

Late insert: And HTML5, and Neko.

Yes, this is just copy+paste my current setup, with much of the cruft cut away. The classpaths were left in place.

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    - crashes (this bug)
html5    - crashes (this bug)
hashlink - build fails (probably different error)
neko     - crashes (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
@MSGhero
Copy link
Member

MSGhero commented Aug 23, 2019

It's apparently erroring on your ScrollView's scroll bar, which is weird. It only occurs when you mouse over the FAQ button, when the scroll isn't on the page, so that's weird. It's also weird that adding text to a label makes the error not happen. The second one makes me think it would resolve itself or become easy to debug after #17.

Easy fix is to add destroySubstates = false in your TitleState, but the underlying problem remains.

@greysondn
Copy link
Author

greysondn commented Dec 1, 2019

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 110fd2a

Edit: Of specific note is that the substate switch now uses the method you originally proposed as opposed to my wrapper classes. I'm trying to gravitate this towards something easier to work with as it seems to persist and will require more and more prodding. This simplified the code by at least 3 classes.

I did not try

add destroySubstates = false in your TitleState

yet, as this issue is about the underlying issue and I didn't have it open when I worked at the code. I'll try it and edit to tell you if that works or not. (I imagine it does, but "the process" and all.)


Edit: That does indeed work. I can only assume it's bad karma as it leaves something uncleaned in memory, but I wonder if there's a good way to destroy that manually after the return for a more robust workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants