Ever feel real stupid because you missed something so obvious... well that was this AM when I got a note from the boys in Belgium

When I first started working with the pronto I decided to put all the common code at the activity level and all the device oriented code at the page level. That is okay at first glance. I then decided that the active page would be in a continuous loop (every 100 milisec) running a switch statement to perform actions in a very controlled manner. Much easier to debug when async events are queued and brought under control.

What I did not realize (until it was mentioned in a kind and forgiving manner) was that every function defined on a page would be reinitialized and defined every 100 milisec. What a time waster!!!

I proceeded to move every function defined on each page to the activity level, resolved any namespace issues and square the code away (not yet optimized).

I saw a two to threefold improvement in performance immediately.

Once I thought about it I realized it had to be that way based on the archtecture of the Pronto and it's GC algorithms. By having the activity level as the home of all the functions they only get defined when the activity level process executes which is when jumping from outside the activity to one of the activities pages.

The scroll wheel is now very usable. It is coded such that you have to leave it alone for one second before the action completes. While you are jogging it the elevator moves up and down in its shaft following the wheels motion and then when you stop it loads the window with the proper section of the data you were scrolling over.


No big loss, but the new Slimserver client is really exciting to use now!

Exciting? Don't know about that one. But I bet it runs a helluva lot faster. LOL

Barry, I thought you knew that one. My bad.

I hit this problem when I thought about doing page queues like you were doing.

It was really not that big of a deal for me as I typically only use classes (includes javascript functions) and define instances of the class in variables stored at the activity-level.

Lyndel

I am easily excited at my age. (:-). When doing a collage load (9 covers at 100x100 each) the just come in one after another with practically no delay. The scroll wheel is nice bcause as long as you keep it moving you can turn it CW or CCW and watch the slider elevator track the wheel. stop playing with it and the data (cover art) loads quickly and smoothly.

If you just move the cursor vertically in a long non resident list; when the cursor hits an edge (top or bottom) the system hiccups, reloads the next chunk from the server and continues.

When I get the time I will do prereads for cursor and page operations, but it makes no sense for scrolling as scrolling sort of mimics random access

When do we see this new version :-) Today?

Goes out tonight. Just need to pack it up with its documentation. All those you have purchased a copy should get it by tomorrow early AM so you can play with it over the weekend

Another great tip, Barry! Thanks! Would be nice if there were a ProntoScript FAQ!

If you run through the examples in the Dev Guide, you will find out many things about the behavior of the unit.