Update

Hi Everyone, Last friday was a great day for Screens since I was able to solve the internals of the object component which is based on a 'snack-machine' design where you can see all the different objects (objects with different name UID's) in a list and each object has a sub list holding all the objects with the same name holding the source and target of each of the 'duplicate' members. This design is fast because it allows classes and extensions to be modified and the update is done dynamicaly. There is no need for run-time checking for the correct override behaviour which makes the system very fast. A few users have already liked the new design. The object browsing of members API has been defined and has a macro which makes browsing very simple. Take a look: ScrObjectList(HContainer, HMember) { if(ScrObjectName(HMember) == UID_WINDOW) //Add code here } This code very elegently will loop through every member of a specific object (HContainer is a handle) and set the current member to the HMember handle. So any code in the brackets will be acted on any member in the collection. This makes it very easy to search, manipulate multiple objects very easily. The ScrObjectList is actually a macro which deals with the loop for you. Compare that to any other meta-data system out there. It's ideas like these that can make an OS very easy to code for however require a great deal of time to think of. What is left for the object component now that the object manipulation and object member browsing function names are designed? The browsing/creating/removing of classes and extensions (extension API can come later though). The class behaviour is the most important. The general prefix is something like this: Here are a few examples: ScrObjectNew ScrObjectFree ScrWindowMove CodeDataWrite Scr prefix is used for all the public API wrapper version while the Code prefix is used for the non-wrapper version. is used for internal (not to be shared outside it's source file) functions. This design makes it very easy to keep track of the multitude of functions. A huge amount of time is spent on not only the user interface and internals asspect but also the programmers view since a programmer is also a user so why should it be hard for a programmer to code. If coding was easier we would see more qaulity applications which is what I plan to show with Screens Environment. Know that the data component is totally ready for coding just waiting for the object API to be finished and I code away the first component which encapsulates a PalmOS database for read/write of records. It's functions took also some time to design however there is no public API (wrapper version) for the data component. This is because I dont need programmers touching the internals of the data component. The only component which does this is the object component anyway. Work is going well... and even though I dont have a working version I am very happy with the design. This is not your average OS... find any other OS that is using it's INTERNALS object oriented with run-time class support. This is not Spotlight or WinFS... The whole Screens Environment is composed of objects in the object storage from the message loop (yes, you can extend the message loop like to support real multi-tasking the future) to the window management (want to add a drop down to the close button on a tap & hold just add a tap & hold method to the close button control in the title control class which belongs to the window class). The possabilities are endless and very flexible which makes life easier for me and any programmer (and users) who make applications for Screens Environment. If anyone has questions... post them here or send me an email at zhamilton1@yahoo.co.uk