Scrollbar colors were considered as one of the first items in 430 but ultimately turned out to be unworkable at that time. We may revisit that in the future, but the central problem is that it will require using a special library to hook into the Windows API. Microsoft stupidly made it all but impossible to override their default scrollbars, and in the many years since Windows 3.1 was first conceived they never thought developers might like to change things up.

Lummox JR

Mista-mage123 wrote:

Does this mean adding scrollbar colors would use MORE CPU? Well, it'd be ok only if that cpu was used when scrollbar colors were actually in effect

If you're referring to world.cpu, I seriously doubt things like this have any effect on that at all. The CPU usage in games that developers should be concerned with are caused by in-game processing (mostly in loops) like AI, HUD, and other continually running procedures. If anything, this may cause more CPU usage on the client-side, but if your computer is having trouble keeping up with BYOND; then its time to upgrade =P

Spunky_Girl wrote:

I see loads of websites, including Myspace of course, with changed scrollbar colors, so it couldn't possibly be taking up that much CPU

It's not really a question of CPU power; it's a question of how to handle the window messages that are related to scrollbars, of which there are many, and how to get standard controls to use custom scrollbars instead of standard ones. The process is not trivial, and merely overriding the control's window proc isn't even enough to ensure success because much of the handling of scrollbar drawing is built in at a very low level--a throwback to when Windows used to run on 80386 processors and 4M of RAM was considered very good.

The reason you see websites changing their scrollbar colors is that, frankly, you're using the wrong browser. Websites are only able to change their scrollbar colors by using nonstandard IE-specific CSS; the effect only shows up in IE, not in legitimate browsers. IE is hooked into the operating system well enough where making changes to scrollbars is easier to do. It's no coincidence that Microsoft decided to implement a glitz feature that pretty much only they would be able to easily replicate. However while Microsoft went all gung-ho on CSS during the browser wars, they never concerned themselves with implementing it properly; for that reason, IE has ongoing display problems on most pages on top of the gaping security holes it has from its reliance on ActiveX. It's also why the W3C disavows Microsoft's custom markup for scrollbars: It's not properly marked as a proprietary style.

Lummox JR

For what's it worth, I was able to change my design so it doesn't use scrollbars.

I actually need scrollbar-color for the window this time although that shouldn't make a difference.
ts

You over-exaggerate. I was making HTML websites before CSS was out and we use to change the color of the scroll bar all the time. The funny thing is IE IS a legit browser regardless of what YOU think.

I figured that if you put the same script into the chat box advanced window it should process it like html and change the scrollbar, I just haven't played around with it yet.

Honestly its way easier than you are making it out to be.

Maybe if the output (chatbox) options > style box supported javascript, or something, it could be done.

i'm using an output for the chatbox, how do you suppose the scrollbar changes color with that? So far the style box in options doesn't allow enough text and I don't even think anything works in it.

I don't know how to use the browser object it just stays white. What exactly do I need to do?

I put this little demo together which contains just enough to get you going. Hope it makes sense.

I pretty much whirl-winded it together so your getting what you pay for. ;)

http://www.byond.com/members/Tsfreaks/files/ BrowserChat_src.zip

ts

UmbrousSoul wrote:

You over-exaggerate. I was making HTML websites before CSS was out and we use to change the color of the scroll bar all the time.

Yes, with IE-specific HTML. The point is it's nonstandard, and doesn't work in other browsers; it never did. I too was making websites before CSS burst onto the scene. Netscape never supported scrollbar changes, nor does Firefox. W3C standards do not include any recognized attributes or CSS styles for changing scrollbars; it's exclusively the domain of IE extensions.

The funny thing is IE IS a legit browser regardless of what YOU think.

In that particular comment six months ago I was clearly being facetious. It's just a joke.

I figured that if you put the same script into the chat box advanced window it should process it like html and change the scrollbar, I just haven't played around with it yet.

The output control is not a browser; it is a RichEdit. All the HTML/CSS sent to it is parsed by the BYOND engine, which is why it supports only a limited subset of HTML as defined in the reference. (It also supports the BYOND-only "iconstate" attribute for img tags, which the browser can't do.) This control is incapable of supporting JavaScript.

Honestly its way easier than you are making it out to be.

Maybe if the output (chatbox) options > style box supported javascript, or something, it could be done.

Apologies in advance for the length of this, because the explanation alone is proof to the contrary.

JavaScript is just a scripting language; it is not in itself capable of bestowing properties like color or styling on anything. The reason JavaScript works is that the browser which runs it knows how to respond to different events; i.e., JS tells it what it wants to do and if the browser can comply, it will. IE, Firefox, Safari, etc. all have engines that run their JavaScript code. (And with some differences between each, I might add. IE in particular has some nonstandard function and property names, and bugs like returning incorrect results for getElementById in some cases. Firefox 3.5 has its own issues, since its new Tracemonkey engine is rather dodgy, so lest it be said I'm just bashing IE I'll state for the record that cross-compatible JavaScript has to cope with idiosyncracies in all browsers.)

When you change scrollbar colors in IE with JavaScript, what you're actually doing is just applying an IE-only CSS style. The script says "Change the style of the window to such and such." Then IE says "Okay, I changed the style. I see you want red scrollbars. I know how to do that. There you go." JS doesn't bestow the capability on the browser; it just asks the browser to use the capability it already has. IE is able to do this only because the people who wrote the code to change the scrollbar color also wrote the app itself, so the browser knows it has to use special function calls when it initializes or adjusts scrollbars. So having JS tell us to change scrollbar colors is really no different than having a parameter in the skin tell us the same thing.

The problem of custom scrollbar coloring is largely one of painting. The Windows OS provides all app windows with a client area and a nonclient area, the latter of which includes the titlebar, borders, close and min/max buttons, and scrollbars. Most parts of the nonclient area can be painted by the app in response to certain messages. Scrollbars however use a lot of code that was originally optimized for 80386 processors, where it made sense to do the drawing in an inline fashion instead of handling it through messages that could be hooked and redirected. So for many events that cause the scrollbar to repaint, the app is not asked to do it.

There are only two known ways of fully changing scrollbar color and style. One is to have total access to the code of the control where the scrollbars are used, so that special functions can be called during all scrollbar interaction; we thus have the ability to change scrollbars for anything like the Grid control, whose code for scrolling exists entirely at our end. The other way is to use a library to reroute the DLL calls an app makes to the Windows API. Since for us, changing scrollbar colors would ideally be an app-wide thing so we'd want it to affect all controls (not just grids and panes), and since the DLL rerouting thing looked like too much of a difficult project to get into at the time, custom scrollbars were set aside until a later date.

So that, in a nutshell, is why custom scrollbars are not implemented yet. As someone who has studied the specifics of the problem in excruciating detail, I can assure you that it is in fact no easier than I have made it out to be. I wish that it was; this is a feature I would very much like too. The best we can do at present is styling grids and panes only, and I think you would agree that that would look bad in an app that also uses browsers and output controls. This is something we may revisit at a later date, because we know it can be done--just with more difficulty than was warranted at the time.

Lummox JR

UmbrousSoul wrote:

Well thanks for the explanation. I tried several work arounds like making the output transparent and trying to put a stand alone background behind it but the transparency was so strong it actually goes all the way through the window and to whatever programs are behind it.

Yes, Windows has this concept of allowing a color to be keyed as transparent, something they introduced in Windows 98, but it affects the whole window. While we do have that setting available, this limitation is documented in the skin reference. There is unfortunately no way to make individual controls transparent on a reliable basis, and it's actually for much the same reason that we can't control scrollbars. Some of the controls, like RichEdit, we don't truly control the drawing for, which is a must for transparency. With the output control it was actually a significant challenge to support a background image.

I couldn't get it to work so I just searched it up for the max line limit. Which really I should have known to use but I guess I didn't know I had to set it from 1000 to 30. Anyhow it worked and currently I can see why colored scrollbars are not really needed with the build in max line function that autoscrolls the text without the need of the scrollbar.

I'm glad you found a workaround that fits your needs. Eventually I would like to have colored scrollbars anyway because it's something that feels like it's missing. The project to make them though was taking up a lot of time (this was back just before the 430 build) and not getting very far, and the discovery of what we would need to do for the full solution pointed to an even greater time investment, so that's why it was set down. After that, effort went into some other feature requests that were more readily feasible, which included scrollable panes, lockable child controls, and above all the new bar control.

Lummox JR