"Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
news:0F043511-F300-4825-ABB9-185C86C7D43C@microsoft.com...
>I have 2 questions on using element collections when building a custom
> section handler.  I'm using the "declarative" model and I can post the
> code
> if necessary.  Basically I'm following the example described here:
>
> http://msdn2.microsoft.com/en-us/library/system.configuration.configurationcollectionattribute.aspx
>
> My code works and the XML in app.config for my custom section looks like
> this:
>
> <MySection name="x"
>    <Stores>
>        <add name="store1" addr="x" />
>        <add name="store2" addr="y" />
>    </Stores>
> </MySection>
>
> But I have 2 sort of "cosmetic" questions about changing the XML:
>
> 1.  If I change "<add..." to "<Store..." it gives a runtime error that it
> doesn't recognize the Store element.  But I don't see anywhere in my code
> where I tell the system to look for the "add" element, so why doesn't it
> complain about that?  I'd prefer the "<Store..." syntax but can't see how
> to
> override or redefine this behavior.
>
> 2. In some cases it might also be nicer to skip the outermost "<Stores>"
> element and just have this:
>
> <MySection name="x"
>     <Store name="store1" addr="x" />
>     <Store name="store2" addr="y" />
> </MySection>
>
> But I don't see how to arrange for this in the declarations of a
> ConfigurationElementCollection.  It seems to require the outermost element
> to
> key on its name.  What I want is sort of an "unnamed" collection of
> Stores.

"Kevin Spencer" wrote:

> Hi Tim,
>
> > 2. In some cases it might also be nicer to skip the outermost "<Stores>"
> > element and just have this:
> >
> > <MySection name="x"
> >     <Store name="store1" addr="x" />
> >     <Store name="store2" addr="y" />
> > </MySection>
> >
> > But I don't see how to arrange for this in the declarations of a
> > ConfigurationElementCollection.
>
> This one I *am* sure of. A ConfigurationSection can contain
> ConfigurationElementCollections, or individual ConfigurationElements. Each
> individual ConfigurationElement can (and should) have its own name. Each
> ConfigurationElement in a ConfigurationSection is a property of that
> ConfigurationSection. That is, the number is fixed by the class definition.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> Professional Numbskull
>
> Hard work is a medication for which
> there is no placebo.
>
> "Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
> news:0F043511-F300-4825-ABB9-185C86C7D43C@microsoft.com...
> >I have 2 questions on using element collections when building a custom
> > section handler.  I'm using the "declarative" model and I can post the
> > code
> > if necessary.  Basically I'm following the example described here:
> >
> > http://msdn2.microsoft.com/en-us/library/system.configuration.configurationcollectionattribute.aspx
> >
> > My code works and the XML in app.config for my custom section looks like
> > this:
> >
> > <MySection name="x"
> >    <Stores>
> >        <add name="store1" addr="x" />
> >        <add name="store2" addr="y" />
> >    </Stores>
> > </MySection>
> >
> > But I have 2 sort of "cosmetic" questions about changing the XML:
> >
> > 1.  If I change "<add..." to "<Store..." it gives a runtime error that it
> > doesn't recognize the Store element.  But I don't see anywhere in my code
> > where I tell the system to look for the "add" element, so why doesn't it
> > complain about that?  I'd prefer the "<Store..." syntax but can't see how
> > to
> > override or redefine this behavior.
> >
> > 2. In some cases it might also be nicer to skip the outermost "<Stores>"
> > element and just have this:
> >
> > <MySection name="x"
> >     <Store name="store1" addr="x" />
> >     <Store name="store2" addr="y" />
> > </MySection>
> >
> > But I don't see how to arrange for this in the declarations of a
> > ConfigurationElementCollection.  It seems to require the outermost element
> > to
> > key on its name.  What I want is sort of an "unnamed" collection of
> > Stores.
>
>
>

"Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
news:1D96DFB7-9FB2-4DC6-B9B1-7D9FE4F5564A@microsoft.com...
> So I think what you're saying is that if you want XML that's useable by a
> ConfigurationElementCollection, you *have* to have a "<Stores>" parent
> element while its child element's names can all be the same, ie "<add
> ...>"
> or preferably "<Store ...>" in my example.   And that even though XML with
> same-named elements might be well-formed, it's not useable in the
> Collection
> context.  Is that about right?
>
> Tim
>
> "Kevin Spencer" wrote:
>
>> Hi Tim,
>>
>> > 2. In some cases it might also be nicer to skip the outermost
>> > "<Stores>"
>> > element and just have this:
>> >
>> > <MySection name="x"
>> >     <Store name="store1" addr="x" />
>> >     <Store name="store2" addr="y" />
>> > </MySection>
>> >
>> > But I don't see how to arrange for this in the declarations of a
>> > ConfigurationElementCollection.
>>
>> This one I *am* sure of. A ConfigurationSection can contain
>> ConfigurationElementCollections, or individual ConfigurationElements.
>> Each
>> individual ConfigurationElement can (and should) have its own name. Each
>> ConfigurationElement in a ConfigurationSection is a property of that
>> ConfigurationSection. That is, the number is fixed by the class
>> definition.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> Professional Numbskull
>>
>> Hard work is a medication for which
>> there is no placebo.
>>
>> "Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
>> news:0F043511-F300-4825-ABB9-185C86C7D43C@microsoft.com...
>> >I have 2 questions on using element collections when building a custom
>> > section handler.  I'm using the "declarative" model and I can post the
>> > code
>> > if necessary.  Basically I'm following the example described here:
>> >
>> > http://msdn2.microsoft.com/en-us/library/system.configuration.configurationcollectionattribute.aspx
>> >
>> > My code works and the XML in app.config for my custom section looks
>> > like
>> > this:
>> >
>> > <MySection name="x"
>> >    <Stores>
>> >        <add name="store1" addr="x" />
>> >        <add name="store2" addr="y" />
>> >    </Stores>
>> > </MySection>
>> >
>> > But I have 2 sort of "cosmetic" questions about changing the XML:
>> >
>> > 1.  If I change "<add..." to "<Store..." it gives a runtime error that
>> > it
>> > doesn't recognize the Store element.  But I don't see anywhere in my
>> > code
>> > where I tell the system to look for the "add" element, so why doesn't
>> > it
>> > complain about that?  I'd prefer the "<Store..." syntax but can't see
>> > how
>> > to
>> > override or redefine this behavior.
>> >
>> > 2. In some cases it might also be nicer to skip the outermost
>> > "<Stores>"
>> > element and just have this:
>> >
>> > <MySection name="x"
>> >     <Store name="store1" addr="x" />
>> >     <Store name="store2" addr="y" />
>> > </MySection>
>> >
>> > But I don't see how to arrange for this in the declarations of a
>> > ConfigurationElementCollection.  It seems to require the outermost
>> > element
>> > to
>> > key on its name.  What I want is sort of an "unnamed" collection of
>> > Stores.
>>
>>
>>

"Kevin Spencer" wrote:

> "Stores" is a reference to the Collection itself. Each "add" member is a
> Collection element.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
> Professional Numbskull
>
> Hard work is a medication for which
> there is no placebo.
>
> "Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
> news:1D96DFB7-9FB2-4DC6-B9B1-7D9FE4F5564A@microsoft.com...
> > So I think what you're saying is that if you want XML that's useable by a
> > ConfigurationElementCollection, you *have* to have a "<Stores>" parent
> > element while its child element's names can all be the same, ie "<add
> > ...>"
> > or preferably "<Store ...>" in my example.   And that even though XML with
> > same-named elements might be well-formed, it's not useable in the
> > Collection
> > context.  Is that about right?
> >
> > Tim
> >
> > "Kevin Spencer" wrote:
> >
> >> Hi Tim,
> >>
> >> > 2. In some cases it might also be nicer to skip the outermost
> >> > "<Stores>"
> >> > element and just have this:
> >> >
> >> > <MySection name="x"
> >> >     <Store name="store1" addr="x" />
> >> >     <Store name="store2" addr="y" />
> >> > </MySection>
> >> >
> >> > But I don't see how to arrange for this in the declarations of a
> >> > ConfigurationElementCollection.
> >>
> >> This one I *am* sure of. A ConfigurationSection can contain
> >> ConfigurationElementCollections, or individual ConfigurationElements.
> >> Each
> >> individual ConfigurationElement can (and should) have its own name. Each
> >> ConfigurationElement in a ConfigurationSection is a property of that
> >> ConfigurationSection. That is, the number is fixed by the class
> >> definition.
> >>
> >> --
> >> HTH,
> >>
> >> Kevin Spencer
> >> Microsoft MVP
> >> Professional Numbskull
> >>
> >> Hard work is a medication for which
> >> there is no placebo.
> >>
> >> "Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
> >> news:0F043511-F300-4825-ABB9-185C86C7D43C@microsoft.com...
> >> >I have 2 questions on using element collections when building a custom
> >> > section handler.  I'm using the "declarative" model and I can post the
> >> > code
> >> > if necessary.  Basically I'm following the example described here:
> >> >
> >> > http://msdn2.microsoft.com/en-us/library/system.configuration.configurationcollectionattribute.aspx
> >> >
> >> > My code works and the XML in app.config for my custom section looks
> >> > like
> >> > this:
> >> >
> >> > <MySection name="x"
> >> >    <Stores>
> >> >        <add name="store1" addr="x" />
> >> >        <add name="store2" addr="y" />
> >> >    </Stores>
> >> > </MySection>
> >> >
> >> > But I have 2 sort of "cosmetic" questions about changing the XML:
> >> >
> >> > 1.  If I change "<add..." to "<Store..." it gives a runtime error that
> >> > it
> >> > doesn't recognize the Store element.  But I don't see anywhere in my
> >> > code
> >> > where I tell the system to look for the "add" element, so why doesn't
> >> > it
> >> > complain about that?  I'd prefer the "<Store..." syntax but can't see
> >> > how
> >> > to
> >> > override or redefine this behavior.
> >> >
> >> > 2. In some cases it might also be nicer to skip the outermost
> >> > "<Stores>"
> >> > element and just have this:
> >> >
> >> > <MySection name="x"
> >> >     <Store name="store1" addr="x" />
> >> >     <Store name="store2" addr="y" />
> >> > </MySection>
> >> >
> >> > But I don't see how to arrange for this in the declarations of a
> >> > ConfigurationElementCollection.  It seems to require the outermost
> >> > element
> >> > to
> >> > key on its name.  What I want is sort of an "unnamed" collection of
> >> > Stores.
> >>
> >>
> >>
>
>
>

"Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
news:21083771-0067-4D7B-B02E-4CF8363228E6@microsoft.com...
>I understand, but where is it determined that the name of each member
>element
> must be "add"?  Why can't I make it anything I want, like "Store"?  Even
> in
> the configSections collection itself, its members are not called "add" but
> "section".  I'd just like to follow that model to make my member elements
> more meaningful.
>
> Tim
>
> "Kevin Spencer" wrote:
>
>> "Stores" is a reference to the Collection itself. Each "add" member is a
>> Collection element.
>>
>> --
>> HTH,
>>
>> Kevin Spencer
>> Microsoft MVP
>> Professional Numbskull
>>
>> Hard work is a medication for which
>> there is no placebo.
>>
>> "Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
>> news:1D96DFB7-9FB2-4DC6-B9B1-7D9FE4F5564A@microsoft.com...
>> > So I think what you're saying is that if you want XML that's useable by
>> > a
>> > ConfigurationElementCollection, you *have* to have a "<Stores>" parent
>> > element while its child element's names can all be the same, ie "<add
>> > ...>"
>> > or preferably "<Store ...>" in my example.   And that even though XML
>> > with
>> > same-named elements might be well-formed, it's not useable in the
>> > Collection
>> > context.  Is that about right?
>> >
>> > Tim
>> >
>> > "Kevin Spencer" wrote:
>> >
>> >> Hi Tim,
>> >>
>> >> > 2. In some cases it might also be nicer to skip the outermost
>> >> > "<Stores>"
>> >> > element and just have this:
>> >> >
>> >> > <MySection name="x"
>> >> >     <Store name="store1" addr="x" />
>> >> >     <Store name="store2" addr="y" />
>> >> > </MySection>
>> >> >
>> >> > But I don't see how to arrange for this in the declarations of a
>> >> > ConfigurationElementCollection.
>> >>
>> >> This one I *am* sure of. A ConfigurationSection can contain
>> >> ConfigurationElementCollections, or individual ConfigurationElements.
>> >> Each
>> >> individual ConfigurationElement can (and should) have its own name.
>> >> Each
>> >> ConfigurationElement in a ConfigurationSection is a property of that
>> >> ConfigurationSection. That is, the number is fixed by the class
>> >> definition.
>> >>
>> >> --
>> >> HTH,
>> >>
>> >> Kevin Spencer
>> >> Microsoft MVP
>> >> Professional Numbskull
>> >>
>> >> Hard work is a medication for which
>> >> there is no placebo.
>> >>
>> >> "Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
>> >> news:0F043511-F300-4825-ABB9-185C86C7D43C@microsoft.com...
>> >> >I have 2 questions on using element collections when building a
>> >> >custom
>> >> > section handler.  I'm using the "declarative" model and I can post
>> >> > the
>> >> > code
>> >> > if necessary.  Basically I'm following the example described here:
>> >> >
>> >> > http://msdn2.microsoft.com/en-us/library/system.configuration.configurationcollectionattribute.aspx
>> >> >
>> >> > My code works and the XML in app.config for my custom section looks
>> >> > like
>> >> > this:
>> >> >
>> >> > <MySection name="x"
>> >> >    <Stores>
>> >> >        <add name="store1" addr="x" />
>> >> >        <add name="store2" addr="y" />
>> >> >    </Stores>
>> >> > </MySection>
>> >> >
>> >> > But I have 2 sort of "cosmetic" questions about changing the XML:
>> >> >
>> >> > 1.  If I change "<add..." to "<Store..." it gives a runtime error
>> >> > that
>> >> > it
>> >> > doesn't recognize the Store element.  But I don't see anywhere in my
>> >> > code
>> >> > where I tell the system to look for the "add" element, so why
>> >> > doesn't
>> >> > it
>> >> > complain about that?  I'd prefer the "<Store..." syntax but can't
>> >> > see
>> >> > how
>> >> > to
>> >> > override or redefine this behavior.
>> >> >
>> >> > 2. In some cases it might also be nicer to skip the outermost
>> >> > "<Stores>"
>> >> > element and just have this:
>> >> >
>> >> > <MySection name="x"
>> >> >     <Store name="store1" addr="x" />
>> >> >     <Store name="store2" addr="y" />
>> >> > </MySection>
>> >> >
>> >> > But I don't see how to arrange for this in the declarations of a
>> >> > ConfigurationElementCollection.  It seems to require the outermost
>> >> > element
>> >> > to
>> >> > key on its name.  What I want is sort of an "unnamed" collection of
>> >> > Stores.
>> >>
>> >>
>> >>
>>
>>
>>

"Tim Johnson" <TimJohn***@discussions.microsoft.com> wrote in message
news:5753F87B-AFA2-4498-9FFF-E900FC8F4FD2@microsoft.com...
> Ok, I found out how to do this based on your last message.  In the
> declarative approach I'm using I just add the AddItemName "decoration" to
> the
> attribute like this:
>
> [ConfigurationProperty("DataStores", IsDefaultCollection=false, IsRequired
> =
> true)]
> [ConfigurationCollection(typeof(DataStoresCollection),
>           AddItemName="Store")]
> public DataStoresCollection DataStores
> {
>    get
>    {
>        return (DataStoresCollection)this["DataStores"];
>    }
> }
>
> There are also decorations to override ClearItemsName and RemoveItemName
> (from the normal "clear" and "remove" labels), but I don't currently need
> them since I'm not support the set operation, only the get.
>
> So now my xml can look like this, which I like better:
>
> <MySection name="x"
>    <Stores>
>        <Store name="store1" addr="x" />
>        <Store name="store2" addr="y" />
>    </Stores>
> </MySection>
>
> Thanks for helping out on this one.
>
> Tim