So it has been a few days, and this morning on the bus the light bulb went off and I now know how I will get scroll bars to work.
I also have been contemplating a few other things....
First, after I release WZGUILib 3.0, I want to start screwing around with coroutines, in order to (possibly) add multithreading to WZ.
Last, I have been running an idea through my head every once in a while. I have been thinking that perhaps I should make WZ into a "Desktop environment". Here is some of the reasons:
1. ability to minimize windows, have multiple windows "full screen" at once. This is could be possible now, because I implemented backtab to switch between windows.
2. It might take a while, but I would develop an app system. How it would work is every "app" would be in a document stored in the library, the user then would install it by opening a dialog that asks for the path of the document. The apps would be able to have icons and other data that then would be displayed to the user. It would be persistant and would have to be uninstalled when they want to remove the program.
3. It would be more stable because less would be left up to the end programmer. A lot of WZ now is left up to the programmer, so they have to check themselves to make sure it is running properly and everything so the user has a nice experience, a desktop environment needs to run even if one app crashes. Again as with #1 I could implement this, the reason I haven't implemented a strict error recovery system is because I want to make WZ as small as possible. I may release a "WZGUILib Secure" edition in the future that would have very good error recovery systems.

Reasons Why I may be against such a Ludacris thing:
1. Less flexible. Right now it is very flexible and the programmer has lots of choice.
2. A "Desktop" environment would be a lot larger.
3. An app system using the current loading scheme would be heavy, this is why the style system wont be in the standard WZ, but in a separate release instead.

Tell me what you think, I would like to know.

I am, but it will definately be some time because I barely have enough time to work on the Nspire version. I plan on starting the prizm port right after I release WZGUILib 3.0 (this release), but I have to add a few features before I do release it. WZGUILib Prizm 1.0 will actualy be just a port of WZGUILib 3.0, and the versions will be numbered from there.

I still am working on getting it to clip right without having to resort to if statements in order to get it to clip right, is there a way to clip two things at once?

In the first image, it shows a blue square, that is 15 width and 15 height.
The second image shows the same blue square, transposed so that most of the square is clipped.
The last image shows that sub-objects wont be cropped when out of the forms borders, like they are supposed to be. This is also the case for other controls that contain controls.

Today I added a working graphics class, GraphDev.
Currently there are 3 parameters: parent; bgColor; screenInf
screenInf has two different inputs, "fs" which stands for Full Screen and a table of points.
fs will set it to use the full body of a form.
The table of points looks like this: {x, y, width, height}.
Right now I'm not sure if I want to keep the last argument or not, as I think the graphics control should take up the full screen.
how you add objects is a little different also...
To add an object the format is: GraphDev_Name:add(object).

Important information: In fs mode, it will erase any controls beneath GraphDev control.

I was wondering if that was what that was for, and I will have to test that out jim

Interesting...
Actually this could be good for me and a few friends.
At school we took an assload of old computers with windows 98/2000/xp, networked them togeather and have been playing Quake and Duke. If our IT guy lets us connect our mini-network to the schools server, this could be realy fun

Even though this is a little off topic, could the same commands sent by nRemote to the Nspire also be sent via arduino?