locked
Screen entity (this.[myObject] is null in VS2013 RRS feed

  • Question

  • Hi

    I'm building a LS LOB app using the Silverlight template in VS2013. 

    My data entities are from an "external source" which is SQL and I've imported the relevant SQL tables as required. One is a Person table which thus gives me a Person entity in the LS app and I've created a PersonDetail screen to update the data. 

    I have a computed column displaying as a label for which I'm setting the text colour based on the value of another field. 

    So in my PersonDetail partial class I have the following: 

    partial void PersonDetail_Created()
    {
      this.FindControl("MyComputedColumn").ControlAvailable += new EventHandler<ControlAvailableEventArgs>(SetColor);
    }
    
    private void SetColor(object sender, ControlAvailableEventArgs e)
    {
      if (this.Person.LogonName.ToLower().Contains("xyz"))
      {
        ... do something ... 
      }
    }

    It is failing in the SetColor event saying that the this.Person is null. 

    This was working 100% and the only thing I have changed is doing an "Update Datasource" since we've added a new column on the SQL table Person. The new property pulled through, everything compiled but now my Person object is null for no apparent reason. 

    Please help.

    Thanks

    Neville


    Friday, August 1, 2014 2:40 PM

Answers

  • It does seem odd that is was working before.  I wonder if it's a threading issue.  Try reversing your logic so that this.Person is conditionally evaluated during the PersonDetail_Created() method, when it is assured that you are still in the Screen logic thread.

    partial void PersonDetail_Created()
    {
    if (this.Person.LogonName.ToLower().Contains("xyz"))
      {
        this.FindControl("MyComputedColumn").ControlAvailable += new EventHandler<ControlAvailableEventArgs>(SetColor);
      }
    }
    
    private void SetColor(object sender, ControlAvailableEventArgs e)
    {
      // do something
    }


    Addenda:  I'll hedge on threading as the source of the problem, since that usually throws a specific invalid thread exception.  But switching around your logic as above or possibly using the Person or PersonDetail property validation method to do the same thing may be successful.

    I also just noted that you have "created a PersonDetail screen to update the data."  Although you mentioned that this is not different from your prior scenario that was working, does this screen have the Person entity set in its ViewModel?  Or do you need to access the Person as a property of the PersonDetail, e.g., this.PersonDetail.[SelectedItem].Person?

    Friday, August 1, 2014 7:39 PM
  • It's deffo a threading issue, the retrieval of the record is done on the logical thread, and the FindControl.ControlAvailable fires on the UI thread. 

    Check for null, and if it is, start a simple timer loop until your property is resolved, or subscribe to the screen's changed event.


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Sunday, August 3, 2014 12:04 AM

All replies

  • It does seem odd that is was working before.  I wonder if it's a threading issue.  Try reversing your logic so that this.Person is conditionally evaluated during the PersonDetail_Created() method, when it is assured that you are still in the Screen logic thread.

    partial void PersonDetail_Created()
    {
    if (this.Person.LogonName.ToLower().Contains("xyz"))
      {
        this.FindControl("MyComputedColumn").ControlAvailable += new EventHandler<ControlAvailableEventArgs>(SetColor);
      }
    }
    
    private void SetColor(object sender, ControlAvailableEventArgs e)
    {
      // do something
    }


    Addenda:  I'll hedge on threading as the source of the problem, since that usually throws a specific invalid thread exception.  But switching around your logic as above or possibly using the Person or PersonDetail property validation method to do the same thing may be successful.

    I also just noted that you have "created a PersonDetail screen to update the data."  Although you mentioned that this is not different from your prior scenario that was working, does this screen have the Person entity set in its ViewModel?  Or do you need to access the Person as a property of the PersonDetail, e.g., this.PersonDetail.[SelectedItem].Person?

    Friday, August 1, 2014 7:39 PM
  • It's deffo a threading issue, the retrieval of the record is done on the logical thread, and the FindControl.ControlAvailable fires on the UI thread. 

    Check for null, and if it is, start a simple timer loop until your property is resolved, or subscribe to the screen's changed event.


    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Sunday, August 3, 2014 12:04 AM
  • PS: seems your server is a wee bit slower then before ;-)

    Keep rocking LS!
    Jan

    PS: have you seen app-stitch yet? It's a visually simple yet powerful way of designing business rules for Visual Studio LightSwitch apps.

    Sunday, August 3, 2014 12:04 AM
  • Thanks. I wrapped my eventhandler creation in an if-statement checking that the object is not null, and that did the trick. Still odd though...
    Monday, August 4, 2014 12:18 PM
  • Hi Jan, I add the null check but not the timer so I do nothing if it is null. So far it is never null and works every time. So it seems unnecessary then to check for null, but without the null check it fails as originally posted. Weird.
    Monday, August 4, 2014 12:20 PM
  • I think this might be the reason after all. My server is still my localhost on my dev workstation but the way I log on to our LAN has changed. The admins had to install a local proxy client on machine lately and that seems to slow down anything that does any network authentication on my PC. So that is why I quess my "server" is now a wee bit slower than before. Its the only logical reason I can find. Nothing else has changed.
    Monday, August 4, 2014 12:25 PM