[RESOLVED][Bug] ItemListbox redraw issue

[Ident]

In the context of the bug, by moving the wnd->addChild(p_list); after the for loop (both in the extract in my last post) I see the three expected items.

That's what I needed. Thank you, i will look into it in a bit.

[iceiceice]

Note that this bug is still active, I bumped this one just now: viewtopic.php?f=3&t=6220

but I think they might really be the same bug, not sure.

[Alain B]

Two years later, I confirm this bug is present on 0.8.7

I also confirm that the workaround described here by iceiceice (i.e. calling notifyScreenAreaChanged on the ItemListbox object after adding an item) does the trick for me.

[Ident]

Sorry for not having fixed this yet. I got a lot on my backlog and way too little time to do all of it

Since CEGUI is very trimmed on performance, we only update what is necessary. The notifyScreenAreaChanged call is basically a "nuke it all". Properly fixing this is a bit more complicated and we have had a few similar issues with other elements as well. However, if we use ths nuke-call carefully, especially in cases that happen not so often (like as you said, when the item is added), it should be safe to fix it using it in v0-8 as workaround, I believe. So this is what I will try to go for.



We might want to consider a rewrite of the caching/updating system for 1.0. But clearly this is out of the scope as a quick-fix for now

Thanks for getting back to this issue after such a long time btw.

[Ident]

I got the sample brower to compile on Gentoo. I'll propose them a patch for it. Contrary to what I first thought, there's no need to change CEGUI's cmake build.

On the other front, I reproduce the bug by simply adding the following block in HellowWorld.cpp, at the end of HelloWorldDemo::initialise (just before the return true; line). Didn't seem worth a patch since it's a single block copy/paste. Whole modified file is here.

Code: Select all

    CEGUI::ItemListbox * p_list = static_cast<CEGUI::ItemListbox *>(
        CEGUI::WindowManager::getSingleton().createWindow("TaharezLook/ItemListbox", "test_listbox"));

    p_list->setSize(CEGUI::USize(CEGUI::UDim(0.9f,0),CEGUI::UDim(0.9f,0)));

    wnd->addChild(p_list);

    for(unsigned i = 0; i < 3; ++i)
    {
        std::ostringstream oss;
        oss << i;
        std::string text = oss.str();

        CEGUI::ItemEntry * p_itm =
            static_cast<CEGUI::ItemEntry *>(
                CEGUI::WindowManager::getSingleton().createWindow("TaharezLook/ListboxItem", text));
        p_itm->setText(text);
        p_list->addItem(p_itm);
    }

    p_list->invalidate();
    p_list->show();

I added this before the return of the HelloWorld initialise function and I see 1,2,3 in the list without interaction with anything. Am I missing something?

[Ident]

We recently changed something in Window.cpp regarding the notifyDisplaySizeChanged call in there, which is now recursive. I think this might have fixed this bug as well. Would you have time to try out v0-8 ?

EDIT:
I just searched the commit and tried it out. Pre-commit : Shows 1,2. After commit: Shows 1,2,3. Fix is confirmed.

Changeset:

6606 (cfab39dac3b7) Fix for sizing of FrameWindow - the children windows that should become visibile …

[Alain B]

No need to be sorry about not fixing it. I know how backlogs are

With what renderer did you try it? Do you remember it's specific to the ogre renderer?

At the time the issue was reported, I had it with 0.8.4, using both my own app and the sample browser.

Right now, I just reproduced the issue with 0.8.7 and only my own app, not yet the sample browser. I'll try with the sample browser ASAP, just to be certain, and I'll come back to you.

[Ident]

I was editing my post when you wrote your last reply: v0-8 has the fix in it, I confirmed it, check my last edited post if you haven't

Edit: The fix would be in the next Release of 0.8, which would be 0.8.8

[Alain B]

Great thanks!

I love it when bug disappear as a side-effect of another fix

I'll edit OP title to mark it as solved.

[Ident]

I love it when bug disappear as a side-effect of another fix

I'll edit OP title to mark it as solved.

Thanks for marking it solved.

I also love it if fixes are multi-fixes.

Unfortunately, as hinted towards earlier, the call that was changed results in a bit more of recaching than might be needed (in other cases). But imho it is better to have everything working properly, than having something working unnoticably faster but with some bugs. I doubt anyone will notice a performance impact based off this and we discussed the fix beforehands thoroughly. There was just no better way without overhauling big parts of the caching system If performance concerns ever come up by any user, we will simply look at those specific use-cases causing them and see what can be done