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/

Reply via email to