| RE: [cdt-dev] Default value for stringList |
|
Yes, defaultValue vs. value is somewhat
confused… > While my recent talk with Leo we
talked about the difference between the “value” and the
“defaultValue” attributes and he mentioned that the intention of
the default value attribute is to specify the option default. In case the
option value equals to its default, it is not added to the command line. That has been my intention, although as
Mikhail said: “No check is made for whether the option value equals to
its default or not while command line generation, etc.” At this
point, I’m not sure that we could use defaultValue in command line
generation without breaking existing tool definitions. Part of the confusion comes from the fact
that the old MBS model had a “defaultValue” but no “value”.
Trying to keep the old defaultValue semantics while introducing new semantics has
resulted in the current state. “defaultValue” and “value”
are used in the following way in the getValue method: /* * In order to determine the
current value of an option, perform the following steps until a value is found: * 1. Examine
the value attribute of the option. * 2. Examine
the value attribute of the option’s superClass recursively. * 3. Examine
the dynamicDefaultValue attribute of the option and invoke it if specified.
(not yet implemented) * 4. Examine
the defaultValue attribute of the option. * 5. Examine
the dynamicDefaultValue attribute of the option’s superClass and invoke
it if specified. (not yet implemented) * 6. Examine
the defaultValue attribute of the option’s superClass. * 7. Go
to step 5 recursively until no more super classes. * 8. Use
the default value for the option type. */ Back to the original question, i.e., programmatically
setting a value. There are two types of MBS model elements in memory when
an MBS project is loaded. There are the elements that were read from a
tool-chain definition added by a tool-chain integrator to the MBS extension
point. These are often referred to as “extension” elements in
the MBS code. MBS does not allow you to change the “value” of
an extension element, since these elements are never “saved”. The
second type of element is the project-specific elements read from the .cdtbuild
file. These are often referred to as “non- extension”
elements in the MBS code. You can change the value of a non-extension
element. As explained by Chris and Mikhail, you can
use the listOptionValue to specify “pre-set” and/or “built-in”
values for a string list. Regards, Leo From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail Hi Chris, We actually need to clarify the meaning of
the default value attribute. While my recent talk with Leo we talked
about the difference between the “value” and the
“defaultValue” attributes and he mentioned that the intention of
the default value attribute is to specify the option default. In case the
option value equals to its default, it is not added to the command line. According to this approach, specifying a
listOptionValue without builtIn=true will force the value to be included in the
command line, that might not be a user intension. This is why specifying values
as built-in might be more correct. On the other hand, the default option
value facility is not currently used by the MBS. No check is made for whether
the option value equals to its default or not while command line generation,
etc. We must make some
clarifications/modifications regarding this to make MBS grammar and API more
consistent. Regards, Mikhail From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On
Behalf Of Recoskie, Chris What you said is not quite true. While
the “default” attribute is not used, if you specify a
listOptionValue for one of these types in the extension markup, it will be used
to populate the default value of the option. In your example below, if
you didn’t specify builtIn=true, then the values would appear in the GUI
and be editable by the user. ___________________________________________ Chris Recoskie Software Designer http://eclipse.org/cdt From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky, Mikhail Hi Aparna, There is no way to mention default values
for the list-type options using MBS syntax, but there is a possibility to
specify built-in values, e.g.
<option
name="Include Paths"
command="-I"
browseType="directory"
valueType="includePath"
id="sub.tool.opt.inc.paths">
<listOptionValue
value="/usr/gnu/include"
builtIn="true">
</listOptionValue>
</option> Do you need to specify default list-type
values or built-ins? Note: I suppose you should be able to
specify default values for the list-type options programmatically, e.g. using
value handler mechanism. What type of exception do you get when trying to set
the default value from your value handler call-back? Regards, Mikhail From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Aparna Argade Hi, As per MBS model, stringList/ definedSymbols or similar
special types do not use default value. I tried to set value through
valueHandler class also, but there also exception occurs. Is there any way to mention default value for a stringList
or definedSymbols? Regards, Aparna |