Under qnx 6.01 I write this small program:
int
main(int argc, char argv[])
{
PtWidget_t window;
if (!(window = PtAppInit(NULL, &argc, argv, 0, NULL)))
return(EXIT_FAILURE);
PtRealizeWidget(window);
PtMainLoop();
return (EXIT_SUCCESS);
}
i link it:
qcc -o test test.cpp -lph -lm
the final application will not parse standard photon arguments like -s -S -x -y etc.
Is this the normal behavior?
wavexx@broadcast.anarchy.net wrote:
Under qnx 6.01 I write this small program:
int
main(int argc, char argv[])
{
PtWidget_t window;
if (!(window = PtAppInit(NULL, &argc, argv, 0, NULL)))
return(EXIT_FAILURE);
PtRealizeWidget(window);
PtMainLoop();
return (EXIT_SUCCESS);
}i link it:
qcc -o test test.cpp -lph -lm
the final application will not parse standard photon arguments like -s -S -x -y etc.
Is this the normal behavior?
Yes, this is normal behaviour. (I think) The parsing standard arguments
is done by the Appbuilder startup code loop – if you use Phab (Photon
Application Builder) to build you applications you will get the
standard argument parsing, but if you build straight from the libaries
you will have to do your own argument parsing. (i.e. use getopt() or
write your own parser)
QNX Training Services
dagibbs@qnx.com
wavexx@broadcast.anarchy.net wrote:
: Under qnx 6.01 I write this small program:
: the final application will not parse standard photon arguments like -s -S -x -y etc.
: Is this the normal behavior?
Those options are standard for PhAB applications, not ones you build from
scratch.
David Gibbs <dagibbs@qnx.com> wrote:
is done by the Appbuilder startup code loop – if you use Phab (Photon
Application Builder) to build you applications you will get the
standard argument parsing, but if you build straight from the libaries
you will have to do your own argument parsing. (i.e. use getopt() or
write your own parser)
I don’t think that’s the normal behavior. I think this function is intended to
do exactly that: parse command line and create a window based on the given
command line, and then remove the parsed commands (look exactly how the
prototype is give: int* argc, char **argv, It’s MUST do something with these
parameters). If it’s not the normal behavior, it should. Photon is lacking
a function like gtk_init (for those who knows) that enables some standard
flags and use them for estabilishing a link to the server.
(please reply here, or at wavexx@apexmail.com, I’m behind a firewall)
wavexx@apexmail.com wrote:
I don’t think that’s the normal behavior. I think this function is intended to
do exactly that: parse command line and create a window based on the given
command line, and then remove the parsed commands (look exactly how the
prototype is give: int* argc, char **argv, It’s MUST do something with these
parameters). If it’s not the normal behavior, it should. Photon is lacking
a function like gtk_init (for those who knows) that enables some standard
flags and use them for estabilishing a link to the server.
Originally, the intention was that the function would do what you think
it should do. But then it was decided that Photon applications should
be compatible with the POSIX command option syntax implemented by
getopt(), which meant that it would be impossible for PtAppInit() to
parse the arguments without knowing the “opstring” that your application
passes to getopt(). Consider the command line:
$ app -fx200
Depending on whether the -f option takes an argument or not, the above
may be equivalent to either
$ app -f x200
or
$ app -f -x200
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
wavexx@apexmail.com > wrote:
That’s why it was decided that PtAppInit() would just ignore its argc and
argv parameters, and another mechanism based on the PhAB-generated
ApOptions string was introduced.
Is it possible to use the ApOptions and the PhAb library to parse the
commandline without even using PhAb?
The code generated by PhAb works well for end-user programs, but I need more
control over the generated code (also PhAb generates external references for
widget names, without any scoping (not a so clean design in c++ applications))
Thanks however for the help
wavexx@broadcast.anarchy.net wrote:
Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:
wavexx@apexmail.com > wrote:
That’s why it was decided that PtAppInit() would just ignore its argc and
argv parameters, and another mechanism based on the PhAB-generated
ApOptions string was introduced.Is it possible to use the ApOptions and the PhAb library to parse the
commandline without even using PhAb?
Possible, yes – you just need to pretend convincingly enough that
you’re PhAB. 
Of course, it would require a significant amount of knowledge about what
the PhAB library expects PhAB-generated data structures to look like.
These details are undocumented, and even if I told you about them, we
would keep breaking your code every time we change anything in PhAB
library. Personally, I think you’re better off writing relevant code
yourself.
The code generated by PhAb works well for end-user programs, but I need more
control over the generated code (also PhAb generates external references for
widget names, without any scoping (not a so clean design in c++ applications))
–
Wojtek Lerch QNX Software Systems Ltd.