A89: Re: Re: Re: A Address book With Some Real Problems

[Prev][Next][Index][Thread]

A89: Re: Re: Re: A Address book With Some Real Problems


> Nothing strange. The strange fact is that anything is correct,
> because it is really hard to discover correct meaning of
> events just by using VTI debugger and nothing more :-)

>From that point of view, you did an AMAZING job =)

> Now there is a problem: as I just signed today a contract with
> TI about alpha testing (so I expect to get their documentation
> soon), I will not be able to correct this in the documentation
> regardless whether I discover the error by myself, or by reading
> their documentation ;-)

I'll be looking forward to catching you on the SDK mailing list within the
next few days, then.  When I get a chance, I'll send you a private message
with various comments =)

> What you expect that I am :-)

Well, you sure are very, very good at pulling off a lot of "tricks" in C
that someone who targets exclusively more sophisticated platforms - like
x86 - would never learn of.  I know that you're a professor somewhere, but
how did you first learn to do all this?

> Yes, prototypes are very very very important, but not so important
> in Rob's code, because functions are called AFTER their definition:

That's the excuse I usually hear - but I for one have found the compiler to
be helpful in correcting me when I accidentally put the wrong type in the
declaration (but, when writing the prototype, do it correctly, thus having
the compiler notify me of the error).  That, and who wants to have the least
important functions - which are referenced in the fewest other functions -
at the top?

> "char static a;" is legal as well as "static char a;" in all C
> compilers I ever seen. The order of variable attributes is not
> proposed in the standard. I used this trick once in tigcclib (don't
> ask me why: it is a long story).

Strange, because the standard may not specify the order, but the CFG listed
in the back of K&RC2 indicates that static/extern/const/volatile etc must
appear before the type, and yes, I HAVE used compilers when "static char"
fails (of course, that was a build of code warrior for macs in which I
discovered several bugs) and a C++ compiler (not C), if any of that is
relevant - I'm sure it didn't work on that compiler since this was a
computer science course where I was correcting novices' code which made
mistakes like those.  I wouldn't typically use static when programming a mac
anyways =)

> Yes, but I don't think that ALL COORDINATES need to be #define's !?

I certainly think coordinates should typically not just be magic numbers.
For instance, if each request box were 10 pixels high, and the top one is at
a 15 pixel offset (I don't feel like getting the exact numbers from Rob's
code), why not use something like the following:

#define VERTICAL_OFFSET 15
#define VERTICAL_INCREMENT 10

and the y coords would be:

1*VERTICAL_INCREMENT+VERTICAL_OFFSET
2*VERTICAL_INCREMENT+VERTICAL_OFFSET
3*VERTICAL_INCREMENT+VERTICAL_OFFSET
. . . etc. . .

See, no more magic numbers!  I actually find using something like this much
simpler to write, and it prevents simple precalculated math errors that many
of us have learned to avoid the hard way.

> No: it is correct. "result" is changed in the loop as the result of
> the execution of "PopupDo".

Wow, I missed that.  When using the find dialog box and searching for the
string "result" to make I didn't miss it.  hmmmm

> Callbacks are not so complicated to can not be explained to a
> beginner: dialogs.h documents it well (yes, Scott, I know that I

Didn't say it can't be explained, I just think that other things should be
taken care of first.  Like the improper usage of concatenation - you fixed
the code (actually, rearranged a lot of it) but I think that an explanation
is often necessary as an accompanyment.  If I were Rob, I think I would like
to _understand_ why the concatenation didn't work.

    -Scott