Ok much clearer. I get questions from users with all different levels of experience so sometimes it can be hard to figure out how technical/detailed to make my responses.
The "helper" functions aren't actually built into the core. Neither are things like the calendar, email, etc parts of the database. These are part of an external dll thats provided with alot of common functions to keep things standardized between the different plugins. The core itself is very very slim and fast (i don't know if you saw the benchmark thread but the whole program loads in ~200ms) The external dll not only provides a standard way for lets say plugin x to read emails from plugin y but also reduces the memory footprint of the app as a whole by allows functions and controls to be shared. The core itself only contains 5 classes.
Some other things to note (didn't really fit into the above):
* We use three different skinning systems but mainly we use compiled skins which load significantly quicker then xml skin files (as i'm sure your finding with your own FE). The skin designer has a quick and easy way to create most of the basics in a skin file and then automatically compiles it into a plugin dll.
* The program makes heavy use of threading to keep things fast. The first thing it does is draw the main UI and main menu, everything else happens in the background usually before you can even get your finger/mouse to a button.
* The loading only the functions needed is actually done by the .net jit compiler. Its constantly looking for the next set of functions that could be called, and compiling/optimizing them. Functions that aren't being called never even make it into memory.
* The calendars, contacts, weather that you saw in the wiki is only a struct definition of these things, not the actual plugins or any code that deals with them. Just makes it easy to save/retrieve things from the database and pass them around.
Sorry if that was a bit redundant - didn't get my cup of coffee yet
Yup thats all possible and pretty easy to do. Might make more sense to use a for loop though:
The big thing to grasp with OpenMobiles controls is the concepts of panels and rendering controls.
OMImage img=new OMImage()
sleep(10); //Your code would have happened instantly so you never would have seen the move
In order for a control to be visible it has to be added to a panel (like a windows form) and that panel has to be visible. Whenever a control is in a visible panel it is rendered whenever needed by the UI. Changing things like height or text causes it to be redrawn.