hi Chris,
thanks very much for your help, it've been very helpful.
but i have another Q:
how do i know what number to put in the char [X]? does it always has to
be the actualy long (size) of the input-data plus one (for Null)?
according to this, why did u define the SrvCall to be [10] if it is just
8 digit long? what is padding? do i always need to add 1 for null and 1
for paddind?
another thing is a C Q:
if i define a string with the long 0f 8, ( char[8]) doesn't it mean that
i have 9 cells ( from 0 to 8)? and doesn't it mean that i don't need to
add 1 tfor Null because it actualy has one more cell?
i hope u will answer me quickly because i really need to finish with my
project.
thank u again very much for your time and knowlage,
byeeee :-)
Chris Tutty wrote:
>
> "Eliah Ninyo" <[EMAIL PROTECTED]> wrote
> >
> > i made a struct with diffrent kinds of fields. here it is:
> >
> > typedef struct
> > {
> > SDWord FormID; // a number id
> > const char *SrvCall; // 8 digit number
> > const char *date; // the date when the form
> > opened/created
>
> Your first problem is that the char * fields (I'd agree with Richard that
> they should be declared const) only point to the location of, for instance,
> the 8 digit number which defines the SrvCall. Where do you plan on that
> location being?
>
> A more usual simple approach is
>
> typedef struct
> {
> SDWord FormID; // a number id
> char SrvCall[10]; // 8 digit number (with NULL terminator and
> padding)
> char OpenDate[16]; // the date when the form opened/created
>
> This actually allocates a certain number of bytes within the record to
> stoare each value. You can then declare const char * variables to refer to
> these if necessary. This is a reasonably complex subject in it's own right
> and I'm just skimming the surface.
>
> I've just guessed about the char [16] for date - the actual space needed
> depends on what you're storing. I've also changed the name of the field
> because, in general, 'date' is as bad a name for a field as 'number'. Most
> naming guidelines suggest that you don't use the type of a field to name
> it - 'date' is the type of the data, a useful name identifies what date is
> being stored.
>
> Chris Tutty
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/