ListItermRenderer background hide ListView border

[hypergeome]

I have a listview with several rows of data. The data rows hide listview border

Expected Behavior

The data rows does not hide listview border

Current Behavior

The data rows hide listview border

Possible Solution

Currently, I have to make itemrender width=99% and horizontalAlign="center" so that it wont hide the list border

Steps to Reproduce (for bugs)

1. 2. 3. 4.

Media

Test app / minimal test case

DemoListBug.zip

Context

Your Environment

• Version used:
• Environment name and version (e.g. Chrome 39, node.js 5.4):
• Operating System and version (desktop or mobile):
• Link to your project:

[ianharrigan]

What backend are you using?

EDIT: i can see its openfl by the project - thanks

[ianharrigan]

So, i actually had code to fix this sitting on a branch relating to something else - focus borders - i noticed the same thing there when i set different border sizes it "cut off" the content of the listview because the listview layout (well, scrollview really) was not taking border sizes into account when it calculated its usable size. Ive extracted just that part from that branch, so this should be fixed now.

Let me know if that fixes it, and this issue can be closed.

Cheers, Ian

[hypergeome]

It is openfl On Thursday, June 24, 2021, 11:45:31 AM GMT+7, Ian Harrigan @.***> wrote:

What backend are you using?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[hypergeome]

Thank you

[hypergeome]

So, I am using haxelib version of haxeui 1.2.3. I use your files for fix 395 including: haxe/ui/layouts/Layout.hx + ScrollView.hx and haxe/ui/styles/Style.hx + ValueTools.hx, the issue is still there.

I tried to use git version. But the component macros inform error on my xml files and failed to compile.

[ianharrigan]

I tried to use git version. But the component macros inform error on my xml files and failed to compile.

What errors? Are you using git versions of haxeui-core and haxeui-openfl?

[hypergeome]

Yes, so, I tried to use git version of both haxeui-core and haxeui-openfl. My project failed to compile because of component macros. It said something about issue with Constraint on findComponent method. below is the error

C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/macros/Macros.hx:213: characters 29-42 : Constraint check failure for findComponent.T C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/macros/Macros.hx:213: characters 29-42 : { text : haxe.ui.util.Variant } should be haxe.ui.core.Component src/dialogs/ConfirmPopup.hx:9: lines 9-34 : Defined in this class. .... .... ... ... C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/macros/Macros.hx:196: characters 25-38 : Constraint check failure for findComponent.T C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/macros/Macros.hx:196: characters 25-38 : { visible : Unknown<0> } should be haxe.ui.core.Component src/dialogs/InputPopup.hx:10: lines 10-51 : Defined in this class .... C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/macros/Macros.hx:196: characters 25-38 : Constraint check failure for findComponent.T C:/HaxeToolkit/haxe/lib/haxeui-core/git/haxe/ui/macros/Macros.hx:196: characters 25-38 : { text : Unknown<0> } should be haxe.ui.core.Component src/dialogs/InfoPopup.hx:9: lines 9-25 : Defined in this class

Below is my content of confirmPopup.xml for ex

<?xml version="1.0" encoding="utf-8" ?>

---

If I use current haxelib version of both (1.2.3), it compiles, but this issue is still there.

[ianharrigan]

can you paste "InfoPopup.hx" ?

and "InputPopup.hx"

[hypergeome]

I am attaching related hx file and xml file assets.zip dialogs.zip

[ianharrigan]

Thanks, thats helpful... do you think you could also include / paste how you are calling these dialogs please?

[hypergeome]

They are all the ssame and simple. Below is an ex @:bind(btnEnterCode, haxe.ui.events.MouseEvent.CLICK) function onEnterCodeClick(e){ var dlg:InputPopup = new InputPopup(); dlg.promptText = "Enter your peer contact's one-time code:"; dlg.okButtonText = "NEXT"; dlg.onOK = function(codeHex:String){ onHaveCode(codeHex); } Main.appContainer.popup(dlg, false, false); }

Main.appContainer.popup simply push dialog into a VBox component to be displayed.

[ianharrigan]

Hmmm, all very strange... code looks totally fine, and everything compiles find this end... Ill try and setup exactly how your are doing things, but it looks totally reasonable to me.

[hypergeome]

I am also trying to create one example to see if the error is informed

[ianharrigan]

That would help alot - minimal examples are defo helpful... feels like a bug to me in core

[hypergeome]

DemoListBug.zip Ok, attached is the demo. Th esame one I sent you before for issue 395. But I simply add InfoDialog into it and it fail to be compiled.

[hypergeome]

Update, please hcek previous message for demo. Here is my environement setup in case you want C:\Windows\system32>haxelib list actuate: [1.8.9] air4haxe: [1.0.0] box2d: [1.2.3] haxeui-core: 1.2.3 [git] haxeui-openfl: 1.2.3 [git] hscript: [2.4.0] hxcpp: [4.2.1] layout: [1.2.1] lime-samples: [7.0.0] lime: [7.9.0] msignal: [1.2.5] openfl-samples: [8.7.0] openfl: [9.1.0] thx.core: [0.44.0] thx.promise: [0.7.0]

[hypergeome]

In any case, you can use the haxelib version of haxeui-core and haxeui-openfl, it will compile fine.

[ianharrigan]

what version of haxe? Compiles find this end (after i add public static var appContainer:Dynamic; to Main just to get it to compile Main.appContainer.closePopup())

[hypergeome]

I use haxe 4.0.5. I could not use later version because of macros issues.

[hypergeome]

I use haxe 4.0.5. I could not use later version because of macros issues. Btw, you can remove everything in onCloseClick (i.e. Main.appContainer stuffs. It is from my project

[ianharrigan]

I could not use later version because of macros issues.

I use 4.2 and havent had any issues btw

I use haxe 4.0.5.

Cool - lemme downgrade and see if i can reproduce

[hypergeome]

Yes, I upgarde to haxe 4.2.2 and it compiles

[ianharrigan]

Cool - and when i downgrade to 4.0.5 is doesnt... so i can reproduce... :)

Now just to find out whats wrong :)

[hypergeome]

So, after upgrading to haxe4.2.2, my project has another issue with your macro. It is property binding. So, inside a component ContactNavigtionBar, I have child component UserIcon. Inside ContactNavigationBar, I bind a property to userIcon.textDisplay and it fail to compile. Let me try to repdocue it in a demo project.

[hypergeome]

Here. Another demo that show issue with component macro with haxe4.2.2 DemoListBug1.zip

[ianharrigan]

OK, so i added some fixes for 4.0.5, however, i would be interested about your binding issues also (i did add a fix for binding in latest haxeui-core but it may not be related to you issue so it might be worth trying with latest first)

Cheers, Ian

[hypergeome]

Please check previous message. I attached DemoListBug1 for macro+bidning property issue.

[ianharrigan]

hmmm, so i think this is a typing order issue... it may take a little more time... im actually surprised the issue isnt here in 4.0.5 also...

For now you can (should) be able to go back to 4.0.5 and not have errors with git versions while i think about this issue.

Cheers, Ian

[hypergeome]

With haxe4.0.5 and haxeui git version. It will still have macro issue for property binding. So, currently, i will stick with haxe4.0.5 and haxelib version of haxeui.

And yes. Thank you so much. Just take your time. It is not urgent. I have to go to bed now.

So, to sumup:

1. With haxe4.2.2 and haxeui git version. My project still not compile because of the macro issue with property binding.
2. With haxe4.0.5 and haxeui git version: Still the same as 1, but your fixes for haxe4.0.5 and previous macro issues works.
3. I doubt even if you fix this macro issue and it compiles, the Itemerender hide ListView border issue will still exists. I think you were missing something when extracting the fix from other branch.

Cheers,

Cat

[ianharrigan]

I doubt even if you fix this macro issue and it compiles, the Itemerender hide ListView border issue will still exists. I think you were missing something when extracting the fix from other branch.

I dont think thats accurate, i think there are other parts you are missing when you just paste in that fix, thats why you need to use git to get everything in core and backed.

Anyways, thanks for the examples - ill try and get this fixed asap, i have already fixed it, but im trying to find a better solution.

[hypergeome]

Issue 3 is confirmed. I commented the property binding to make it compiles. So, with git version of haxeui-core and haxeui-openfl, the issue of Itemrenderer hide ListView border is still there.

Also, the git version has other positioning issue. My GUI is messed up alot,

[ianharrigan]

I dont really see how that is possible, this is your app from the original issue:

[hypergeome]

Let me try with haxe4.2.2

[hypergeome]

Sorry, my bad. It works. I must have swap out of git version.

[hypergeome]

So, haxeui on git does fix ListView border issue. But it is not totally correct. It did not take scale into consideration. Why do I need scaling? My app is for android too and I must work with exxact pixel positioning and can adapt to multiplle device screen size.

DemoListBugNandPositionBug.zip

Attached here is a demo that shows the issues. You can see that part of the ListView border where there are rows is still hidden a bit.

Also, If you click on open dialog button, you will see the dialog is positioned wrong. It should be at the center of the screen. This position issue does not exist with haxelib haxeui version of 1.2.3. Also, on my real project, there are other position issues. But I think they maybe all the same.

[hypergeome]

Hi Ian, any progress on this? Please check my previous message for sample about ListView border and positioning issue.

[ianharrigan]

So, there are a few weird things in your app / test... the first is ive never really heard of a scale < 1... what i think this is doing is its making lines / cords < 1px and openfl is having a tough time drawing them.

The other thing about centering the dialog, i had to put a "validateNow()" for the popup function... im not sure how this ever worked in previous version, if you trace out the widths etc of the components that function "popupView" is always 0 (without the validateNow), eg:

    public function popup(comp:Component, isAbsolute:Bool = false, isCloseOnClick:Bool = false){
        this.popupView.visible = true;
        this.popupView.includeInLayout = true;
        this.popupView.validateNow();
        trace(popupView.width, popupView.actualComponentWidth, popupView.componentWidth, comp.width, comp.actualComponentWidth, comp.componentWidth);
        comp.left = (popupView.width - comp.width) / 2;
        comp.top = (popupView.height - comp.height) / 2;
        this.popupView.addComponent(comp);
    }

Can you explain the scaling thing to me? Why not just let haxeui handle the scaling for mobiles?

[hypergeome]

Sorry, my bad. I set width=100% and height=100% in mainView.xml in the project that I sent you which is wrong. It should be just .

Attached here is the correct demo. You can try with haxelib version of haxeui-core and haxeui-openfl and see that it works correctly, i.e. the mainView fill the screen and the dialog is centered on the screen, and totally wrong for git version.

I traced in code and see that Screen.instance.width, Screen.instance.height, are 1604,3208 on my computer for git version which is wrong. For haxelib version, they are correctly 400, 800 which are the values set in project.xml.

FixedDemo1.zip

About the scaling thing, it is simple:

1. We design GUI on a screen of fixed value WIDTH and HEIGHT whiich are 801 and 1424 pixels.
2. All the elements on view are exact pixel in postion and size. and in coding/xml, we just follow those exact values.
3. Wrapping all of the above for different screen sizes, we scale the whole UI as you see in Main.hx, where we set Toolkit.scaleX = SCALE; and Toolkit.scaleY = SCALE;
4. So far, it works for haxelib version of haxeui-core and haxeui-openfl.

[hypergeome]

Update: Please also check previous message for new demo project.

So, there are a few weird things in your app / test... the first is ive never really heard of a scale < 1... what i think this is doing is its making lines / cords < 1px and openfl is having a tough time drawing them.

I dont think this is correct as the border is rendering fine. Just the part where there are list item that it is hide a part of the line. You can compile my new project with haxelib version of haxeui-core and haxeui-openfl and see

[hypergeome]

Update: Please also check previous messages for new demo projects and issues and explanation for scaling.

Can you explain the scaling thing to me? Why not just let haxeui handle the scaling for mobiles? Is there other way to do scaling the whole UI instead of setting Toolkit.scaleX and Toolkit.scaleY? I dont understand what you mean by "let haxeui handle the scaling for mobiles". How? It will works for different screen sizes for different types of devices?

[hypergeome]

Update: Please also check previous messages for new demo projects and issues and explanation for scaling.

Why not just let haxeui handle the scaling for mobiles?

Is there other way to do scaling the whole UI instead of setting Toolkit.scaleX and Toolkit.scaleY? I dont understand what you mean by "let haxeui handle the scaling for mobiles". How? It will works for different screen sizes for different types of devices?

[hypergeome]

There has been so many messages. So, I sum them up here again.

The other thing about centering the dialog, i had to put a "validateNow()" for the popup function... im not sure how this ever worked in previous version, if you trace out the widths etc of the components that function "popupView" is always 0 (without the validateNow), eg:

So, first, the project I sent you before was a little bit wrong. In mainView.xml, I set the wrap vbox width and height to 100%, whcih makes it display incorrect. It should just be vbox tag alone, no width and height and code to set it in new of MainView will have effect. Attached here is the updated project FixedDemo1.zip

You can try with haxelib version of haxeui-core and haxeui-openfl and see that it works correctly, i.e. the mainView fill the screen width and the dialog is centered on the screen. If you compile with git version of haxeui-core and haxeui-openfl. It is totally wrong. I traced in code and see that Screen.instance.width, Screen.instance.height, are 1604,3208 on my computer for git version which is wrong. For haxelib version, they are correctly 400, 800 which are the values set in project.xml. So, this is the root issue of all I think.

So, there are a few weird things in your app / test... the first is ive never really heard of a scale < 1... what i think this is doing is its making lines / cords < 1px and openfl is having a tough time drawing them.

I dont think this is correct. The border is rendered correctly, but where there is list row data, the border is hidden a part (thinner).

Can you explain the scaling thing to me?

About the scaling thing, it is simple:

1. We design GUI on a screen of fixed value WIDTH and HEIGHT whiich are 801 and 1424 pixels.
2. All the elements on view are exact pixel in postion and size. and in coding/xml, we just follow those exact values.
3. Wrapping all of the above for different screen sizes, we scale the whole UI as you see in Main.hx, where we set Toolkit.scaleX = SCALE; and Toolkit.scaleY = SCALE;
4. So far, it works for haxelib version of haxeui-core and haxeui-openfl.

Why not just let haxeui handle the scaling for mobiles?

Is there other way to do scaling the whole UI instead of setting Toolkit.scaleX and Toolkit.scaleY? I dont understand what you mean by "let haxeui handle the scaling for mobiles". How? It will work for different screen sizes for different types of devices? So far, using Toolkit.scaleX and Toolkit.scaleY works for me.

[ianharrigan]

OK, so i can see the "weird" values for Screen.instance.w/h, thats is because (i believe) that these is the width from openfl / the toolkit.scale... This is done so % widths work correct across scales (which they arent in 1.2.3).

Where do your 801 and 1424 values come from? They seem arbitrary and, to me at least seem like you will end up with some really nasty scale values across devices.

Is there other way to do scaling the whole UI

This is what i meant by letting haxeui do the scaling for your, ie, dont touch the scale, and use % widths / heights. Haxeui will set and appropriate scale based of the devices DPI value. You can turn this off by setting Toolkit.autoScale = false or, as you have done, setting the scale explicitly. Consider the following layout:

<vbox style="padding: 5px;" width="100%" height="100%">
    <hbox width="100%" height="100">
        <button text="Header 1" width="50%" height="100%" />
        <button text="Header 2" width="50%" height="100%" />
    </hbox>

    <listview width="100%" height="100%">
        <data>
            <item text="Item 1" />
            <item text="Item 2" />
            <item text="Item 3" />
            <item text="Item 4" />
            <item text="Item 5" />
            <item text="Item 6" />
            <item text="Item 7" />
            <item text="Item 8" />
            <item text="Item 9" />
            <item text="Item 10" />
            <item text="Item 11" />
            <item text="Item 12" />
            <item text="Item 13" />
            <item text="Item 14" />
            <item text="Item 15" />
            <item text="Item 16" />
            <item text="Item 17" />
            <item text="Item 18" />
            <item text="Item 19" />
            <item text="Item 20" />
        </data>
    </listview>     

    <hbox width="100%">
        <button text="Another" width="100%" />
        <button text="Thing" />
    </hbox>      
</vbox>

If you used that example, but DIDNT set the scale explicitly in your code then that should look fine / similar on all devices (including desktop) without some weird scaling at .4999

I dont think this is correct. The border is rendered correctly, but where there is list row data, the border is hidden a part (thinner).

Yeah, looking again, you could be right, but i still think asking openfl to draw (or create clip rects) at sub pixel sizes is going to cause problems - even potentially in performance.

I honestly dont get why a) there are these strange and very specific values for app width / height and b) why the scaling is being used in that way in general. I could just be me, but i think you are going to end up with quite a strange looking app across different devices, and, likely on some with very blurry text - but maybe im just missing something still :)

[hypergeome]

OK, so i can see the "weird" values for Screen.instance.w/h, thats is because (i believe) that these is the width from openfl / the toolkit.scale... This is done so % widths work correct across scales (which they arent in 1.2.3).

Yes, you are right. So, git code update Screen.instance.width and height when setting Toolkit sclae. The issue of my code is setting Toolkit.scaleX and scaleY BEFORE recalculating APP_WIDTH and APP_HEIGHT using Screen.instance.width and height. Just change the order of code and it works.

Where do your 801 and 1424 values come from?

Those 801 and 1424 are from the designer. I think those are the average values of current different devices size or maybe it just looks good in our designer eyes :).

They seem arbitrary and, to me at least seem like you will end up with some really nasty scale values across devices.

They seems arbitrary to me too :). But it looks fine. You can see that in my code, I set both Tookkit.scaleX and Y to the same value SCALE which is the min value between APP_WIDTH / Screen.instnace.width and APP_HEIGHT / Screen.instnace.height, The result is that app GUI it will fill the whole screen width (in portrait mode) and keep aspect ratio of the GUI accross devices. The only problem is that for devices with quite long screen, our app GUI will not make use the bottom portion of the screen where it greater than 1424 / 801.

This is what i meant by letting haxeui do the scaling for your, ie, dont touch the scale, and use % widths / heights

Ah, yes. Relative layout and % will work without the need of setting scale explicitly like me. But we dont want that. We want PIXEL EXACT looks of GUI according to the GUI design. In short, the designer gives me a photoshop file for GUI design with exact position and size info. I just follow that design in xml and code and the result looks the same as the GUI design.

Yeah, looking again, you could be right, but i still think asking openfl to draw (or create clip rects) at sub pixel sizes is going to cause problems - even potentially in performance

I am not sure. But as far as I see, the whole list border is rendered fine. Just the part where there is list row data that the border is thinner. So, apparently, I think the itemrenderer size is still not correctly calulated in this case, i.e. setting Toolkit scale like me.

[ianharrigan]

I am not sure. But as far as I see, the whole list border is rendered fine. Just the part where there is list row data that the border is thinner. So, apparently, I think the itemrenderer size is still not correctly calulated in this case, i.e. setting Toolkit scale like me.

You could be right, it could also be that the scrollRect is being rounded by one pixel over, making it look like an overdraw... ill have to check it out...

So am i right in thinking that, apart from that border issue, which is essentially the original issue, there are no other issues? Ie, the screen width / height make sense to your app?

[hypergeome]

So am i right in thinking that, apart from that border issue, which is essentially the original issue, there are no other issues? Ie, the screen width / height make sense to your app?

Yes, but not quite. There is also the property binding issue that results in macro error when compiling with git version which I already sent you demo project about it. I can work around that by not using property binding, instead, using setter. Still, I think I should let you know about that.

[ianharrigan]

There is also the property binding issue that results in macro error when compiling with git version which I already sent you demo project about it.

Yeah, thats already on my radar 👍

[hypergeome]

This is just a small reminder about this issue. It is still there on haxeui-core and haxeui-openfl 1.4.0. It is not important, we can work around by setting itemrenderer width to 99%. DemoListBug.zip