ListView ItemRenderer doesn't work

[krisj07]

Expected Behavior

When an ItemRenderer is defined as a child element of a ListView in the XML format, the item renderer should display the relevant values for the items in the ListView.

Current Behavior

When using an 'item-renderer' XML element in a listview, only the edge outline of the listview appears and no content is shown. Checkbox or image components in the item renderer cause the following exception:

Called from haxe/ui/core/ItemRenderer.hx line 76 Called from haxe/ui/core/ItemRenderer.hx line 130 Called from /usr/share/haxe/std/neko/_std/EReg.hx line 37 Uncaught exception - Invalid field access : __s

When a ListView is used without an item renderer, it appears to work normally.

Steps to Reproduce (for bugs)

To reproduce the bug I have used the ListView example code from the Component Explorer. The only difference to the Component Explorer XML is that I have commented out the checkbox and image components (which caused the exception) from the item renderers.

I have only tested this with the OpenFL backend, so I cannot say whether the issue is related to haxeui-core or haxeui-openfl.

Media

Test app / minimal test case

Please find attached the test app, I have run it as "openfl test neko".

HaxeUIListViewTest.zip

Your Environment

• Version used: haxeui-core 1.0.14, haxeui-openfl 1.0.0, openfl 8.9.5, lime 7.6.3
• Environment name and version: NekoVM 2.2.0
• Operating System and version: Ubuntu 16.04

[ianharrigan]

Yeah, something is up here. On haxeui-html5 they do work, however, when adding 100k items to the virtual listview, its slow, which it really shouldnt be (and never used to be) so there is a regression somewhere.

Im taking a look.

Thanks!

Ian

[ianharrigan]

OK, this should be fixed now, was a little oversight for a previous (kha related) fix. Good catch! Surprised it hasnt come up before to be honest.

If that works for you (latest haxelib haxeui-core) then can you close this?

Thanks again for the find!

Cheers, Ian

[krisj07]

Thank you very much for the quick response and update! With haxeui-core 1.0.15 the ItemRenderer works now when it contains a 'label' element, but having either a 'checkbox' or an 'image' element in the item renderer definition still causes an exception at the regular expression on line 130 of ItemRenderer.hx (} else if (~/^[0-9]*$/i.match(propValue)) {).

I tested this with the same example program, by uncommenting the commented out 'checkbox' element in the "lv2" list's (the non-virtual, custom renderer one) item renderer, and added a trace at line 128 (trace(propValue, Type.typeof(propValue));) of ItemRenderer.hx. The list appears to be rendered a few times (probably due to startup and resizing), and both the 'complete' and 'item' properties are shown to be String objects, until suddenly the type of one propValue of value "true" is shown as being TBool. This results in the if statement (propValue == "true") failing, so it then goes into the regular expression where the exception occurs.

The full stack trace for the exception is:

Called from ? line 1 Called from ApplicationMain.hx line 25 Called from ApplicationMain.hx line 130 Called from lime/app/Application.hx line 150 Called from lime/_internal/backend/native/NativeApplication.hx line 146 Called from a C function Called from lime/_internal/backend/native/NativeApplication.hx line 175 Called from lime/_internal/macros/EventMacro.hx line 91 Called from lime/system/ThreadPool.hx line 199 Called from lime/_internal/macros/EventMacro.hx line 91 Called from lime/_internal/backend/native/NativeHTTPRequest.hx line 451 Called from lime/app/Promise.hx line 108 Called from lime/net/HTTPRequest.hx line 112 Called from lime/app/Promise.hx line 108 Called from lime/app/Future.hx line 284 Called from lime/app/Future.hx line 129 Called from lime/app/Promise.hx line 108 Called from lime/utils/Assets.hx line 475 Called from lime/app/Promise.hx line 126 Called from lime/app/Future.hx line 129 Called from lime/app/Promise.hx line 108 Called from lime/utils/Preloader.hx line 286 Called from lime/utils/Preloader.hx line 202 Called from lime/utils/Preloader.hx line 304 Called from lime/utils/Preloader.hx line 218 Called from lime/_internal/macros/EventMacro.hx line 91 Called from ApplicationMain.hx line 113 Called from openfl/display/Preloader.hx line 48 Called from openfl/display/DisplayObject.hx line 1136 Called from openfl/display/DisplayObject.hx line 1497 Called from openfl/display/DisplayObject.hx line 1436 Called from a C function Called from openfl/events/EventDispatcher.hx line 402 Called from openfl/display/Preloader.hx line 252 Called from openfl/display/Preloader.hx line 213 Called from openfl/display/DisplayObject.hx line 1136 Called from openfl/display/DisplayObject.hx line 1497 Called from openfl/display/DisplayObject.hx line 1436 Called from a C function Called from openfl/events/EventDispatcher.hx line 402 Called from openfl/display/Preloader.hx line 101 Called from lime/_internal/macros/EventMacro.hx line 91 Called from ApplicationMain.hx line 116 Called from ApplicationMain.hx line 155 Called from openfl/display/Stage.hx line 1440 Called from ApplicationMain.hx line 143 Called from Main.hx line 12 Called from haxe/ui/core/Screen.hx line 37 Called from a C function Called from haxe/ui/backend/ScreenImpl.hx line 72 Called from openfl/display/DisplayObjectContainer.hx line 157 Called from openfl/display/DisplayObjectContainer.hx line 268 Called from openfl/display/DisplayObject.hx line 1497 Called from openfl/display/DisplayObject.hx line 1436 Called from a C function Called from openfl/events/EventDispatcher.hx line 402 Called from haxe/ui/backend/ComponentImpl.hx line 39 Called from haxe/ui/backend/ComponentImpl.hx line 48 Called from haxe/ui/core/ComponentValidation.hx line 208 Called from haxe/ui/core/ComponentValidation.hx line 208 Called from haxe/ui/core/ComponentValidation.hx line 208 Called from haxe/ui/core/ComponentValidation.hx line 208 Called from haxe/ui/core/ComponentValidation.hx line 208 Called from haxe/ui/core/ComponentValidation.hx line 208 Called from haxe/ui/core/ComponentValidation.hx line 205 Called from haxe/ui/core/ComponentValidation.hx line 170 Called from haxe/ui/core/ComponentValidation.hx line 228 Called from haxe/ui/core/ItemRenderer.hx line 76 Called from haxe/ui/core/ItemRenderer.hx line 130 Called from /usr/share/haxe/std/neko/_std/EReg.hx line 37 Uncaught exception - Invalid field access : __s

[ianharrigan]

OK, that should be fixed now in 1.0.16, was a neko only fix - i think ill move that code to somewhere more central anyway, but for now, the issue (for neko) should be resolved.

If that works, and you are happy with it all working, can you close the issue?

Cheers, Ian

[krisj07]

I've re-added both the 'image' and 'checkbox' elements to both the list views' item renderers, and can confirm that with haxeui-core 1.0.16 they both work. As far as I can tell, the list views sample now works on the OpenFL Neko target (and also on the CPP target) the same as in the online component explorer.

Regarding future development, am I correct in assuming that the ItemRenderer should support property values of any type (provided that the renderer has a subcomponent that can handle them)? In that case, instead of converting the propValue to String, would it be better to perform the Bool and Int parsing only in case the type of propValue is already String, as I think Std.string might cause performance issues with objects of more complex classes?

Thank you again for the quick updates and fixes, and for all your work on making HaxeUI such a comprehensive solution for making user interfaces!

[ianharrigan]

Yeah, agreed, there is another place (maybe two) that has something similar, i dont like it at all - i think its been left over for a while now. Ill remove it and replace it with something more "normal" and in a central location.

Anyway, glad its all working! :)

Cheers, Ian

[ianharrigan]

FYI, v1.0.17 now has this change in it: https://github.com/haxeui/haxeui-core/commit/bd90b027aab03775ca11473796586c33295d1902

Which i think is a better way to handle converting from strings to other types. Ive also dropped support for allowing "yes" and "no" for "true" and "false" in xml values, i think it was added at the very start "because" but its junky, i dont like it, and im pretty sure no one uses it that way anyway.

[krisj07]

I only now got to testing the new version, it works great! It is very convenient now to be able to define custom components for rendering values other than basic types or Strings, yet still be able to use XML for designing a complex item renderer.

Limiting the boolean values in XML to Haxe syntax sounds like a good idea for readability and consistency.