WLProgressBar colour

[Xothin]

Is there any way that the default color can be changed? I checked through most of the docs, and then checked out the WLook header and source for the progress bar and didn't see any way to get access to the variable that holds that value. CE?

[CrazyEddie]

Errrm. Not at the moment. When I first wrote the widgets I was of the mind that the default should be fixed; otherwise it wouldn't be a default. I'm now aware that this is hindering people who are changing the imagery in the image files.

There is a possibility that settings for these defaults may be added, although this will be obsoleted by the xml driven widget layouts, so at the moment I'm kind of on the fence about where my time is best spent

CE.

[Xothin]

No problem CE, if needs be, I can just use Taharez instead for my purposes and just create several different versions of the progress bar and use a different image for each one.

The reasoning behind my asking, is the WL progress bar does great for doing "health" bars, but having all of them the same color doesn't seem right. Maybe I can play around with the WLProgress bar code and code in a way to change the value on the fly.

You're doing GREAT work CE, I appreciate it the more I play with the system. ^.^

[CrazyEddie]

Maybe I can play around with the WLProgress bar code and code in a way to change the value on the fly.

That would be very easy to do. Just add a method to modify WLProgressBar::d_progressColour.

You're doing GREAT work CE, I appreciate it the more I play with the system. ^.^

Thanks

[gcarlton]

I too would like a coloured progress bar.

If you are going to do it, it wouldn't be too much trouble to add a general "SetProgressColour" method (or whatever) to the base ProgressBar, implement it in TL and WL, and then submit a patch for the rest of us. Having said that of course, I should point out I was too lazy/busy to do any of this, which is why I'm still interested now.

[Xothin]

The only problem with that, is that Taharez does not use a color.

This would have to be a WL only type thing, which is why I'm contemplating my course of action...

[Xothin]

after playing with it a bit, the only quick and dirty way to do this would be to create the method and allow both TL and WL to call it. TL won't allow this to be done though because it doesn't have this value.

Interesting thing to play with. ^.^

Maybe it's just me, but I may be overcomplicating things.

[CrazyEddie]

You could implement it in WLProgressBar alone, include the WLProgressBar.h header, and cast the pointer you have; not ideal, and potentially dangerous

Another option is to create a Property for it instead and use this. Using this approach means that you do not have to include any files or cast any pointers. You should surround the client app code that accesses this property with a try/catch construct incase the widget is of the wrong type and the property does not exist.

A third option (which I may implement next week ) is to promote the data field into the base class, and then you can hve the methodin the base class.

If I do go ahead with this next week, I'll use a ColourRect instead of a simple color; this will enable some simple effects to be applied to the progress bars

CE.

[Xothin]

I tried to make it into a property.. but apparently get is a string only function and it should be getting a colour. I tried hacking around in the code and every attempt, failed. =/

Tried as I might to get this in as an editable property, I couldn't do it.

I thought about the dangerous aspect, and decided that I didn't want to go that route. I'm in no real hurry for that functionality at the moment, I'll wait for your data driven widgets. ^.^

[CrazyEddie]

Yeah, the Property class deals in Strings, but there's a utility class: CEGUI::PropertyHelper that can convert the Strings returned from Property into something that many would find a bit more useful.
(Design Note: The Property class was the way it is to support easy IO of property data for XML files, and also as something that can be used from scripting languages if the whole set of window and widget methods are not bound).

I'm in no real hurry for that functionality at the moment, I'll wait for your data driven widgets. ^.^

You know that's still quite a way off though?

CE.

[Xothin]

I think I tried using that property helper, but I still couldn't get it to work right, since I needed a return value of colour.

More than likely it was something in the way that I did my casting, or didn't do as the case may be.

I've got some other work to do on the system ATM, but I will be revisiting this issue in the very near future. ^.^