Peter Thorstenson

Everybody who has tried to make DAs (Desk Accessories) knows you can’t use global variables in the code. There are ways to go around that problem, of course, but all I have seen are either slow, like reading and writing to databases, or complicated to use, like using Feature Memory (I never figured out how to read from it!). The easiest way I found is to use Application-Defined Features to store pointers to variables in Dynamic Heap. It practically gives you real global variables to use in your DA! This is how it works:

1. Define your application creator
#define DACREATOR 'myDA'

2. Define a the name of your feature ID giving it a unique number. To make it real easy, give it a name reminding of the global which pointer it will contain. I put an “f” in front of it.
#define fBuffer 1

3. For ease of use, put in the following two functions already published on TamsPalm:
//------------------------------------
MemPtr malloc(UInt16 size) {
MemHandle h = MemHandleNew(size);
if (!h) {
return NULL;
}
return (MemPtr) MemHandleLock(h);
}

//------------------------------------
void free(MemPtr ptr) {
MemHandle h = MemPtrRecoverHandle(ptr);
if(!h) return;
MemHandleUnlock(h);
MemHandleFree(h);
ptr = NULL;
}

4. Put in two functions that will make it easy to set and get the App Defined Feature which will contain the pointers to the globals.
// ------------------------------------
UInt32 GetFtr(UInt16 ftrID){
UInt32 test=0;
Err e=FtrGet(DACREATOR, ftrID, &test);
if (e!=0){
FtrSet(DACREATOR, ftrID, 0);
test=0;
}
return test;
}

// ------------------------------------
void SetFtr(UInt16 ftrID, UInt32 val){
FtrSet(DACREATOR, ftrID, val);
}

5. Declare your global variable and place them in the Dynamic Heap. To use the Dynamic Heap is really cool. You can almost put as much as you like up there without affecting the stack which has a limited space already used by the app running when the DA is launched.
char *Buffer=malloc(32000);

6. Set the pointer as a feature value.
SetFtr(fBuffer, (UInt32)Buffer);

7. To access the global variable in your functions, you need to get the pointer to it. That is done like this:
char *Buffer=GetFtr(fBuffer);
StrCopy(Buffer,"Hello!");

or even use it directly as in this example:
StrCopy((char *)GetFtr(fBuffer),"Hello!");

8. When quitting the DA, you need to free the global variable. Don’t forget it! It’s more important for a DA than for normal app. Quitting a normal app releases the variables but quitting a DA does not.
free((char *)GetFtr(fBuffer));

That’s it. It’s easy, fast, powerful, and safe. It also works with structures, so you can easily have your DAappPrefs available in all functions. If you want to see how it works in a real DA, have a look at the thumbboardDA code.

Using FontBucket with OnBoardC

Thanks to Peter MoƱko, the author of TBmpEdit, it is very easy to compile FontBucket with OnBoardC. The files: FontBucket.c and FontBucket.h are totally free standing, and therefore do not need to call for example FnGlue.

This is all you have to do:

1. Add FontBucket.c to the project file list.
2. Include FontBucket.h in the files calling it.
3. Create three string resources containing:

string_resource RESOURCE_ID="9500"
text "System" /text

string_resource RESOURCE_ID="9504"
text "VGA Font Name" /text

string_resource RESOURCE_ID="9550"
text "Bold" /text

You can IMHO leave the resources out, but the Palm will then behave uncontrollably when the app runs without having FontBucket installs.

The files can be downloaded here:

That’s it! FontBucket is now part of your project. Now you need to use the FontBucket functions to make it work the way you want it to.

DocumentsToGo is a popular application suite used by many people, but some, like myself, doesn’t use it at all. So, one day when I got fed up by looking at the only icon I never tapped on, I decided to see if I could remove it from my Tungsten T5.

I opened the Delete window, selected Documents, tapped on Delete, and yes the icon was gone. Great, I thought, so I opened the Info window to see how much RAM I had freed up. To my astonishment, I found out that I had freed up almost nothing.

Then I saw the names of several DocumentsToGo apps. I knew what that meant: The people who made DocumentsToGo never thought anyone would want to delete their app. But that was a mistake. I was now, more than ever, decided to wipe out every little piece of the garbage they had spread in my T5′s RAM. I was going to delete the individual DTG applications one by one. But each one of them had a creator ID of its own, making it impossible to decide whether I should delete it or not. At this point I said some really ugly words. I now understood that the people who made DocumentsToGo didn’t want anyone to delete their app at all. They had done everything they could to stop me, except for one tiny detail: The version number.

Yes, the version number in the Info window displays v 7.005 on all DTG apps in my T5. Luckily, this way of writing the version number is quite unique, but just to be sure: check so that no other app uses the same version number before deleting the DTG apps!

So, there it is. Just identify all the DTG applications using the version number as ID tag, and then delete them one by one. I gained close to 5mb, but that was in my T5. Other models may have the DTG apps in flash memory or even ROM, and then they can’t be deleted. If I one day would miss that icon I never tap on, I just have to make a hard reset on my T5, and all the DTG applications are back in the RAM again.

Is that what is called garbage recycling?

© 2013 TamsPalm - the Palm OS / web OS Blog Suffusion theme by Sayontan Sinha