>> Anyway, I'm not aware of any problem with sets and VFI. >> You could explain that.
> The problem is that a set is practically a single value. Take for example > the > TFont.Style property. If you set the bold in an inherited form then in the > dfm > you will see Font.Style = [fsBold]. Now if in the base form you want that > the > font has the italic style then the inherited will not "see" the change > because > the Style property is assigned. > About the HttpCli, actually it has an Options property that contain two > flags > for the authentication. If we add other flags for the content handling > then > this is what could happen. The base form has the content disabled and the > authentication enabled. The inherited switch the content on. In a second > time > the developer want switch off the NTLM in the whole application. It doues > that > in the base form but it must do the same for each inherited form that has > changed the Options property. > While this could be accepted for related switches like TFont.Style I don't > think that it is acceptable when they are unrelated. I think this behaviour is the normal expected behaviour of the way inheritance work. > For this reason I don't use anymore set properties in my components. > > Now the final question is: > - do you want that the two new properties will be added to the Options > property > or > - do you want these properties added as a new set > or > - do you want to add these properties as sub-properties of a new property > of > object type? > > In either case propose the names. I want that the two new properties be added to the Options property. Names: httpoEnableContentCoding and httpoUseQuality -- [EMAIL PROTECTED] http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
