I would like to automatically scroll to the top of the ListView when the user navigates to this with the back button. I tried to use this:
scrollViewer.ScrollToVerticalOffset(0.0);
It works, but the VS says:
ScrollToVerticalOffset may be altered or unavailable for releases
after Windows 8.1. Instead, use ChangeView.
Okay, I thought it's no problem, I will use ChangeView instead of this. But the ChangeView doesn't work properly. At least in my case. I tried this:
scrollViewer.ChangeView(null, 0d, null);
It works when I call it for example from a button, but it doesn't do anything when I put it to the OnNavigatedTo method.
So why does it work?
If you take a look at MSDN description od OnNavigatedTo, you will see that it's called before the visual tree is loaded. Therefore if you want to manipulate your UI elements - do it in Loaded event:
You cannot use OnNavigatedTo for element manipulation or state change of controls on the destination page. Instead, attach a Loaded event handler at the root of the newly loaded page's content, and perform any element manipulations, state changes, event wiring and so on in the Loaded event handler.
Related
I've a situation in a windows phone project wherein I'm dynamically creating UI elements one inside the other. This can lead to say a 10 StackPanel hierarchy . Now each UI element has a tap event attached to it. How do I make sure that only the tap event associated with the bottom most element is triggered (my problem being all 10 events are triggered)?
Have you tried to use eventArgs.Handled = true; into your event handlers to stop the event propagation? (see in MSDN).
It will stop the event propagation at the first event handler receiving it, which will be (in your case) the one associated with the deepest StackPanel located where the Tap event occurs.
Let's say we have a pretty standard form with a textbox and a button (for simplicity). You want to handle a Click event and do some stuff based on user's input.
I was wondering, does it matter, when exactly you wire up an event handler for the Click event in a code-behind? If it does, where is the best place to put it? Page load? Page init? I've tried both places, but didn't notice any difference. Or it's just a personal preference of the programmer? I've already searched the internet couple of times, but haven't found any satisfactory answer.
I know when the actual method execute, just not sure about the wiring-up part.
As you know, there are several Page_xxx event handlers, like Init, Load, Prerender... This events exist in Controls, and Pages as well as User controls (in fact they're derived form Control, which holds all these events).
This events are related to the ASP.NET Page Life Cycle
If you read the page pointed to by this link carefully you will understand when the events are triggered. So, if you bind your event handler in any page lifecycle event that happens before the events are triggered, it's guaranteed that your event handlers will be bound in time to be triggered.
These are the main lifecycle steps:
PreInit -> Init -> InitComplete -> PreLoad -> Load -> [Control events] ->
LoadComplete -> PreRender -> SaveStateComplete -> Render -> Unload
Not all of them have associated events, but, if it's necessary you can override the corresponding OnXxx() function, like OnPreInit(). (This is usually only done on custom server controls).
You can bind events in Page_Init or Page_Load, because the control events are triggerd after the loading of all the controls has finished. The Load step happens in top-bottom way, first in the Page, and then recursively in all the children controls.
After Load finishes, the first events which are triggered are the Change Events, like TextChanged or SelectionChanged. Then are triggered all the other events, like Click.
If you bound the events in PreRender or Unload, they wouldn't be triggered. If you did in Init or Load, they would.
So it could look like it's safe to bind in Init or Load, but that's not true:
It could look like there's no special reason to bind them on Init or Load, because they'll be triggered later in the page life cycle. But, as the binding defined in the .aspx happens during Init, a programmer will expect that all events are already bound in the Load event. What would happen if this programmer raised an event of a child control in code behind? The Load event happens first in the root of the control tree, and them on all of the children, recursively. So, by the time the programmer is trying to raise the event of the child control, it won't be already bound. So this won't work as expected. This is more than enough to consider unsafe to bind events in Load event. That's why you should always bind events in Init.
Look at this diagram to see the order of execution of Page & children events:
ASP.NET Page Life Cycle Diagram
I have been wiring mine up in the control tag. If I do it this way it is clear that an event handler is present.
<asp:Button ID="btnRefresh" runat="server" Text="Refresh" OnClick="btnRefresh_Click" />
If I had to wire up an event handler in the codebehind, I would put it in Page_Load as a private function call.
I want to give the user the option to use a tutorial, the first time he uses the program. I tried adding it in the Form.Load event, but the forms shows up after the Messageboxes have popped up.
That's why I would like to know, are there any events fired right after loading a form?
If not, is there a way to perform actions right after loading?
You should try the shown event, which fires after the form is shown for the first time.
Load happens before the form is shown.
You could try using the Shown event but that might be a bit early too based on what you are doing but it does occur after the Load.
If you have any controls on the page you could trigger it off the controls GotFocus event. Just make sure to put in checks to only do it once if using the GotFocus method.
MSDN Form.Shown
MSDN Control.GotFocus
MSDN Reference to order of events
System.Windows.Forms.Control.HandleCreated
System.Windows.Forms.Control.BindingContextChanged
System.Windows.Forms.Form.Load
System.Windows.Forms.Control.VisibleChanged
System.Windows.Forms.Form.Activated
System.Windows.Forms.Form.Shown
The Shown event should do this for you.
I'm using WBC in my project but I don't need it to be added to the form, I tried to call Navigate method but still get empty string when retrieving
the WBC .DocumentTitle!
Navigate is asynchronous, that means it goes to that web page on another thread and does not wait until it finishes. You are trying to get the Title immediatelly, but it is not set yet.
You should attach to DocumentCompleted event on the WBC and check for title there.
As noted the title can only be retrieved after it has been set. To know when that happens, in addition to DocumentCompleted event there is also a WebBrowser.DocumentTitleChanged event that is convenient and could simplify your logic.
Also, presumably, the latter event would also fire when title changes after the document is loaded via Javascript.
I need to execute code before a wpf user control is unloaded and cancel the unloading if certain conditions are met and keep the control open in its current state in the ui...
Is there any way I can accomplish this? I couldnt see anything like unloading event?
Thanks,
Unloaded is fired when the control is removed from the WPF visual tree. As far as I've been able to read there is no "Unloading" event as there is, I think, in Windows Forms. But, "Unloaded" doesn't mean that the control is destroyed, just that it's removed from the visual tree.
Keep a reference to the control in a separate place in your code, along with a little bit of metadata about its parent control. You can probably collect that metadata by storing a reference to the Parent property in your Initialized event handler.
Then, when Unloaded is called, make your tests in the Unloaded event handler, and if your conditions are met, re-insert the control into the logical tree. The ContentControl class has an explicit AddChild protected method you could call.
There are probably some side effects to watch out for; According to the documentation, Unloaded is called when themes are changed at the OS level, when the WPF visual tree reconstitutes itself.
There is an Unloaded event on System.Windows.Controls.Control, but I don't know an elegant way to stop unloading the control with it.
private void UserControl_Unloaded(object sender, RoutedEventArgs e)
{
if (ConditionsMet) { e.Handled = true; }
}
If ConditionsMet the Unloaded event will be set to true henceforth keeping your control in the VisualTree - your control does not Unload