> For the record, the error message was "parse error before int on line
> (whatever)
> The line in question was
> fl_set_object_callback(obj, name_callback, int name_arg);
>
> The compiler couldn't find name_callback because it was in another piece
> of code. Effectively it was an unresolved reference although the
> compiler gave me a parse error.
I don't think your diagnosis is correct. `name_callback' would be
defined as
extern void name_callback(FL_OBJECT *, long);
in the fdesign generated .h file, so the compiler would have had no
problem with it.
fl_set_object_callback(obj, name_callback, int name_arg);
is invalid C code. The argument `int name_arg' is incorrect -- it
includes a reserved word and a space, neither of which are allowable.
If your compiler accepted this at all, no matter how you specified the
command line arguments, I'd be surprised (and somewhat appalled).
I do agree that the error message is somewhat misleading but I'm not
sure how the compiler designer could be any more explicit without a
lot of hackery. That's the sort of error that yacc or bison coughs up
when it sees an illegal or unexpected token.
Now, it might have barfed on `name_arg' if it wasn't somehow defined,
perhaps in a user supplied header file.
It looks as if fdesign will allow you to output an invalid variable
name in the Argument field, which is a minor bug in fdesign, I guess
(TC, wanna look into this?). I can argue either way whether fdesign
should be more rigorous in its argument checking. I suppose it would
useful to protect the novice user in some way but I really hate
interfaces which "know more than you do" (even if they're right).
> In my view the designer should either emit all the code as one file or
> else the manual should offer some advice on the compilation step. ...
It should definitely *not* do the former. The main, callback, and
form creation files are logically quite separate.
Typically in a project (at least for me -- I won't speak for others),
I generate the callback and main files only once, just to serve as a
quick bootstrap and to save myself some typing. The form creation
file and its associated header file are often regenerated as I go
about the process of modifying and `perfecting' the user interface.
I suppose some discussion of the compilation and linking might be
useful for the novice user -- I did a quick scan of the manual just
now and didn't find much of anything [did I miss it? If it's there,
could someone point it out to me, please?].
You might want to fish around in the DEMOS directory and look at the
Makefile provided therein.
> ... I am
> more used to compiling each module separately and then linking at the
> end. Most Makefiles follow this philosophy.
Yes, that's true and generally what I do. I usually only reserve the
method I gave you for "quick and dirty" throwaway tests where I just
want to try something out and don't want to go to the bother of
writing a Makefile. My Makefiles are generally actually generated
from an Imakefile using imake, by the way, which does generate
separate compilations for each object module and then globs the whole
mess together in a link step.
You really don't want to see either my Makefiles or my Imakefiles --
the design has evolved (mutated?) over several years and, as a result,
is quite bizarre and convoluted, I'm afraid.
> John Culleton
> misplaced COBOL Programmer
Um... no comment. :-)
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
Xforms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/