I think you guys are misunderstanding Lionel. He is not disliking/bashing kArmTI, but is trying to secure its future. If kArmTI stays closed source, OR the author doesn't communicate with upstream there is A VERY BIG chance it will get outdated and die eventually. Lionel is just warning you for this, and trying to help you by giving some good advice.

I think kArmTI is great, but Lionel made some points that realy need to be considered.

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]

 --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)

--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.

http://education.bwns.be/FormulaPro is the database creator.
http://education.bwns.be/FormulaPro/eepro.html is the database editor with the EEPro database loaded.

The structure of the editor might be a bit complex in the beginning, but once you get the hang of it it isn't so bad

Tried it, looks nice
However, maybe the graphics are a bit too small ?

Thanks all for your kind words

How do you control your cannon by the way? Using directional buttons or swiping the touchpad like a trackball?
Edit: You know you have a small area at the bottom to move around freely in all directions, don't you?

Currently only the arrow keys, but I plan to change that.
Yes, I just didn't move much in the animation. My area is 4 mushrooms high.

About two weeks ago I decided I wanted to make a Centipede clone for the contest. Centipede is a classic Atari game.
Sadly enough I only could spend a couple of hours on it, so it did not get done in time.

Here is what I have until now:


As you can see there are still many things lacking:
- You don't die when hit (or win)
- No spiders, no fleas and no scorpions
- graphics aren't so good yet
- Controls need improvement.

But I intend to finish it, so it's not too bad

Thanks, fix'd

(You might have to clear cache or shift-refresh)