So I have a question, Is there a way to totally delete an object from memory, not just from the table that contains the object?
I wonder this because table.remove only removes the object from the table, yet it still exists in memory.

Normally, if all references to an object are removed, the object will be destroyed. Lua will do this automatically, but you can force it. (see links Adriweb gave).
I'd suggest you to check if you really removed all the objects first, because forcing a garbage collection isn't the normal thing to do.

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.

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.

I hope so too. It is, so I think I'm going to have to make versions in order to keep it from getting too large, also I am working on tutorials to hopefully shorten the learning curve.

Here is a first look at the GraphDev control. I only have paint events routed to it right now, but it will be really simple to add the other ones in. I didnt fix the other issue I talked about earlier in my posts, but I will be implementing an if-then approach.

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.

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.

It wouldn't make the document size any bigger, it would use more memory because we have to use loadstring. I plan to do a lot of programming during Christmas vacation, especially on the days I don't work. I have to get a few more controls documented, then I will upload the documentation and the newest dev release(s).