The "basic usage" sample given here (http://shawnoster.com/2012/10/welcome-custommessagebox-to-the-windows-phone-toolkit) doesn't work on a particular page of my application. The UI elements just don't appear (visually), but then there is some weirdness and some controls can no longer be hit (but others can...). I admit that I didn't bother looking too far into the issue because I have to move on (by moving back to Guide.BeginShowMessageBox), but on top of my head:
Is it supposed to work with Silverlight / XNA hybrid apps? (on a page that uses an UIElementRenderer)
Is it supposed to work with pages that listen to manipulation events on the PhoneApplicationFrame?
The page the control didn't work on has these two characteristics which may make it more quirky when compared to a typical XAML page.
The following is a general comment not related to above issue:
Assuming that this control would have suited my need, I would have loved to have a static and blocking "Show" overload just like the 1st party control has. For example, an argument-compatible replacement for the static "MessageBox.Show" method (and even the "Guide.BeginShowMessageBox" method which can be rendered blocking using a ManualResetEvent...) would have gone a long way in helping integrate this promising control into existing projects.
Btw, I was looking forward to using this control to work around the absurdly large gutter that 1st party message box controls impose on landscape message boxes.
Is it supposed to work with Silverlight / XNA hybrid apps? (on a page that uses an UIElementRenderer)
Is it supposed to work with pages that listen to manipulation events on the PhoneApplicationFrame?
The page the control didn't work on has these two characteristics which may make it more quirky when compared to a typical XAML page.
The following is a general comment not related to above issue:
Assuming that this control would have suited my need, I would have loved to have a static and blocking "Show" overload just like the 1st party control has. For example, an argument-compatible replacement for the static "MessageBox.Show" method (and even the "Guide.BeginShowMessageBox" method which can be rendered blocking using a ManualResetEvent...) would have gone a long way in helping integrate this promising control into existing projects.
Btw, I was looking forward to using this control to work around the absurdly large gutter that 1st party message box controls impose on landscape message boxes.