CEGUI (Crazy Eddie's GUI) Forums

Hi,

I'm pleased to announce that Dawntide has just upgraded to CEGUI 0.7.5 which is ~4 times faster than our last integration CEGUI 0.6.2. I'm quite impressed to be honest. Our UI is way more responsive now and doesn't hog the CPU anymore with quad updates when moving windows around. My thanks and gratitude to CE and his team, good job !

However there are still some issues with the new way the UI works. First, panels doesn't auto-place things inside which makes sense though I just didn't realize we had so many offsetted windows before. Next up is that I had a function to rescale widgets based on how many lines of text I had in them which doesn't work and CE supplied it to me so I'm not really sure how to upgrade it to 0.7.5 standards.



That is how I tried to patch the code since the commented line doesn't work and my "patch" always returns one line.

Next up is a real CEGUI bug that I thought is worth mentioning. I was creating a widget attached to a different widget from a hierarchy which is at base negatively offsetted on the Y axis. It turned out that when I was scaling it to fit entirely in it's parent window (with X and Y scale set to 1), after a setArea/setSize call the Y scale was 0 and the widget was rendered invisible. I debugged the code a bit and it gets clamped to 0 because the PixelSize.Y of the parent is reporting to be -10.



I was creating a widget inside which I was placing GuiMain/CastBar_Frame and then attaching it to GuiMain/CastBar.
However I've managed to fix this by specifying the size in pixels rather than scale.
Hope it helps.

As a side question, is there a way to enable color tags to multiline edit boxes ? I can add [colour='FF00FF00'] on a simple text widget but I can't on a multiline edit, which is what I'd prefer because of the vertical scrollbar/autoresize functionality. I only need it in read-only mode though.

I will probably leave the first pair of questions to CE as my knowledge of 0.6 is very limited.

Multiline EditBox can't be formatted yet because it makes very little sense as it's editable. You can make StaticText scrollable, just enable it's scrollbars.

see http://www.cegui.org.uk/wiki/index.php/SetProperty#StaticText, it's the HorzScrollbar and VertScrollabar properties.

HTH

PS: I tried Dawntide and it's very nice Keep up the good work.

Please post in the appropriate forum, as well as use the search tool, before posting. The reason for this is that an organized and less cluttered forum makes it easier for people to find answers. Thanks.

As a side question, is there a way to enable color tags to multiline edit boxes ? I can add [colour='FF00FF00'] on a simple text widget but I can't on a multiline edit, which is what I'd prefer because of the vertical scrollbar/autoresize functionality. I only need it in read-only mode though.

This question was just answered a few days ago.

I came across a new issue, scrollable panels no longer scroll unless you scroll over the area of the scroll bar, which is kinda weird.
I did some searching suggesting the MouseInputPropagationEnabled property but that thing does absolutely nothing.
search.php?keywords=MouseInputPropagationEnabled&terms=all&author=&fid[]=1&fid[]=10&fid[]=2&sc=1&sf=all&sr=posts&sk=t&sd=d&st=0&ch=300&t=0&submit=Search

Furthermore, I tried DistributeCapturedInputs on the panel and on the scrollbar and it still doesn't do anything. The posts were from CEGUI 0.7.2 though, so something changed from 0.7.2 to 0.7.5 ?

LE : Hm... a Window::EventMouseWheel message never gets to the panel, odd...
LE2 : This is awkward. The MouseWheel event isn't sent to ScrollablePane but to it's child ScrolledContainer which is not defined in the xml. Was this really the intended behavior ? Now I have to manually write code to add MouseInputPropagationEnabled to that child so that I can make the panel scroll.

LE3: Yet another issue, posting it here.



So we got a slider thumb which is in a hierarchy that doesn't have negative offsets so it's not the issue above. However the slider thumb's size says that scale on X and Y is -1.#IND000. Does the area tag have to define all edges and can't work with a leftedge/topedge/width/height combination anymore ?

Hi,

I just want to post a note to say that I have seen your issues, and I'll give a more detailed response as soon as I can. Before I can do that I have to test / check some of the things you raise, but I can't do that right now. I'd originally intended to try and get a reply up this afternoon / this evening, but there's quite a few things to check on and so I'll aim to get a reply up some time tomorrow. Sorry for not being able to answer more quickly, and thanks for your patience

CE.

Ok. I've finally managed to get around to testing or otherwise looking into most of the issues and other points you have raised.

... panels doesn't auto-place things inside which makes sense though I just didn't realize we had so many offsetted windows before.

I don't understand what you mean here - what is a 'panel'?

For the StaticText sizing, your code - or at least something similar could work, though you'd need to ensure the RenderedString copy you make is of the correct type. This said, however, I would use something like this:

To explain that, in case you missed it, the StaticText now exposes VertExtent (and HorzExtent) read-only properties to give you the pixel extents of the formatted text. Depending on various things, you may have to do a 'static_text->render();' or something to ensure the extents are updated by the time you access them, although in my test, the above code worked fine for me.

For the possible bug regarding sizes and ancestors with negative offsets, I could not immediately reproduce any issue. Though thinking it through in my head, I agree that an issue should definitely manifest itself, since negative sizes should not exist but we're not checking for them. I'll need to dig deeper into this in order to reproduce it before I can make any fixes.

The ScrollablePane issue where the ScrolledContainer is not propagating mouse inputs is confirmed. If you're interested in a fix/workaround, just obtain access to that window and enable the input propagation setting - this will pass those inputs back up to the main ScrollablePane window. I will point out that if you want the scroll to work when hovering over any random content you may have attached to the ScrollablePane, then the setting needs to be enabled on that content too (you could set this in the looknfeel for all appropriate window types in order to not have to do it manually all the time). Of course there is an argument to have this setting enabled on all widgets via the hard-coded default, although IIRC at the time when that setting was added doing that would not have been appropriate since maintaining some form of operational and/or behavioural consistency between point releases is something most would prefer Perhaps we can look at changing the default state of this for 0.8.0.

For the slider thumb, it sounds like this issue: viewtopic.php?f=3&t=5403

HTH

CE.

Thanks a lot for the rescale function, works great ! As for the panel, I seem to like to call it a panel instead of a pane I meant ScrollablePane-based widgets. Not a big issue, we've fixed it, it just made it look more obvious with 0.7.5.
As for the message propagation, yes, I wrote a function that goes through all widgets, checks for panes and sets the property. It's a pain though to add a single property to most widgets in a 7000 lines xml file. I think I'd rather enlarge the scope of that code fix if this becomes an issue.

For the slider, I made a code fix since I encapsulate a couple of widgets together in a class, so for each slider I manually set the scale of the thumb to 0 and use absolute sizes. I assume that patch is going to be featured in a future official version of CEGUI, right ?

LE : Ok, I found another issue. Given this piece of xml code


Something really odd happens. When I retrieve the RegionList widget it says scale.y = -0.069 and while that shouldn't account for a lot of pixels, I somehow don't see the widget. The issue is that the height is 1044 which is larger than it's parent initially. Switching that to say 144 fixes it though.

Yeah, the thumb fix is already in the source repository, as is a fix for the ScrolledContainer.

I'll have to look into the other issue soon; I can't comment before then, other than to say I've never seen any issues before with the scrollable pane. If that layout snippet is not a complete example, would it be possible to post a complete layout that uses one of the stock skins, in order that I can quickly and easily reproduce the issue?

Cheers,

CE.