Update: StoreChannel has been coded

You can find the updated source as always here: http://www.geocities.com/zhamilton1/screens.zip I dont believe it! Things are going great! OK... StoreChannel has been coded which means that the kernel can not only launch modules but if a module talks to the kernel, I have now coded the component which will allow the kernel to read the parameters sent by the modules. What's left before I release the 0.1 version of the kernel? 1. Finish the transalation layer in the kernel that recieves the parameters and passes them to the kernel functions. No brainer here, just alot of typing. 2. Start working on a demo application to demonstrate the object storage and write the Core wrappers while working on it. While the demo application might be a bit complex (hopefully I'll think of some cool demo) the wrappers are just alot of typing. 3. Test that it works - the hard part :D Screens Environemnt is on a level it was never before and I realy feel that the kernel first release is going to be very soon. I know it has taken 4 years and the kernel only holds the object storage but because of the amount of design I have spent on other components like the UI, you will see the pace not slow down but actually go faster as time goes by. You have no idea how complex it is to design an object storage and if you dont believe me, just follow my posts :D

Store Channel Design

http://www.geocities.com/zhamilton1/storechannel.doc You can find here a short document about my design and implementation for StoreChannel component which deals with communication between the kernel and modules. Enjoy, Zakai Hamilton

Update: StoreMethod has been coded

I have updated the source: http://www.geocities.com/zhamilton1/screens.zip So, what now? The communcation between the module and the kernel. It looks like I will use system memory for sending parameters and feature memory for recieving parameters. The idea for this is that the kernel can manage the feature memory IDs instead of the modules. This should take a while because of its design not implementation. I will try my best to get this done as quicky and efficiently as possible. There are not any big issues here just small details like function and component names which I seem to struggle every time. After this comes the Core component wapper and then the kernel is considered done for a first version. After that the Core wrapper is done I will create a small application to demonstrate the kernel. Any ideas?

Update: Wow... Things are moving...

Yay :D StoreModule and StoreMessage are coded which allows me to send a message to another module. You can get the new source code from here: http://www.geocities.com/zhamilton1/screens.zip So what's left for the object storage to be usable? 1. StoreMethod - To allow methods to be attached to objects and send messages to them 2. This was talking about Kernel->Module communication, we still have the module to kernel communcation which will be done over PalmOS system chunks. 3. The wrappers - These wrappers deal with sending and recieving the parameters so you dont have to think about them so when you call StoreObjectNew, it sends parameters to the kernel and receives the object handle. Once these are finished, I can work on the UI Module. I will also publish documentation on using the object storage kernel. Note that the kernel does not include multi-threading or multi-tasking since you all want this version quicker, I am making the object storage single tasking. I know this project is taking forever and I want to reward you all for you sticking with me with at least something. The UI will be like I always wanted it to be which is dynamic. What does this mean? This means that I can have a button which is derived from a button class and I can either create a custom button or extend the button class. I can send a 'Draw' method to all windows and controls and each window/control will handle the draw command depending on its type. This takes away alot of the complexity. So you can say... all this way just for that? Its not like that... This is only using a bit of the ability that the object storage gives me.

Update: Thanks for the chat

Hi, I would like to thank the users who have been chatting with me on MSN Messenger (zhamilton1@yahoo.co.uk is my user name if you want to join) in the last few days. Your input has been very helpful to move Screens forward. I should have StoreModule coded by the end of the week which are objects that represent PalmOS Code databases (prc's). The advantage of a module is that you just need to know its ID to use it for executing methods on it. If all goes well, I will work on StoreMessage which allows sending messages to modules and StoreMethod which allows calling methods which sends messages to modules. If I finish these three components then I am very close to having the object storage ready.

Update: Screens Source Code II

OK, First of all this version now compiles because I have removed the UISurface component from this build untill I finish it. I have implemented the StoreProperty and StoreType components correctly and did some cleanup with the StoreObject component. I know the siutation is pretty grim so I am going to cut one of the planned features of the object storage - dynamic objects. This basicly allowed to execute code from remote locations as if the code was local. It doesn't help if I add this functionality if Screens will never be released. Its a very complex feature and has alot of overhead and I have decided that it does not reduce the goodness that Screens will provide. http://www.geocities.com/zhamilton1/screens.zip Enjoy, Zakai Hamilton