locked
PropertyChanged problem..

    Question

  • I'm following the Metro C++ tutorial:
    http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx 

    Just for testing purpose I decide to update FeedData to fire notification changed when Title property changed.

    As in change from

       [Windows::UI::Xaml::Data::Bindable]
       public ref class FeedData sealed
       {
       public:
    	property Platform::String^ Title;            
       };   
    

    to

    [Windows::UI::Xaml::Data::Bindable]
    public ref class FeedData sealed : public Common::BindableBase
    {
    #pragma region Title
    
    private:
      Platform::String^ mTitle;
    
    public:
    
      property Platform::String^ Title
      {
         Platform::String^ get() { return MTitle; }
         void set(Platform::String^ value)
         {
           if(value == mTitle)
             return;
           mTitle = value;
           OnPropertyChanged("Title");
         }
       }
    
    #pragma endregion
    };   
    

    And it worked well in part 1

    In part 2, when multiple feed data are loaded, the application kind of freeze while loading data after updating the title of 2nd feed.

    What Can be happening? Confused.. as the FeedData is still a private method property at this stage...

    FeedData^ App::GetFeedData(SyndicationFeed^ feed)
    {
        FeedData^ feedData = ref new FeedData();
    
        // Get the title of the feed (not the individual posts).
        feedData->Title = feed->Title->ToString(); 
        // ... freezing when coming here the 2nd time ...


    Saturday, March 10, 2012 8:46 AM

Answers

  • Turns out there were Platform::COMException exceptions being logged in the output window.

    Breaking on one of the exceptions, the error was: 0x8001010e . The winerror.h defines this as RPC_E_WRONG_THREAD The application called an interface that was marshalled for a different thread.

    Looking at the callstack, there was a PPL concurrency task continuation executing. Looking at the App.xaml.cpp line 128 we see they were configured to use any thread (in this case background threads)

    concurrency::task_continuation_context::use_arbitrary

    See this document for more information on this topic: Creating Asynchronous Operations in C++ for Metro style Apps

    It details how task_continuation_context affects the apartment the continuation is executed from in this section, Controlling the Execution Thread. The simplest way to correct the problem in this project is to change the task_continuation_context to ::use_default

    //Remark this line }, concurrency::task_continuation_context::use_arbitrary())
    //change to use_default
    },concurrency::task_continuation_context::use_default())

    Thanks!


    David Lamb


    Friday, March 16, 2012 2:24 AM
    Moderator

All replies

  • Hi

    I'm looking into this issue and update asap.

    Yi


    Yi Feng Li [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, March 13, 2012 12:51 PM
  • Could you email me your project in this problem state to look into please?

    DavidLam AT Microsoft DOT COM

    Thanks!


    David Lamb

    Thursday, March 15, 2012 1:11 AM
    Moderator
  • Thanks, just emailed it!
    Thursday, March 15, 2012 1:18 PM
  • Turns out there were Platform::COMException exceptions being logged in the output window.

    Breaking on one of the exceptions, the error was: 0x8001010e . The winerror.h defines this as RPC_E_WRONG_THREAD The application called an interface that was marshalled for a different thread.

    Looking at the callstack, there was a PPL concurrency task continuation executing. Looking at the App.xaml.cpp line 128 we see they were configured to use any thread (in this case background threads)

    concurrency::task_continuation_context::use_arbitrary

    See this document for more information on this topic: Creating Asynchronous Operations in C++ for Metro style Apps

    It details how task_continuation_context affects the apartment the continuation is executed from in this section, Controlling the Execution Thread. The simplest way to correct the problem in this project is to change the task_continuation_context to ::use_default

    //Remark this line }, concurrency::task_continuation_context::use_arbitrary())
    //change to use_default
    },concurrency::task_continuation_context::use_default())

    Thanks!


    David Lamb


    Friday, March 16, 2012 2:24 AM
    Moderator
  • ho... I.. thought about Async but I dismissed it.. :~

    I guess I have to read a bit more...

    Thanks! :)

    Friday, March 16, 2012 9:06 AM
  • It wasn't obvious for me either when I first saw it. It took a bit to track it down.

    Great question!


    David Lamb

    Friday, March 16, 2012 3:03 PM
    Moderator