>> > I *think* the way to do this is:
>> >
>> > string const paramStr = InsetIncludeMailer::params2string(params_);
>> > params_.read(paramStr);
>> >
>> > Abdel...is this right, more or less?
>
> Sorry that I am slow due to lack of sleep. How can I *set* option in
> this way? You basically convert
> I *think* the way to do this is:
>
> string const paramStr = InsetIncludeMailer::params2string(params_);
> params_.read(paramStr);
>
> Abdel...is this right, more or less?
Sorry that I am slow due to lack of sleep. How can I *set* option in
this way? You basically convert params_ back and fort
[EMAIL PROTECTED] wrote:
If you look at InsetCommandParams, you'll see that params_ is set in
read(), and the other InsetCommand derived insets call read() when they
need to set params_. (When they need to read the params, they just get
params_ directly via params() and index into it.) That's wha
>> If you look at InsetCommandParams, you'll see that params_ is set in
>> read(), and the other InsetCommand derived insets call read() when they
>> need to set params_. (When they need to read the params, they just get
>> params_ directly via params() and index into it.) That's what I meant
>> wh
If you look at InsetCommandParams, you'll see that params_ is set in
read(), and the other InsetCommand derived insets call read() when they
need to set params_. (When they need to read the params, they just get
params_ directly via params() and index into it.) That's what I meant when
I said that
>> The question, basically, is why you're making use of getOptions. My
>> understanding was that getOptions and setOptions (and some other things)
>> were scheduled for removal because they're some kind of relic of an
>> older
>> way in which insets interacted with parameters. (There are other
>> r
