I have a page that I am navigating to that does some setup stuff via the 'OnNavigatedTo' event.
Thso page contains a TimePicker control and I have discovered that when I finish in the Timepicker control and focus returns back to my page it is again going through the 'OnNavigatedTo' event.
As a result is doing setup stuff again that is mucking things up, and if even has the same NavigationContext.QueryString as when I originally navigated to that page.
I assume I cannot avoid this event being called again - but is there any way to know that I have come here as a result of exiting the Timepicker control?
thanks
What about defining a bool in the class (instance-level, not static) that you set check in OnNavigatedTo -- if false, then do your work and set to true. Now, I'm not 100% sure that this works if you go back one level further and then tap on whatever brought up this page, so check that. Also, check to ensure everything works with tombstoning -- that's where you're more likely to have problems.
--randy
Related
My question is simple: WHEN (on what event?) can I be sure that a control has fully loaded and has its states and templates also?
Why am I asking:
I'm trying to restore the state of my own WP7 control after recovering from tombstone. This control looks like a calendar in a weekly view. In this calendar you can select many items displayed as colored Rectangles.
If I select any of them, and then go to tombstone and come back to the page, it seems like my control forgot which Rectangles were selected. In fact, it did NOT forget the data itself, but the Rectangles forgot their selected state.
After recovering from tombstone, I try to select the Rectangles by setting their VisualState to "Selected" (which works in any other scenario). I found out, that it fails, because VisualStateManager can't find the "Selected" state.
I know this is tricky, because when coming back from tombstone the controls do not build exactly as in any "normal" case. (for example Bindings and Templates do not apply in the same order) But up until now I could always trust, that when FrameworkElement.Loaded fired, I had my controls ready. Now it seems like VisualState is not. (I tried to set the state from Loaded event handler, but results are the same, VisualStateManager.GoToState returns with false.)
What more can I do?
This is a tricky one! I have also experienced issues where UI events fire before the UI itself is fully constructed, see this blog post for an example. My general approach to this is to handle the LayoutUpdated event, which fires each time the visual tree is updated. You will find that this event fires multiple times, both before and after the Loaded event.
When the Layoutupdated event fires, you can check whether the visual state change has worked, if so, no longer handle the event. If not, keep trying!
Within your loaded event, try the following:
// try to set the state
if (VisualStateManager.GoToState(myControl, "myState") == false)
{
// if failed, wait for the next LayoutUpdated event
EventHandler updateHandler = null;
updateHandler = (s, e2) =>
{
if (VisualStateManager.GoToState(myControl, "myState") == false)
{
myControl.LayoutUpdated -= updateHandler;
}
};
myControl.LayoutUpdated += updateHandler;
}
I've implemented iScroll into a web page, intended for a smartphone. I haven't tried this yet in an emulator so I don't know if this is just a PC problem.
The scroller contains a UL. Each LI is marked with an onclick event handler:
$("li.myitem").click(showItemDetails);
...
function showItemDetails() ...
When I implemented this prior to using iScroll, if I click ONCE on a LI I get one call to my click handler (which opens another view window). After using iScroll I have two bad behaviors.
When scrolling around, sometimes iScroll thinks that I want to click on something. That is, iScroll is working something like an "onmouseup" event.
When clicking on an event, whether intentionally or not, iScroll is generating 10, 20 and even 30 events (or event threads) for that one place that a single event is intentioned for. I traced it, and all of the events are coming from the same LI item. This occurs just as badly if I change the click handler to a double-click handler (dblclick()).
In the immediate, I'm reduced to putting in a gatekeeper, a flag saying "I'm already busy with an event, go away". I could also change the interface to have the user click (select) an LI and then click on a separate button to see the details.
But I'm concerned about what iScroll is doing.
Any ideas? Need to see code? I can't put on the whole app (a thousand lines long, after comments), but I can show decent snips. But I'm hoping that this is an "oh, yeah" moment and someone tells me a known story.
I need to change the Background Image of my Application if user changes theme from "Light" to "Dark" or vice-vesa in code behind. I hope these should be done in Page Loded event
#TimDams pointed you to one of the nice ways to detect what-theme-is-now-set, but I didn't notice there any information how to detect a change to the theme during the application runtime. The user could start your app, then bump forward to the menu, change the theme, and get back to your app. While you may think that your app will be tombstoned and then restarted and renavigated to your page with full cycle with all pageloads -- it is not 100% true.
Firstly, the PageLoaded is NOT a good place to do the initial check-and-set-styles, because, if you get that event called, then the page, probably, has already rendered once. If I remember well, the PageLoaded is invoked just after the first render. If this is true, then you will have to detect the colors earlier, for example in the LayoutUpdated (warning: this event is a great spammer. I mean, it gets called gazillions times. Attach a single-shot handler, you know, such that will instantly unattach-self on first invocation). Maybe you will be able to do it in the Page's .ctor, just after InitializeComponent. Or in the OnApplyTemplate or MeasureOverride, or at least ArrangeOverride -- the visuals should be mostly/fully available there.
Buuuut. I've intentionally 'bolded-out' the word "initial". With Mango, there's some multitasking getting more and more common, but even the pre-Mango 7.0 version does not guarantee that your app will be tombstoned. From my observations in early 7.0, for example, starting the MediaPlayer from WebBrowser component does not tombstone your app:) If you have some time to read, check WP7 recover from Tombstone and return to page for details on the "pause" vs "tombstone".
Anyways, if your app gets "paused" and the user switches themes in the meantime, I think (I've NOT checked) that your page will (in most of the cases) be just temporarily hidden and upon returning to the screen, it will probably not be re-created and will not be re-(Page)Loaded. If it is true, then you will have not so easy problem to solve, because your app may be paused, the OS rethemed, and your app unpased virtually in any moment of time and the only events you will get in the mean time are .... global events of App.Deactivated and App.Activated. It is possible that completely none of per-page events will fire [but I've not checked - before you do anything I suggest below, CHECK IT].
If this pessimistic view is really true, than in those events, you will have to detect the current theme (->Tim's post), then somehow inform your current Page that themes changed - or not. If you have your ViewModel at least a bit separated from the rest of the app (as it should be:) ) you have an easy option to do it: create in that ViewModel a set of properties (dp or inotif) like Brush Background, Brush Foreground, Brush Hightlight, and other that you need, and instead of harcoding colours in your XAML - bind to those properties. You may event want to create a separate class for all those many Brushes and other Styles, let's say "pub class MyCurrentAppTheme" and keep that props there, and expose such object from ViewModel - whatever. Just Bind your colors to whatever -- but whatever that will be "logically global" and that will be easily accessible from the App.Acticated event handler. Having that done, in the App.Activated, detect the current theme and if changed, so through all the colors kept in VM and set them appropriatelly. Voil'a, whole your App gets recoloured properly.
But mind that still - there might be some transient blinks and flashes between the rendering of cached old theme, refreshing databound objects, and redrawing fresh theme. I hope not, but I sense it may occur, especially when returning from fast-switch tool (long back press): I think that the device captures the 'last screenshot' of your app in the backbuffer and uses that throughout all the time the app is 'minimalized' to do transitions animations, to show the fast-app-switch overview and so on.. again, I've not checked, but I doubt that during such animations the pagecontents are 'live', it could be very demaning on CPU/GPU resources. Any one knows anything on that? It could be a nice test to have some looping animation on the page and then to switch out and check in the fast-switch overview, whether the animation moves or is halted!:)
If your application is tombstoned, all your controls will be recreated and the new theme will be applied. If you'd like to manage your light/dark specific styles in a similar vein to normal themes, you might want to take a look at a custom ResourceDictionary I blogged about a while back.
Unfortunately, as of Mango there, is a bug (?) related to fast application switching that causes the theme to remain unchanged in your application. The bug is outlined in this question and its linked posts:
Is there a bug when changing themes when app is deactivated and reactivated in Windows Phone Mango
My ResourceDictionary is still useful for the initial startup but it appears, unfortunately, that nothing can be done to workaround the Mango bug.
For this no event exists. You need to figure this out manually by comparing the PhoneBackgroundBrush color to see if the user has the dark or light theme and compare it with your last stored value.
Were you able to do some test on the App.Activate - Deactivate?
I decided to use a different path to solve the issue of dynamic theme change.
I've assigned to all text and buttons only system resource colors.
For the icons inside the buttons in the window instead of using PNG images-icons I used the in XAML and assing it a Foreground color from system resource.
For the buttons in the SystemMenuBar there is no issue as they are always on a dark gray background so the black PNG images work just fine.
Hoping this helps.
You can check if the dark theme is in use with this simple check:
public static bool CurrentThemeIsDark
{
get
{
return (Visibility)Application.Current.Resources["PhoneDarkThemeVisibility"] == Visibility.Visible;
}
}
I'm finding a common pattern during my WP7 development.
Something takes a long time to display and I want to break down the display into 2 parts - an initial display so I can show a Loading message and start the progress bar then a secondary display where I can load the data.
At the moment I'm trying to do this in a custom control but it could equally apply to user control or a page.
I can't find a way of doing this. Way back in WinForm days there were events I could call before the form was shown and others for after. I guess I'm looking for something similar.
I have also tried to see if I can display a stack panel first with the Loading message then capture an event on that to fire the data loading but nothing so far.
Any ideas?
I'm using Caliburn Micro BTW.
You can use the page's Loaded event or an OnNavigatedTo override to show the Loading message, and then you can use the BackgroundWorker class to run your long-running process on a background thread so that the UI thread remains responsive, and then in the handler for the RunWorkerCompletedEvent handler, which is marshalled onto the UI thread for you, you can hide the loading message and perform your second stage display.
Is there a way to handle OnBackKeyPress in such way that it returns to the actual page in the back-stack instead of going back to another instance of the same page? This is the code I have:
protected override void OnBackKeyPress(System.ComponentModel.CancelEventArgs e)
{
e.Cancel = true;
base.OnBackKeyPress(e);
this.NavigationService.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));
}
But it doesn't do what I want. is there a way to do this without using the NavigationService and getting the actual page in the back-stack instead?
Thanks.
The short answer is no you can't do that. Other than using the NavigationService to move backwards page by page there is no way to manipulate the back stack. Rightly or wrongly this is by design. And it kind of makes sense as they need to sure that the operation of the back button is consistent.
What you are trying to do is actually change the behavior of the back button. Which is not what the OnBackKeyPress is intended for. The WP7 Design Guide says the following about the back button:
The back button can close an on-screen
keyboard, menus, dialogs, navigate to
a previous page, exit a search
operation or even switch between
applications. However the principal
usage is to move from a current screen
to a previous screen.
If your scenario is not covered in the by the above I would suggest maybe you are trying to do something which is fundamentally in consistent with Microsoft's intentions for the back button.
If your reason for wanting this behavior is to maintain state on your previous page when navigating back, you can achieve this using dependency injection and the MVVM pattern. You can register a singleton/instance of your viewmodel in your dependency container. That way when your view gets navigated to via the back button, you can inject that single instance of the viewmodel into the view and have the previous state if you rely on the binding techniques of MVVM.
I know that there's a phone version of Ninject floating around for a dependency container so you don't need to roll your own injection container (just search for Ninject wp7).
I was able to fix it. This was the problem:
MainPage -> SettingsPage -> SetLocationPage
Once location was set, we sent the user back to SettingsPage with NavigationService.Navigate, then when the user pressed the back button in the SettingsPage it would go back again to the SetLocation, when it made more sense to send it to the MainPage.
This is how it was:
SetLocation -> SettingsPage -> (Back button) -> SetLocationPage
Now, I'm using NavigationService.GoBack instead of NavigationService.Navigate in the SetLocationPage:
SetLocationPage (once location is set use GoBack()) -> SettingsPage (use GoBack here too) -> MainPage.
Navigation now makes sense, and I solved it using NavigationService.GoBack().
Thanks for everyone's input.
I'm curious what you trying to do here and why you need to navigate to implement back.
Ordinarily you dont implement the override and the user presses back, and the NavigationService automagically takes the user to the previous bage in the back stack.
If this is not the case can you elaborate on why. There is some information that may help, but I suspect it would be a band-aid on top of an existing problem at the moment.