Updating WZGUILib

[jwalker]

Does anyone know the best way to implement scroll bars? I was thinking about how to do it, but im not quite sure how to calculate when the scroll bars gets larger and smaller depending on what is in the scrollable area.
Also for those who tried the dev release/preview, what did you think about the toggle switch, if you noticed it?

[Jim Bauwens]

Sorry for the late reply.

]

So I had a thought about something that I may do.
I havent realy been able to test out the style system that I proposed, although today I may get Time, but this idea could go hand in hand with it.
What I was thinking about doing was hidding the main events that drive WZ (on.click, on.paint, etc...), and do this instead:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8

--create a window in on.create, which will still be 'visible' to the user   window = form(...)      --then after on.create we would have the new 'events'   window_paint(gc)   window_click(x, y)--where x and y is the location of the pixel in the forms body   window_etc.....

all controls would also work similar, so it is kind of like VB.net, or C#.
I thought that this could be released in a WZGUILIB_EventDriven stylepack, or maybe it could be integrated into all WZ versions, although that would be a more radical aproach.

Well, I think you want is a 'screen manager' (well, that's what certain Lua coders call it).
Here is the code for a very simple one: (warning, not tested might contain a bug)

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

--Screen manager code screens = {} function current_screen()     return screens[#screens] end function push_screen(screen)     table.insert(screens, screen)     platform.window:invalidate() end function pull_screen()     platform.window:invalidate()     return table.remove(screens) end Screen = class() function Screen:paint() end function Screen:arrowKey() end function Screen:enterKey() end function on.paint(gc)     for _, screen in ipairs(screens) do         screen:paint(gc)     end end function on.arrowKey(arrow) current_screen():arrowKey(arrow) end function on.enterKey() current_screen():enterKey() end -- User code main = Screen() function main:paint(gc)     gc:drawString("Hello World", 10, 10, "top") end function main:enterKey()     push_screen(sub) end sub = Screen() function sub:paint(gc)     gc:fillRect(10,10,20,20) end function sub:enterKey()     pull_screen() end push_screen(main)

Take a look at this tutorial too: http://www.inspired-lua.org/2012/02/how-to-create-a-screen-manager/
And if you want at https://github.com/adriweb/EEPro-for-Nspire/tree/master/Global%20Libraries (screen.lua and widgets.lua) for example of a real life implementation.

Does anyone know the best way to implement scroll bars? I was thinking about how to do it, but im not quite sure how to calculate when the scroll bars gets larger and smaller depending on what is in the scrollable area.
Also for those who tried the dev release/preview, what did you think about the toggle switch, if you noticed it?

Regarding the scrollbar, check out my implementation of it in widgets.lua (in the above link). Basically, I have three parameters for my scroll bar.
total: the amount of lines/whatever I need to scroll
visible: the amount of lines/whatever that you can see
top: the current line/whatever that you are on.

With this information I easily can calculate how to draw my scrollbar.

I haven'y noticed the toggle switch.

[jwalker]

I all ready implement a screen manager, it just looks a little diffrent from yours because it considers every form a screen, and has to switch between the forms.
What I mean is that say I have something like form:paint(gc), which is already there, everytime it is called to repaint the form, it would call something like form1_paint(gc), giving WZ its own 'events'.
The toggle switch is on the very bottom of the class definitions in the last file that I uploaded, I have some creation code commented out.
It looks like:

Code: Select All | Copy To Clipboard

1 2 3 4

--toggle test 0.1     --t1 = toggle(50, 100, true, form1)     --t2 = toggle(1, 1, false, Tabs.atab)

thanks for the link to your scrollbars class, I think it will help.

[jwalker]

So today I came home after work and decided to take a look at what WZGUILIB might look like in C, for use on the prizm, and I definately think that porting it wont be that difficult. But I ran into a problem....
My Prizm emulator trial ran out and I dont want to ruin my prizm.
So as an effect of that, I will be writting out the first C version in Nspire C , and once school starts I will download the prizm emulator on one of the schools computers and directly port WZ to the prizm. The WZ headers them selves will have barely any platform specific code in them, so I can easily port it.
The only problem right now is.... nRGBLib draws out its chars way to large, in the image, the title is bieng drawn out at a size of 1.
 I only drew out the body, frame and title of the form, as you can see. It will have the two circle buttons in the end.

[adriweb]

Well that's a very nice idea

[jwalker]

thank you

[Nick]

imo the title isn't toooooo big, is it? i think it fits fine, it does not overflow the area, so that's good enough i think..

it's nice to see the progress, i just can't test your latest versions because i'm staying at OS 3.1 for  ndless reasons

[jwalker]

Thats what Im doing with my CX, and I added the files to the bottom .
The WZ_ST_LIB should work on all versions.

Excuse my double post...
I am happy to announce that I hav successfully got the 'lib' system to work.
Currently, I have only moved the paint code to the lib, but I will move the rest later.
This is a proof of concept release, it is a v3 development version.
I tested these two files on both the computer and my old light blue greyscale nspire.
What this could allow is:
  Easily create styles for WZGUILIB.
  Easily switch styles durring execution.
  Editing how the GUI objects look and work on calc (great for me and style developers).
  Allow multiple styles on one calc without having to have several diffrent versions of WZGUILIB.
  *Allow to only have some class code loaded.

Questions and comments are definately welcome

**********************How to set up**********************
send both files to your calc
place WZ_ST_LIB.tns inot your MyLib folder
Refresh your libraries
execute WZ_LibTST

*I havnt yet implemented it.

the setup instructions are at the bottome

[Nick]

that's what i did, and it tells me this:

"You must update your software to the latest version to view this document.
WZ_LibTST.tns.
Visit education.ti.com to update."

so i guess that's because of the os

[jwalker]

ok, I know whats going on....
I think the problem is that it is trying to open the WZ_ST_LIB.tns file to read the variables, because the lua script that I just posted should work on all versions.
So here is what You will have to do, to have 'Styles' and the dynamicaly loaded strings.
Make a new file called WZ_ST_LIB.tns (this way you dont have to change anything in the WZ_LibTST lua file) and paste the code snipits into it from the file that I provided.

I divided each one out with: ------------------------------------------name of control----------------------------------------------

copy everything into the file and then press enter, this way the variable is created, and do the same for all variables.

This is also how it would work with any style that some one may develop, the variable names would remain the same but the drawing code may be diffrent and the name of the library may be diffrent.

Also feel free to mess around with the drawing code, in the future I will make sure to include this file, and a file that works with <=3.2 calcs.
Also in the future I will add all some of the event code, because if you made a rounded window, you cant check the click the same as you would with a standard window

[DJ Omnimaga]

So today I came home after work and decided to take a look at what WZGUILIB might look like in C, for use on the prizm, and I definately think that porting it wont be that difficult. But I ran into a problem....
My Prizm emulator trial ran out and I dont want to ruin my prizm.
So as an effect of that, I will be writting out the first C version in Nspire C , and once school starts I will download the prizm emulator on one of the schools computers and directly port WZ to the prizm. The WZ headers them selves will have barely any platform specific code in them, so I can easily port it.
The only problem right now is.... nRGBLib draws out its chars way to large, in the image, the title is bieng drawn out at a size of 1.
 I only drew out the body, frame and title of the form, as you can see. It will have the two circle buttons in the end.

If you got Virtual PC you can actually run Windows XP mode on Windows 7 and you have unlimited PRIZM emulation there, since once your trial expires, you just need to start a new image and get rid of the previous one

[jwalker]

true, but I am using home premium...

[DJ Omnimaga]

Ah that sucks. I actually had Home too but upgraded.

[jwalker]

I thought about, but decided not to in the end (dont want to spend the money )

[alberthrocks]

I thought about, but decided not to in the end (dont want to spend the money )

I would suggest VirtualBox, which is pretty nice. Once you install XP, just download the emulator and then shut down the VM. Copy the virtual HDD to a safe place, and then keep using (install and use). Once you're out, backup any progress from the current VM, delete said VM, and then use the old one to repeat.

If you don't have an XP CD/image... be creative.