Question: naming of control classes

[wriedmann]

Hi Terry,

both, of course. But since I'm working more with WPF, I can add more ( and other) functionality to the WPF classes.

For example, name based binding for WinForms can be accomplished at the Window level, whereas for WPF it has to accomplished at the control level. And since I consider name based binding one of the important features of the VO GUI classes, they will be added to the Tools controls also.

And then will be the possibility to assign a value to a control (not only a text), and when you retrieve it later it will be the same type.

What I'm missing at the moment is a picture feature for both WinForms and WPF edit control.

Wolfgang

[Terry]

Have you considered different prefixes/suffixes for the two namespaces?

Xst Forms
Xctl WPF

It could be users want access to both in their programs.
Just a quick thought - sorry if it's nonsense. Haven't got anything active in XSharp.

Terry

[wriedmann]

Hi Terry,

no, I have not considered that.

I don't think both will be used on the same form, as it needs some special adjustments to use WinForms controls on WPF forms and viceversa.

But if here more people asks for a differentiation, it can be done.

Wolfgang

[wriedmann]

Hello,

since I don't think other comments will come in: these are the conclusions:

the classes will have a postfix (Robert's argument are valid - and when using a prefix that starts with "x" theses classes will be at the bottom of the lists), and the postfix will be "xt", so we will have for example a class

Code: Select all

class ButtonXt inherit Button

Wolfgang

P.S. "xt" could not be mean only "XSharp Tools", but also "extra" <g>

[Meinhard]

Hi Wolfgang,

I prefer a prefix and a lot of other vendors do the same, for example in the Infragistics Control Suite lots of the class begin with Xam like XamComboEditor.

Regards
Meinhard

[wriedmann]

Hi Meinhard,

thank you very much for your comment!

So until now Robert is the only one suggesting a postfix.... Maybe I have to rethink about this, and change to a Xst prefix.
It may have some advantages to respect/copy rules all other component vendors are applying.

Wolfgang

[Terry]

Hi Wolfgang

I have been reluctant to comment further on this topic for the simple reason that I do not have any up to date experience of using XSharp, Vulcan, of VO.

In view of Meinhard's comment I'd just like to make a couple of points.

The whole reason for namespaces is to group together classes so they can be spread around an assembly without fear of naming conflicts. Namespace-Classname is concatenated by the compiler.

By using the same control class names for different classes you are breaking this separation.

You may have a very valid reason for doing this, I don't know.

But as a general rule I would not choose to do this.

Using different class name prefixes in different namespaces would satisfy Robert's arguments and allow for Meinhard's preferences.

One further point: Although it may be easy for humans to distinguish between controls having the same name it introduces ambiguity which would add to complexity should some future software tooling be introduced which needed these classes.

Terry

[wriedmann]

Hi Terry,

By using the same control class names for different classes you are breaking this separation.

No, there must be a misunderstanding.

Code should be self-documenting, so a Button class must be recognizable by its name, and it is a nonsense to have a System.Windows.Forms.Button and a XSharp.Tools.Windows.Forms.Button, because no one will always write the full name, and should not be forced to so.
Therefore the toolkit class will be XSharp.Tools.Windows.Forms.xstButton, so the programmer can write

Code: Select all

local oButton as xstButton

Wolfgang

[FFF]

Wolfgang,
I see no convenient way to search by postfix, while the absolute position in an ordered list poses no problem, given an incremental search:)

[Terry]

Yes - comments are clearly at cross purposes.


Can't put my finger on why at the moment.


Terry