Issues with new ways how controls can be defined

[Ikael]

When developing IZ extension for SW I noticed that it really matters what style you use to define your controls. For instance in SW there is template called textlistitemnumber which defines frames as following:

<frame>
    <name>textline</name>
</frame>

when using this template I must use the same way to define frame and I cannot use CoreRPG way:

<frame name="textlinesmall" />

because it is not taken account for reason or another. I can only override it by including frame element as

<frame>
    <name>textlinesmall</name>
</frame>

I know both presentations are different in terms of XML but if FG engine is interpreting them as the same thing generally (you can use any style you like) then I see consistency issue here becuase now developer must know how template was defined and use the same style. This is minor issue, but to prevent unecessary why-this-does-not-work I would like to see that FG engine could understand this issues and could interpret outcome which does not depend on style you used.

[Moon Wizard]

Attributes and sub-tags are only interpreted the same within the context of specific windowcontrol parameters. There are other cases where they are not interchangeable (i.e. name/source attribute, etc.)

However, the XML merging engine is a general merging engine that handles window classes and window controls. So, it would require a fair bit of logic to make it "FG class/control context aware".

When I'm developing add-ons for the rulesets, I always have to review the original classes.

Regards,
JPG