Luc Le Blanc wrote:
Neil Whitworth a écrit :
Luc Le Blanc wrote:
I need to store a table of geodesic datum conversion factors (about 300
doubles.) If I put it in my code as a const struct, does it eat up my heap? Or
should I instead put the data into an auxiliary PDB I can read only when I need
to access the specific data I need?
Luc Le Blanc
You could alsow save the data as a resource in you app prc. I believe
there is also a 'integer array' resource type.
At least Constructor doesn't know about this resource type.
If PalmOS resources emulate the MacOS' you should be able to create
your own resource types and even provide a template for editing
(by ResEdit.) But my MacOS days are long gone and I don't if this
brilliant idea still works.
My arrays are a little more complex than just integers:
typedef struct
{
double radius;
double flattening;
} Ellipsoid;
typedef struct
{
Char name[ DatumNameLength ];
UInt16 ellipsoid;
float dX, dY, dZ;
} Datum;
You can create custome resource types (They are just blobs in the
resource database).
With PilRC just define the resource as below
HEX "type" ID ResID
0x00 0x00 0x10 0x21 0x20 0x42 0x30 0x63 0x40 0x84 0x50 0xa5 ...
I know it is also posible with constructor/68k linker, but it has been a
while since I did it.
if I remember corectly you do not use constructor, but create some text
files to hold your resurces. Constructor compiles its source resource
file to an intermidiate text file (.ro?). The 68k linker then parses
this and adds the correct resources to the final prc file. You can
create some additional .ro files and add them to your project. This was
how er added the fnav resource when the treo 600 was released, as
constructor does not support it.
Just lock the resource
when the app starts, and unlock when it quits. Then you only need a
single global pointer and can keep bith code & data segemnst smaller.
Aren't resources linked with one of the code segments? That's my
impression from the CW 9.3 Segment tab.
No. The resource files are listed in the segments view, which also
determines compile order. They are compiled into .ro files just as the
c/cpp code is compiled into object files. The linker then puts it all
togeather as a prc file, putting code, data and other resources into the
right resources.
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
