Hi all,

I'm trying to set a expander's (which has custom controltemplate) header to string but SetHeader method only accepts basecomponent as argument. How am I going to do that?

Thanks

The API is not correct, we will fix it in the next release.

Meanwhile, there is a tricky way to do it, by using other property that allows to set a string like the FrameworkElement.Tag property:
Sorry for the inconvenience

Your tricky way is worked but I'm using tag property for another purpose so I tried creating new class which inherits from BaseComponent and override ToString method, it don't work. What am I missing?

You can still use Tag for whatever you want. My workaround only needs the Tag property to construct a BaseComponent object with a boxed string inside.

You can save the current Tag and restore it later:
Or you can use a helper object just to construct this boxed strings:

But remember that this is only a workaround until we fix the SetHeader to set a string.

Are you sure it's a good idea to change SetHeader to take a string? I may be wrong but I think the Header of the HeaderedContentControl in WPF is of type object so it's possible to pass even more complex objects in there.

And I guess certain things would become more difficult because it would probably prevent specifying a more complex header within XAML. But again, it may also be wrong here.

The same problem with base component also applies to various other cases. So the main problem is that you often need the base component instead of just an object which makes certain things just a bit more cumbersome than they would need to be.

Oh, also the lack of support of generics is occasionally really frustrating.

But remember that this is only a workaround until we fix the SetHeader to set a string.

Also please, remember to file a bug to track this.

Are you sure it's a good idea to change SetHeader to take a string? I may be wrong but I think the Header of the HeaderedContentControl in WPF is of type object so it's possible to pass even more complex objects in there.

And I guess certain things would become more difficult because it would probably prevent specifying a more complex header within XAML. But again, it may also be wrong here.

The same problem with base component also applies to various other cases. So the main problem is that you often need the base component instead of just an object which makes certain things just a bit more cumbersome than they would need to be.

It is a workaround for the v1.1, overloading the function with both BaseComponent and String.

But all this, won't be needed in v1.2 because we have fixed the architecture to support native objects everywhere. This way our API will be more similar to WPF.

Oh, also the lack of support of generics is occasionally really frustrating.

Collections are also being fixed in v1.2. Is this what you mean or a different thing?

Are you sure it's a good idea to change SetHeader to take a string? I may be wrong but I think the Header of the HeaderedContentControl in WPF is of type object so it's possible to pass even more complex objects in there.

And I guess certain things would become more difficult because it would probably prevent specifying a more complex header within XAML. But again, it may also be wrong here.

I didn't explain it correctly. Our intention is to provide two versions of the SetHeader function (for 1.1.12 version), as it occurs with other BaseComponent properties (like Tag). You will be able to call SetHeader("Some header") or SetHeader(headerElement) being headerElement any BaseComponent derived object.

The same problem with base component also applies to various other cases. So the main problem is that you often need the base component instead of just an object which makes certain things just a bit more cumbersome than they would need to be.

Oh, also the lack of support of generics is occasionally really frustrating.

Upcoming 1.2 version will deal with these problems better. We are working to provide an API equivalent to WPF, exposing properties instead of functions, 'object' instead of 'BaseComponent' type, etc.

I'm glad you're just overloading the method.

And it sounds very promising that we'll be able to use any object instead of just from BaseComponent derived classes.

Oh, also the lack of support of generics is occasionally really frustrating.

Collections are also being fixed in v1.2. Is this what you mean or a different thing?

Collections are just one issue. The other one is that right now it's not possible to create a generic class, add the "Extended"-attribute and just use it in Noesis.

Collections are just one issue. The other one is that right now it's not possible to create a generic class, add the "Extended"-attribute and just use it in Noesis.

The "Extended" attribute is going to be deprecated in v1.2 also. So, I think that Generic classes should work fine also.