the reason that we have 2 distinct places which look thru
argv is historical. originally, the only thing we did
with the command line was get the (single, optional)
filename -- and we didn't need it until all the class
registration and the initial window and all its widgets
were created -- this could take some time.
if we let the parse code populate a ut_hash or ut_alphahash
of the arguments (and their optional values) of the keywords
and a ut_vector of the filenames to load, then everything
should be fine. these could be stored in XAP_App -- the
absolute base class for the application and then referenced
wherever....
and yes, let getopt do all the parsing dirty work in cross-
platform code....
thoughts ?? opinions ??
jeff
Ming-I Hsieh wrote:
>
> 337 for (k=nFirstArg; (k<pArgs->m_argc); k++)
> 338 {
> 339 if (*pArgs->m_argv[k] == '-')
> 340 {
> 341 if
> (UT_stricmp(pArgs->m_argv[k],"-nosplash") == 0)
> 342 {
> 343 bShowSplash = UT_FALSE;
> 344 break;
> 345 }
> 346 #if DEBUG
> 347 else if
> (UT_stricmp(pArgs->m_argv[k],"-splash") == 0)
> 348 {
> 349 // [-splash filename]
> 350 szFile = pArgs->m_argv[k+1];
> 351 break;
>
> Should we put it to ParseCommandLine?
> Maybe we can remove _showSplash(&Args, szAppName) from
> AP_UnixApp::main(...).
> And let ParseCommandLine call it before return!
>
> 453 pMyUnixApp->ParseCommandLine();
> 454
> 455 _showSplash(&Args, szAppName);
> --
> Ming-I Hsieh