Is this possible with the Option class?

[fbraem]

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.

[alex]

> 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

[guenter]

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.

[fbraem]

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.

[guenter]

> 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]");

[fbraem]

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.