2

I had a type-o in my windows-8 app store code. I got a strange result, so I went back to look and realized I missed a value, but it still compiled and ran without errors. Thinking this was strange, I went and tried it in a windows 8 console application, and in that context it is a compile error! What gives?

App store version:

var image = new TextBlock()
            {
                Text = "A",    //Text is "A"
                FontSize =     //FontSize is set to 100
                Height = 100,  //Height is NaN
                Width = 100,   //Width is 100
                Foreground= new SolidColorBrush(Colors.Blue)
            };

Console version:

public class test
{
    public int test1 { get; set; }
    public int test2 { get; set; }
    public int test3 { get; set; }
    public int test4 { get; set; }
}

class Program
{
    static void Main(string[] args)
    {
        test testObject = new test()
                          {
                              test1 = 5,
                              test2 =
                              test3 = 6, //<-The name 'test3' does not exist in the current context                         
                              test4 = 7
                          };
    }
}
N_A
  • 19,799
  • 4
  • 52
  • 98

1 Answers1

5

I'm guessing the class in which your first block of code was located had a property called Height, and so the compiler was interpreting it as:

var image = new TextBlock()
            {
              Text = "A",
              FontSize = this.Height = 100,
              Width = 100,
              Foreground = new SolidColorBrush(Colors.Blue)
            };

That would also explain why your image.Height property was NaN -- your initializer never tried to set it.

On the other hand, the Program class where your second block of code is located doesn't have any members named test3, and so the compiler barfed on it.

The problem is clearer if you rewrite your initializer code as old-school property assignments:

test testObject = new test();
testObject.test1 = 5;
testObject.test2 = test3 = 6; // What is test3?
testObject.test4 = 7;
Jeremy Todd
  • 3,261
  • 1
  • 18
  • 17
  • Take a closer look. The second object does have a `test3` member. – chue x May 12 '13 at 00:48
  • The `test` class he's creating an instance of has a property called `test3`, yes, but the surrounding class (`Program`) doesn't -- he's trying to assign a value called `test3` to the property `testObject.test2`, and the compiler can't find a variable or property by that name in the current context, so it doesn't like it. – Jeremy Todd May 12 '13 at 00:50
  • Just to further clarify - the second code block should compile if we add a member to the `Program` class - `static int test3;` – chue x May 12 '13 at 00:59
  • Heh, right you are. It didn't even occur to me that it wasn't a property of the same object. Still... that seems like a poor choice to allow an assignment of a variable which is not part of the object inside of the object initializer. – N_A May 12 '13 at 01:21
  • Well, that would make initializers pretty darn limited. You'd only be able to assign literals, and objects you can initialize using literals. – Jeremy Todd May 12 '13 at 01:22
  • @JeremyTodd How so? I've never tried to assign a value to a member of the _containing_ object when initializing a new object. – N_A May 12 '13 at 01:24
  • @mydogisbox Oh, I see what you're saying. I dunno, I'd rather have enough rope to hang myself instead of not enough rope to do what I want. :) – Jeremy Todd May 12 '13 at 01:25
  • @JeremyTodd It just seems to entirely defeat the purpose of having an initializer. Pretty much the only reason I can see to use an initializer is for clarity of intent and ... well ... this entirely defeats that. – N_A May 12 '13 at 01:27