Why cant I create a thumb dynamically? (Wpf - C#)

Question

1.00/5 (1 vote)

See more:

this is my code

public MainWindow()
{
    InitializeComponent();
    StringBuilder sb = new StringBuilder();
    sb.Append(@"<Thumb x:Name='thumb1' Canvas.Left='0' Canvas.Top='0' Canvas.ZIndex='99' DragDelta='Thumb_DragDelta' >
        < Thumb.Template >
            < ControlTemplate >
                < Image Source = 'images/table1.jpg' Name = 't1' Stretch = 'None' />
            </ ControlTemplate >
        </ Thumb.Template >
    </ Thumb > ");
    UIElement myThumb = (UIElement)XamlReader.Parse(sb + "");
    Canvas.Children.Add(myThumb);

I GET THIS ERRORMESSAGE :

Exception thrown: 'System.Windows.Markup.XamlParseException' in PresentationFramework.dll

Additional information: 'x' is an undeclared prefix. Line 1, position 8.

What I have tried:

I try to create some code in c# that will put some xaml controls on my application so i can put it in a foreach loop and check the database.

Posted 28-Apr-16 9:30am

Member 12491690

Updated 28-Apr-16 14:08pm

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Matt T Heffron · Accepted Answer · 2016-04-28T14:08:00

Solution 2

From the error I suspect the problem is that you haven't specified the the XML namespace corresponding to the x prefix. You could try something like:

C#

public MainWindow()
{
  InitializeComponent();
  const string thumbXaml = 
    "<Thumb x:Name='thumb1' 
            xmlns:x='http://schemas.microsoft.com/winfx/2006/xaml'
            xmlns='http://schemas.microsoft.com/winfx/2006/xaml/presentation'
            Canvas.Left='0'
            Canvas.Top='0'
            Canvas.ZIndex='99'
            DragDelta='Thumb_DragDelta' >
        <Thumb.Template>
            <ControlTemplate>
                <Image Source = 'images/table1.jpg' Name = 't1' Stretch = 'None' />
            </ControlTemplate>
        </Thumb.Template>
     </Thumb>";
    UIElement myThumb = (UIElement)XamlReader.Parse(thumbXaml);
    Canvas.Children.Add(myThumb); // the name of your Canvas element is "Canvas"??

You certainly need the xmlns:x= attribute, and probably also the xmlns= attribute. I suspect it will still fail because it has no way of knowing about the context so it can locate the Thumb_Drag_Delta event handler method that, I suspect, is in the MainWindow code behind.
(And the "Name" attribute in the Image element probably should be "x:Name".)

OK. First of all, since this is all static, why not just put it into the XAML file for the MainWindow?

But, maybe this is just "simplified for an example"...fair enough.

Create the controls in code, set the appropriate values and then hook 'em all up.

C#

public MainWindow()
{
  InitializeComponent();
  Thumb th = new Thumb();
  th.AddHandler(Thumb.DragDeltaEvent, this.Thumb_DragDelta);
  ControlTemplate thCt = new ControlTemplate();
  // fill in the ControlTemplate here....
  th.Template = thCt;
  myCanvas.Children.Add(th);  // I renamed this for disambiguation re: the Canvas class itself.
  th.SetValue(Canvas.LeftProperty, 0);  // MTH: Fixed the property names...
  th.SetValue(Canvas.TopProperty, 0);
  th.SetValue(Canvas.ZIndexProperty, 99);
  // etc...

(Caveat: I didn't try any of this...!)

Posted 28-Apr-16 14:08pm

Matt T Heffron

Updated 29-Apr-16 7:37am

v3

Comments

Sergey Alexandrovich Kryukov 29-Apr-16 9:04am

This is how it can be done:


UIElement someElement = new ... // concrete class
//...
Canvas.SetLeft(someElement, left);
Canvas.SetTop(someElement, top);
//...

This is because Left, Top, etc. are dependency properties of the UIElement, they depend on logical parent.

—SA

Matt T Heffron 29-Apr-16 13:19pm

Would the
Canvas.SetLeft(someElement, 0);
be equivalent to my
th.SetValue(Canvas.Left, 0);
(where my th corresponds to your someElement)?

(And shouldn't your MyCanvas. be Canvas. as it is referencing the static method?)

Sergey Alexandrovich Kryukov 29-Apr-16 13:28pm

I thin not. Canvas.Left simply means the location of Canvas itself, relative to its parent, and this is not what we need. We need to set Left of a child element relative to the Canvas. This term explains it all: "Dependency Property". What I show works as expected; I always do it here and there.

And sorry for my mistake; I really forgot these methods are static and wrote from my memory (broken at this point :-). I'll fix my comment above.

—SA

Matt T Heffron 29-Apr-16 13:38pm

I see I had a "think-o" ;-)
I should have used Canvas.LeftProperty, etc.
Would that be equivalent to your code above?

Sergey Alexandrovich Kryukov 29-Apr-16 13:56pm

Maybe, but why? The ideology is to use dependency properties and not the DependencyProperty objects. Can you see the point? Canvas.LeftProperty is not a property. This is one of the fields referencing Dependency Property infrastructure element; its type is DependencyProperty, some type used to implement the mechanism of dependency properties, and the field itself is one of the Canvas's attached properties.

Let me tell you this: both dependency properties and the attached properties are related to one special way to implement the normal property mechanism needed just in XAML. The build complies XAML into source code, say, in C#. That build step is, of course, agnostic to what the property names mean. So, it needs some lookup mechanism to find out: what is the location of the property data to be used by the setter or getter, if XAML tells only the name of the property? Essentially, this is all why all this machinery is used.

In the code behind, we use all those properties as regular properties, directly through property syntax or through the methods like Canvas.SetLeft. The getters are settes are defined in those properties is some special way, but it does not change how they are called in code. Using DependencyProperty objects in code behind would be totally pointless.

—SA

Matt T Heffron 29-Apr-16 14:05pm

OK, I agree that doing it with the Canvas.SetLeft() method is the correct way to do it.
(I was just asking about equivalency. Would both ways accomplish the same thing? Even if one way was not recommended.)
Thanks.

Sergey Alexandrovich Kryukov 29-Apr-16 14:32pm

I answered "maybe", don't want to dig into it again. Not quite sure, sorry. I think you can figure it by yourself. In effect, you can do achieve setting of the property. But...

But I'm sure it won't be equivalent in terms of performance. It's pretty much compares as setting some property value directly, through the known property member, versus extracting PropertyInfo object via Reflection. This is not exactly the the same, but based on similar ideas.

The assembly stores the metadata on all types and members. Ultimately, for an unknown type, you can find it by some criteria. Dependency property data is not stored in the same .NET assembly metadata; it is stored as normal data during runtime, but the semantic of this data is the dependency property metadata. Essentially, this metadata is used to bind 3 things: some type having a property (or 2 or more in case of attached), property name, and the property object storage mechanism, with its getter and setter. All this machinery is really needed when you translate XAML into, say, C# code; this process is not that fast as what's required during application runtime, but acceptably fast for the build step; and it's done once. If you do something like that during application runtime, you would do it 1) each time you need to set/get the property object, 2) it would take much more time than just calling getter or setter on a known property member. This is the reason it makes no sense. It's more than "not recommended".

—SA