Re: XForms: Compile DESIGNER output files?

Steve Lamont (
Fri, 18 Jul 97 06:56:16 PDT

To subscribers of the xforms list from (Steve Lamont) :

> 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. :-)

To unsubscribe, send the message "unsubscribe" to or see
Xforms Home Page:
List Archive: