Bar controls are no different to any other control.
All the necessary information to successfully control one is located in the aforementioned skin reference.
The only things I see that might appear confusing is when the control is first created. To get a better sense of what you're actually doing, build a bar, go to it's options menu, set it's Value to 50, set it's Width to 0, change it's Progress / slide colour to light green and it's Background colour to dark green. OK it and look at it in the editor.
That should give you a better idea of how the bar controls work. Play around with the Value setting to get the feel of it, then manipulate it in the code with winset().
Its not the building of the bar itself, its the coding the bar to the hp/mp/xp that is the problem for people with the lack of programming skills. (Or atleast me) You're right though, most confusion with some controls comes from when they are created and blank - but even more difficult (if you don't know the code, or proceedure) is making the control useful by tying it to the game.
| |
I know it's a long shot, but I'm hoping the last four years or so have made colored scroll bars easier to do than they were before; so here's a little bump for this.
I know there has been a major shift toward on-screen objects and such, which is great and all, but I think this would still be pretty helpful. I'm currently using a mixture of interface elements, and on-screen objects, and in my opinion a pretty fair amount of games may need to favor that which makes this remain a very useful feature. The default outputs always seems to be the easiest, and most efficient way to handle chat boxes as well; which further maintains the value of colored scroll bars. If it's too time consuming or difficult of a feature, though, then oh well. It just seems worth at least bringing back up in my opinion. Edit: I just noticed this was posted in the wrong section. I guess that's what happens when I find a thread through google, heh. Edit 2: Oh, seems someone fixed that. Awesome. Thanks to whoever did. | |
It won't have been made easier, really. The best I've managed so far, is a somewhat tempermental (I really wish people would post bug reports when it didn't work rather than calling it shit and moving on) browser-based output setup.
http://www.byond.com/developer/Ter13/ImageScrollbarDemo | |
Windows has some funky quirks about scrollbars going way, way back to its 3.1 days. It does some of their painting in deeply internal routines.
When I was last looking into this, a library called Detours was able to hook some of the routines responsible. It was kind of an iffy solution but it did work for some people. I didn't get as far as implementing it before we just gave up on it, because it was too much a waste of time then. About the only thing that's changed in the time since is that I ended up needing a sort of custom version of Detours for the pager project. Having that code on hand means I could probably handle the overrides needed if I looked them all up. However such a feature has an extremely low reward/time investment ratio, so it's still low on the list. | |
The only issue I personally have with the bar control is that I can't use it because I don't know the programming half to set it to hp, etc. So far I have just been using a text statpanel because it worked right off the bat.
Maybe a generate feature could be incorporated into certain interface controls? That would just be for the incapable like me though. heh..