Overview
Features
Download
Documentation
Community
Add-Ons & Services

Is this possible with the Option class?

Please post support and help requests here.

Is this possible with the Option class?

Postby fbraem » 18 Aug 2008, 14:41

Hi,

I'm the developer of the wxJavaScript project. A project that ports wxWidgets to JavaScript. I'm looking for a replacement of all NON-gui classes of wxWidgets into classes of a common library like POCO. This will make my project more useable for people that don't want to install all the wxWidgets dll's.

One thing that must work is the way command line arguments are handled. In wxJavaScript all arguments are handled. When a name of a scriptfile is found, the handling must stop, because all arguments that follow are arguments for the script. Can the following be handled by POCO?

wxjs.exe /c /r 1024 script.js /h /v

"/c" and "/r 1024" must be handled by the wxjs.exe program. script.js is the scriptfile. "/h", "/v" must be passed to the script.

Franky.
Zumuta!, that's the way to do IT!
fbraem
 
Posts: 104
Joined: 11 Aug 2008, 22:47
Location: Belgium

Re: Is this possible with the Option class?

Postby alex » 18 Aug 2008, 16:03

> I'm the developer of the wxJavaScript project. A project that ports wxWidgets to JavaScript. I'm looking for a replacement of all NON-gui classes of wxWidgets into classes of a common library like POCO. This will make my project more useable for people that don't want to install all the wxWidgets dll's.

We certainly encourage you to use POCO. I have not looked into wx for some time, but last time I checked, POCO general-purpose facilities were definitely more complete and powerful. That being said, I hope you are aware that, if you link dynamically, your users will need POCO DLLs.

^
> One thing that must work is the way command line arguments are handled. In wxJavaScript all arguments are handled. When a name of a scriptfile is found, the handling must stop, because all arguments that follow are arguments for the script. Can the following be handled by POCO?
>
> wxjs.exe /c /r 1024 script.js /h /v
>
> "/c" and "/r 1024" must be handled by the wxjs.exe program. script.js is the scriptfile. "/h", "/v" must be passed to the script.
^

Given that 'script.js' can be anything it's impossible to handle the above case without customized parsing. If your application does not use Util::Application framework, then you can build your own OptionSet (and figure out which switch goes where) directly from the command line.

With Util::Application framework used, as it currently stands, this will work:

Code: Select all

wxjs.exe /c /r=1024 /s=script="script.js /h /v"


Provided you have defined all the options in your application (see SampleApp), the above will give you a convenient script access at runtime:

Code: Select all

std::string myScript = config().getString("script"); // myScript == "script.js /h /v"


HTH

Alex
alex
 
Posts: 1120
Joined: 11 Jul 2006, 16:27
Location: United_States

Re: Is this possible with the Option class?

Postby guenter » 18 Aug 2008, 16:54

Hi,

as Alex noted, the required behavior is not supported out of the box.
Possible alternatives are:
1) use Unix-style options (-option), and put a -- before the filename argument. This will cause the option parser to ignore everything following the --
2) patch Util/src/Application.cpp to get the required behavior.

A possible way to do this is:
1) add a virtual member function handleArgument(const std::string& arg) to Application
2) replace the body of Application::processOptions() with the following code:

Code: Select all

    OptionProcessor processor(_options);
    processor.setUnixStyle(_unixOptions);
    _args.erase(_args.begin());
    ArgVec::iterator it = _args.begin();
    while (it != _args.end() && !_stopOptionsProcessing)
    {
        std::string name;
        std::string value;
        if (processor.process(*it, name, value))
        {
            handleOption(name, value);
            it = _args.erase(it);
        }
        else
        {
            handleArgument(*it);
            ++it;
        }
    }
    if (!_stopOptionsProcessing)
        processor.checkRequired();


In your subclass of Application, override handleArgument() and, in handleArgument(), call stopOptionsProcessing().
This should give you the required behavior.

guenter
 
Posts: 1121
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: Is this possible with the Option class?

Postby fbraem » 19 Aug 2008, 13:01

Is there a way to get all unhandled arguments after calling stopOptionsProcessing?

Maybe this must be added in POCO because this is also the way the perl interpreter works.

I would use the static build, to reduce the number of dll's.
Zumuta!, that's the way to do IT!
fbraem
 
Posts: 104
Joined: 11 Aug 2008, 22:47
Location: Belgium

Re: Re: Is this possible with the Option class?

Postby guenter » 19 Aug 2008, 15:14

> Is there a way to get all unhandled arguments after calling stopOptionsProcessing?

A vector of string is passed to Application: :main, containing all unhandled arguments.
Alternatively, the entire command line is available as application properties:
use config().getInt("application.argc") and config().getString("application.argv[i]");

guenter
 
Posts: 1121
Joined: 11 Jul 2006, 16:27
Location: Austria

Re: Re: Is this possible with the Option class?

Postby fbraem » 01 Oct 2008, 18:01

Finnaly managed to get into POCO and this solution works very well. Any change that this will get into POCO? If not, I always have to change Application.h and Application.cpp when a new version of POCO is released.

Franky.
Zumuta!, that's the way to do IT!
fbraem
 
Posts: 104
Joined: 11 Aug 2008, 22:47
Location: Belgium


Return to Support

Who is online

Users browsing this forum: No registered users and 3 guests

cron