I'm working on a WP7 appliation with Silverlight. When a user clicks the back button, I want to determine where they will go to. Is there a way to determine where a user will go without managing my own nav stack?
thanks!
To respond to the question that has actually been asked "Is there a way to determine where a user will go without managing my own nav stack?"
You could use the OnNavigatingFrom override the eventargs of which carries the Uri of the page being navigated to. I suspect this is only useful when the navigation is back to page within your app.
You cannot override what the back button does - the rule Derek mentioned is enforced by the system and the previous page/app will always be called.
You can, however, add an action to be executed on back key press:
this.BackKeyPress += new EventHandler<System.ComponentModel.CancelEventArgs>(MainPage_BackKeyPress);
Then just use the handler:
void MainPage_BackKeyPress(object sender, System.ComponentModel.CancelEventArgs e)
{
// Your activity goes here
}
The application will go back to the previous page when the user presses the Back button. If the user is at the last page in the application, then the application will exit and the user will be navigated to the previous application. To perform anything else would be inconsistent, confusing to the user, and almost certainly would fail certification.
In general you'll want to build your app composed of pages (similar to a website). For example a HyperlinkButton might be used like this:
<HyperlinkButton NavigateUri="/Page2.xaml" Content="Click here to enter page 2"/>
After clicking that then pressing the back button will automatically return to the previous page. There's no extra programming involved to make this happen... it just works.
But there are some circumstances where you'll want to override the back button. The one I ran into was the dialog box. If your app creates a dialog box, then the back button should close it instead of returning to the previous page. I wrote a brief article about how to accomplish this.
And here's a complete list of rules from Microsoft's certification requirements concerning the back button:
To maintain a consistent user
experience, the Back button must only
be used for backwards navigation in
the application.
a. Pressing the Back button from the
first screen of an application must
exit the application.
b. Pressing the Back button must
return the application to the previous
page.
c. If the current page displays a
context menu or a dialog, the pressing
of the Back button must close the menu
or dialog and cancel the backward
navigation to the previous page.
d. For games, when the Back button is
pressed during gameplay, the game can
choose to present a pause context menu
or dialog or navigate the user to the
prior menu screen. Pressing the Back
button again while in a paused context
menu or dialog closes the menu or
dialog.
As I found out, if you don't follow those rules they won't approve your app.
Related
In Microsoft's Toolkit DataForm
User is trying to add a new item in Toolkit Dataform by clicking Add icon. In the middle if he selects any other menu tab, then he is going to lose all the entered info.
I want to show promt to User to Save When Leaving a Page. Like Warning user before leaving page with unsaved changes.
After some research I found the solution.
Theere is a Method called OnNavigatingFrom in Silverlight page. that methods is Called just before a page is no longer the active page in a frame.
So you can add any alert or confirm message in that methods.
protected override void OnNavigatingFrom(NavigatingCancelEventArgs e)
{
if (DataForm.IsEditMode)
{
System.Windows.Browser.HtmlPage.Window.Alert("Please Save or Cancel changes before switching the page");
e.Cancel = true;
}
base.OnNavigatingFrom(e);
}
that will be called when you want to move to other page from current page edit or add mode.
I have a really strange issue relating to how I handle navigation in an application, and that application now being rejected from AppHub (after being successfully approved a number of times on the same code base... grr)
currently I am capturing the first navigation of the application and routing it an "add item" page in the App.cs using the example found here
the user then adds an "item"
the user is taken to the "main" page again, but stay there are there is now 1 "item" to show in a list
the user then can view a "detail" page of this item where they can select to delete the current item. when they do that I redirect them to the "main" page again.
this navigation then fires the same thing that happened in step 1
and they are routed to an "add" page
the problem with the above process, is that if the user hits "back" on the routed page in step 5 they don't go anywhere as they are routed back to the current page (because there are no items on the page previous and this fires the app.cs routing event to take them to the add page). if I did allow for them to go back, the actual first page they would be able to go back to is 3 nav steps back, when they first added the item - as they are on the "add item" page already, this would be pointless.
The apphub store testers say that in this instance, the application should close. I really don't know how the f&*k I am meant to make this happen, as there is no "go back until close" action I can call...
thoughts?
When the user decides to "delete" the current item, you shouldn't navigate forward to the main page, leaving the deleted item in the navigation stack. You should navigate back to the main page. That way the navigation stack will be empty, and if they navigate back again, the app will close.
(The same is true at step 3, of course - when the item is added, navigate back to the main page. You don't want the "add" page as part of the navigation stack; that action has been completed.)
The single best advice I read on WP7 navigation was "if you don't have to, don't use it." I've almost stopped using it all together and just use "MainPage.xaml" for loading/unloading user controls that do this kind of stuff. I completely control the Back button as needed. It has saved me so much headache. The important thing to realize is that the Navigation pages are really just mimicking a website and it's pages - many apps do not fit that paradigm (as they are apps, not websites). So, if you don't have to use Navigation, don't use it.
So in your case, if you just managed everything on MainPage.xaml, you would use a number of If/Then statements in OnBackKeyPress and if one meets your criteria, do an e.Cancel = true; and show/load/etc. your thing. If not, let the app navigate out of itself - i.e. exit.
For tombstoning, just let the OnNavigatedTo in MainPage.xaml handle loading the right user control received from tombstoned information retrieved from Application_Activated.
I've got a "Main Window" containing quite a few things, including, in the status bar (at the very bottom of the window), a "Support" button, which the user can use at any time to open a window containing our support phone number, along with a little chat functionality if the user prefers to chat with us.
The problem is that if the program is displaying a modal dialog, the "support" button is not clickable anymore.
Stopping using modal dialogs is not an option ; I use them because I sometimes want to force the user into performing a specific task before I can do something else in the software.
What's the best way to let the user contact the support without having to close the current modal dialog?
Modal dialogs should behave as modal dialogs, the user won't expect to be able to click a button in the main window even if it were possible.
Your best bet is to put a support button on the dialog too.
Using a shortcut key instead of a button may be an option. The functionality could be factorized into a base form class like this :
public class BaseForm : Form
{
protected override bool ProcessDialogKey(Keys keyData)
{
if (keyData == Keys.F1)
{
SupportForm f = new SupportForm ();
f.Show();
}
return base.ProcessDialogKey(keyData);
}
}
Not using modal dialogs is an option. You can disable other parts of your interface during the required interaction to get whatever it is that you need out of the user.
The solution is to avoid situations where the user 'must' do something. Modal dialogs often get in the way if, for example, the user wants to quit the application right at that moment, or see something in a backgrounded window, or refer to another part of your application. Instead of using them, design your interaction so that if there is a required action/piece of information, it's folded into the application logic.
Think about website design -- modal dialogs are very rarely found on the web, and for good reason -- they disrupt the user's workflow unnecessarily. And yet plenty of sites have 'required' information.
Don't use modal dialogs; they are a shortcut to avoid a better design.
Is there a way to start off showing a dialog modally, but then instead of hiding it, to keep it visible while changing it to a non-modal dialog?
I want to show a dialog, blocking the method that shows the dialog. Then when the user clicks the 'Finish' button on the dialog I want:
The dialog to remain visible.
Control to return to the method that showed the dialog.
I've achieved this result by running the dialog on a separate STA thread, and using an event to block the main UI thread until 'Finish' is pressed, but there's a catch to this method: you can click on the close button of the 'main' window while the dialog is visible, and the main window closes when the dialog is hidden.
Update
Thanks for the responses so far. Sorry - it looks like I got the balance wrong between too much background and not enough.
The form is effectively a modal 'wizard' dialog - it appears, sits in front of the main app modally, and then is hidden. So as far as the user's concerned there's no non-standard weirdness going on. The only difference is that the dialog is driven from a series of callbacks from the UI thread, so I don't think making it truly modal (via a call to ShowDialog) for its lifetime would work. The first callback must show the dialog, and then block while the user sets their preferences via the dialog UI. After that, the dialog stays visible and displays a progress bar page while various other callbacks are made from the UI thread. Eventually the form is hidden. The user isn't interacting with the main window while the form is up. As far as they're concerned, it should appear to be 100% modal wrt the main UI thread.
(The form is a dialog for a Visual Studio wizard - these are driven from a series of callbacks on the UI thread). An alternative would be to show the dialog, hide it, immediately show a topmost 'progress' form instead and then hide that, but I think showing a single dialog is more seamless an experience for the user.
Again - sorry for the confusion!
Perhaps you want to rethink your interaction model? How are you going to explain this to your users? They have an internalized model of how computer programs work, and you better have a very good reason to break that. They know about modal dialogs, they know about non-modal dialogs, they know about inspectors. Choose one, and apply it.
Modal dialogs are made for short-time interaction. They should not block exiting the application. The user is in control of the interaction, the program only provides the minimum of restrictions needed.
[after the explanation, replaced]
What's wrong with showing the progress bar in the modal dialog? Start processing once ok
is clicked, disabling all buttons, only keeping the cancel button active? If it takes a long time, the user might want to abort the action. Only close the dialog when you're finished processing.
You could use a modeless dialog then have your main UI check if the user has clicked the Finished button. If the modeless dialog is open but Finished hasn't been clicked then don't respond to any users actions in the main form...
This is just a terrible idea - it's completely non-standard behavior and you're going to jump through all kinds of hoops to get something working that is just going to horribly confuse your users.
Like most of the other answers here stated, you're implement non-standard UI elements that will be confusing to most users.
If the dialog remains visible just to provide read-only access to the data, then why not have dialog window close normally and open a side-bar window in your application with the data from the dialog window?
If the dialog remains visible to allow the users to continue making updates in it, then perhaps, it shouldn't be modal to begin with.
Point is, there's a couple different ways you can accomplish your task without breaking standard UI metaphors.
I'd make it a flyout from the side or bottom of your app that shoves other things out of the way. If it's on top of other stuff that the user might need to see or interact with then it's just gonna annoy them.
I found that showing an an invisible modal dialog on the main UI thread during the blocking stage of the interaction works great.
Hidden modal dialog settings (so it's not visible): ShowInTaskBar=false, FormBorderStyle=None, size={0,0}, Opacity=0%, StartupPosition=CenterParent.
The hidden dialog is shown on the UI thread using ShowDialog. The visible dialog is shown on a separate STA thread. The thread is kicked off before calling hiddenDialog.ShowDialog on the main UI thread.
The visible dialog hides hiddenDialog when it wants the initial blocking state to complete. This stops the main UI thread from blocking.
The important bits of code:
void LaunchWizardForm(s)
{
// Show the wizard on its own thread.
ThreadStart t = () =>
{
_wizard = new WizardForm(s);
Application.Run(new ApplicationContext(_wizard));
};
var thread = new Thread(t);
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
// Block this (main UI) thread
_hiddenForm.ShowDialog();
}
void EndModalEpisode()
{
_hiddenForm.Invoke((Action) (() => _hiddenForm.Hide()));
}
I have a base panel class that has (among other things) three buttons. I use subclasses of this base class in two different config dialogues. Both dialogues have an OK button set as the accept button.
In one of the dialogues, if I click one of the buttons in the base class, focus immediately returns to the OK button, so pressing the enter key works as expected.
In the other dialogue, focus remains wth the button in the base class that was clicked if it is enabled, or moves to the next button if the clicked button is no longer enabled.
There is no code that handles the base class button click events in either of the derived classes.
Ideas anyone?
I'm not sure what's going on in your first dialog because it doesn't seem to be operating the way I would expect it to. The second dialog sounds more like the standard behavior.
In Windows Forms, the AcceptButton property only comes into play when pressing Enter doesn't otherwise cause any actions. In both of your examples, clicking on a button should move the focus to that button, and subsequently pressing Enter would cause another click on that button.
In any event, I think it's generally preferable to stick with the Windows user interface guidelines and not automatically change the input focus back to the OK button. If the user clicks on one of the other buttons, the focus should stay there until they move it.
i don't know what language you are using, but the button class should have a focus method that will highlite it for enter pressing. in the click method, or when you open the dialog you can call this method to make the button you want get the form's focus
c#
myButton.Focus();