Exception on class UploadFileView, event Unloaded

Oct 13, 2011 at 9:06 PM

I suggest this modification to solve possible exceptions on the UploadFileViewClass.

 

At the constructor, check if ViewModel is not returning null before executing UnitializeView()

  public UploadFileView()
        {
            InitializeComponent();

           //add this check
            if (this.ViewModel == null) return;

            this.Loaded += (s, e) => this.ViewModel.InitializeView(this);
            this.Unloaded += (s, e) =>
                {
                    this.ViewModel.UnintializeView();
                    this.DataContext = null;
                };
        }

There's a strange behaviour generating an exception after closing the UploadFileDialog window.
When debugging, I've put a breakpoint at the Unloaded event and verified that the ViewModel was null.

Can you help me discovering why this is happening ?

My code is:
private static readonly UploadFileDialog Ufd = new UploadFileDialog();

public void OnUploadCommand()
{
            Ufd.AutoClose = AutoCloseUpload;
            Ufd.AutoUpload = AutoCloseUpload;
            Ufd.BrowseAndShow();
}


Oct 13, 2011 at 9:12 PM

Interesting you bring this up, I had another customer have a similar error and in FireFox it actually crashed the SL Runtime. From best I can tell, when you close the dialog, the Files collection is adding a new yet null item, so after it's being removed from the visual tree the main view is no longer accessible. Good job in finding the bug.

I really want to find out why it's creating the null entry on close. But the band-aid is to check for the view model, but will stilll leave a dead object in memory.

Thanks for the feedback, and I'll keep you posted.

Oct 14, 2011 at 12:17 PM

OK, I've modified the test client thats included with the source code to test the bug and I cannot repro the issue.

Can you provide me more details or maybe check out the source code to your environment and run the test app and see if it happens from that project?

Oct 14, 2011 at 12:35 PM

Also to confirm, my other clients issue was OOB with debugger attached and using Firefox. I could not repro the issue, but his resolution was to run without debugger attached when testing OOB and Firefox.

Jul 22, 2012 at 8:33 PM

I guess a stack trace would show who called "public UploadFileView()" at closing time - isn't that a constructor?

Jul 23, 2012 at 8:03 PM

I suppose, but now that the latest version 3.0 is out, it's not longer an issue.