I have a certain UI element, which when clicked should navigate to another URL.
I tried handling the mouse down event and execute something like this:
System.Windows.Browser.HtmlPage.Window.Navigate(new Uri("http://google.com"), "_blank");
However, this gets blocked by the browser (I tried both Chrome and Firefox) unless I disable the popup blocker.
I did some research and it seems that the browser blocks navigations that don't occur as a result of user interaction and as far as the browser is concerned this navigation is initiated by a plugin (Silverlight), not a user.
OK, makes sense. But then I tried using a HyperlinkButton instead and it was NOT blocked.
I wonder why these two approaches get different treatment from the browser. Any idea?
I actually worked around the problem by wrapping the navigation triggering UI with a HyperLinkButton, but I'm still very curious...
I'm going to pull a fancy corporate quote and say "It is a feature, not a bug."
The Silverlight team is obviously worried about Security. They don't want crazy haxorz like you and I to do crazy things with our apps--you know, like popping up a bunch of browser windows all routing people to Zombo.com. Just imagine the choir! Zombo!
Summarized from their documentation: They want us to only use the HyperlinkButton to go outside of their application. In fact, they went the extra step, and depending on our settings, they will even throw a SecurityException for us if we navigate to an outside page--Even from a HyperlinkButton. How nice.
The real question: Why the Hyperlink Button and not something else?
Only one "thing" can navigate. this take saves time for Microsoft while testing Silverlight. This one thing can navigate to both internal XAML pages and external web pages--Might as well be consistent and have only one way to do navigation.
It is a UIElement. It's code behind likes to run in the primary visual thread. It can promise the browser that a Visual Element wants to go somewhere. Microsoft can also put its limiting logic in a control that requires a mouse-click/keyboard-input event tree.
All in all, it makes sense to start simple by making a control do the work.
Fun stuff! Hope this helps you.
Related
I dont hope to get any answer but i will try to be clear.
I tried Caliburn Micro . At first it seemed fine and all i need. Some features yes but other not.
All i wanted is a single window with some views as usercontrols and multiple dialogs at each view. Using a conductor.OneActive i could achieve the first with little pain. However switching between views even looking the example was to cast Parent to Conductor and call a method there.
Even example of caliburn micro did casting like this. Calling .close(false) at screen was same as close(true) resulting in killing the view and recreating causing lag in lowest end atom pc.
So only solution was to cast to parent.
Dialogs
I tried tons of dialogs examples but non worked and made my life hard.
Messagebox etc were DEAD easy but in case you wanted multiple dialogs you were out of luck.
If you put code at close callback to open another dialog you got bonus stackoverflow exception as it gets confused.(Endless loop).
I could figure a good dialog that could cache the view and at the same time to display efficiently multiple dialogs.
Event Aggregrator
Also i cant figure out how on earth event aggregrator is suitable for switching views. In case you have multiple conductors it could be a hell to manage.
To show a dialog - as in Modal Dialog that blocks the view that showed it - you should be using IWindowManager.ShowDialog.
You should take a look at prism library http://compositewpf.codeplex.com/
see navigation chapter: http://msdn.microsoft.com/en-us/library/gg430861%28v=pandp.40%29.aspx
But I don't know how EventAggregator could help you to switch views… you could subscribe to received an event on a closingView but… …
You might want to take a look at Catel. It has a UIVisualizerService which allows you to show windows based on their view model.
It also has a ViewManager (IViewManager) which allows you to manage all views inside your whole application. Besides that, it also provides a ViewModelManager (IViewModelManager) which does the same for your view models. Best of all: you can find all views that are connected to a specific view model in your application to interact with that.
Well ... at the risk of sounding like I really don't know anything about programming, I have a question about controls in Silverlight 5.
I have an OOB App that I am working with, but I need to add the User Menus (File, Edit, etc.) that are normally seen at the top of all apps. There used to be a control in VS (the Menu control) that was easily configurable. What is the control used to create the User Menus in Silverlight 5? The Context Menu is not what I am asking about. That is the right mouse click menu ... so that's not the answer ...
Please, understand my problem. It's been since Silverlight 2 since I worked in Silverlight. I appreciate any information you kind folks would be willing to provide.
There is no such thing available directly from Microsoft (meaning it's neither built-in or present in the Silverlight Toolkit).
You will have to use third-party controls such as DevExpress or Telerik.
EDIT: Some more advice in response to your comment.
Another possibility is to create UIs from scratch. There are two forms of UIs that I found inspiring lately, both of which don't use any ribbons or drop-down menues at all. The first is to use "Windows 8"-like dashboards instead of traditional menues, the other is the Windows Azure Management Portal (a web application).
I don't use traditional UI frameworks for menues myself, but mostly because I don't like those approaches and I'm picky with how user interfaces should work and look like.
But obviously you have to make a serious time investment to go new ways. And it will heavily depend on your application what approach makes sense.
Here's one simple approach that could work in a number of cases, I used it for a database application (I call it the Windows-Phone-7/8 approach):
The screen is divided into the "page" area and information bars. The information bars contain no menues, just who's logged on, a back-button, a home-button, and context-sensitive buttons depending on what's in the view. So basically it behaves like a web browser and you navigate through the app by clicking on "links" (buttons that take you elsewhere).
There's only one page area, so no windows and no popups. I've gone to the extreme of making even dialog windows to be pages.
Now you need menues. You do that with "dashboards", ie. pages that present some overview stuff and buttons that lead to the other areas of your application.
Although you could have action buttons like save or delete on the page itself, I put them in the bottom bar (but they are still dependent on the page your on) - that is exactly how it works in Windows Phone 7/8.
One last advice: The real effort is usually not in the menus anyway. Beside your application logic itself, it's a lot of little things like login screen, error handling and how to present error messages (look at the windows azure management portal for how they did that really nicely) and gracefully failing on session timeout. There's also a lot of nuisance on how you manage your data (ria-services, etc.).
So as long as you don't need fancy data grid grouping, rich-text edit or excel-like pivot controls, a toolkit might not help you as much as you'd hope - because they give you only the controls, not the entire UI.
What is the best approach to make an SPA (AngularJS) Accessible (for screen readers etc)?
I have little to no experience with the aria specification, and I wonder if it will at all work on a single page application.
What are the common pitfalls when developing?
How do one debug and test the accessibility when developing?
This could cover a broad swath of issues here. So I'll go through some of the basics in the hopes that it starts you on your way, the common pitfalls, as it were.
Firstly, like the commenters said, yes, you need to make sure ARIA tags are employed correctly. So, say, if you wanted to expose a div as a button, you'd have something like this.
<div id="mysuperflashybutton" ... role="button" aria-label="Super flashy" tabindex="0"></div>
This button when selected by a screen reader will be called "super flashy button", so you don't need to put button in your aria-label attribute. There are more complex examples out there, but that illustrates the basics of it, pretty much. Role, aria-label and tabindex will be the most prevalent ARIA attributes you see.
Tab-indexing elements that you want screen reader users to click on is vital to this. Set tabindex to 0 to include it in its default location on the document. If you don't want it to necessarily normally be reached by people using keyboard navigation, set it to -1. This means it's out of the normal tab order, but can still be navigated to if you want to put the user's focus there manually through javascript/jquery .focus().
As mentioned, sometimes you can assist keyboard navigators/screen reader users by moving their focus for them. An example would be if they click a button and a menu appears. You could do something like this to put them on the first link of the menu:
$('#linkmenuactivator').on("click", function () {
$('#linkmenu').find('li:first a').focus();
});
I know that's in JQuery, I'm not familiar with AngularJS but my brief view makes me think it's more of a ViewModel controller as opposed to something UI specific like JQuery, but correct me if I'm wrong.
Live regions can be used if you're doing funky things on screen that will make no sense to a screen reader user. You can write text to the elements in these regions to put the information out textually. The easiest way to do this is to use a role of alert or status, for important messages or generic status updates respectively. These roles make your element a live region by default, and any text changes in there will be reported to the screen reader. So a quick example would look something like this:
<p id="ariastatusbox" ... role="status"></p>
Then later in JQuery (taking the example of you loading a document and fading it in when you've got it):
$('#maincontent').fadeIn(function () {
$('#ariastatusbox').text('Document loaded');
});
This will let the screen reader know that the document is loaded and ready to be read on screen. Live regions can be slightly tricky, but they're a powerful beasty if you can master them.
Finally, as to accessibility testing, there's a few options. Something I recently stumbled across is Wave which appears to be an online testing tool. It looks good from a first glance, you could give it a try. Another option is to grab a screen reader yourself and give it a go. I recommend NVDA which is an open-source (so therefore free) screen reader. It's my screen reader of choice and is pretty damn good. The synthesiser it comes bundled with doesn't have the nicest voice, but there are other options, or you could turn off the speech output and view a textual display of what it would be saying using the Speech Viewer. A final option is to ask for accessibility testers to take your app for a test drive. For consumer products or things in those brackets, blind people and other users of accessible tech may well volunteer to do it if asked. For more business oriented apps that you might not want out in a public forum, there are several organisations that can consult on issues of making web applications accessible.
This is by no means a comprehensive manual on accessibility, I was hoping to really kickstart you in the right direction. For a bit of a deeper look, try looking at the ARIA roles documentation (all of it will help but the code is under the definitions heading), and on from that the ARIA States and Properties documentation. They both can be a little dry, but also have the full list of everything you can use ARIA wise. Google should be able to yield some tutorials, too, I hope.
I hope this helps get you started. Good luck!
I'm making a Sketchflow WP7 application which is working fine, except Navigation is sometimes buggy. Sometimes when I go to a screen and try and click it doesn't work, some times it does. I'm using the MouseLeftButtonDown Event to trigger it. After it 'freezes' I can no longer navigate via the map either, though before it freezes I can. I'm not sure if any errors are thrown because I'm not aware of a real time silverlight console. Sketchflow doesn't have a 'Debug Project' option only a 'Run Project' one.
It's very unpredictable, sometimes it works, sometimes it doesn't (though some links are more unreliable than others). Sometimes it gets stuck in different screens. I've tested this across browsers and computers and while sometimes a new browser occasionally has a better success rate, something always gets stuck.
I'm afraid I'm probably leaving out some details so feel free to ask for them. I'm not really very familiar with Silverlight and Sketchflow, I'm just working on a prototype so it seems like I shouldn't have to deal with any code based issues...
Thanks!
You might want to look for a Click Event rather than MouseButtonDown as that could be anything, it doesnt mean MouseButton Down, MouseButton Up, which resembles a click. this is just the same as if you use your finger to touch the screen, this would also trigger the MouseButton Down Eventhandler
so if I was you try and use the Click eventhandler for your navigation.
You can open the same project in VS (including the free express editions) and run it in the debugger from there to see if an exception is being thrown. That might help narrow down the problem.
Snoop allows you to look inside the application and change element properties.
Its a great asset for developers, but can be a security issue in some cases, like when we have users who like to look in places where they shouldn't be looking. Is there a way to do something to block applications like Snoop from "snooping" your application?
And if there is no way to block it, what do you recommend to do to minimize security risks?
Snoop is a utility that allows you browse visual tree of a wpf application and view and change properties. Its very useful when you are trying to debug something and have no idea what is going on. You can find more here.
Thank you.
There actually is a way to detect whether your application is being "snooped" by the snoop program. The solution I will give is not a silver bullet, and if someone really wants to snoop your application, they'd have to modify the snoop source code (it's an open source project).
What snoop actually does is it injects an assembly into your application, and the injected assembly recursively examines your applications visual tree starting at the root. In other words, snoop actually runs inside your application. That being said, the solution is to raise an event when the snoop assembly is injected into your application.
First, you need to subscribe to the assembly-loaded event somewhere in your application (preferably the begginging):
AppDomain.CurrentDomain.AssemblyLoad += new AssemblyLoadEventHandler(CurrentDomain_AssemblyLoad);
Then, you would implement the handler somewhat like this:
void CurrentDomain_AssemblyLoad(object sender, AssemblyLoadEventArgs args)
{
if (args.LoadedAssembly.FullName.StartsWith("ManagedInjector"))
MessageBox.Show("hey you, stop snooping");//and shut down your application.
}
You would probably need to enhance this solution for real silver-bullet solution, but at least this solution will definitely stop the current latest version of snoop being run as is (without the code modified). The better solution would be to check that no external assemblies are being injected into your application.
However, Kent is still right in the fact that a utility like Snoop should not cause any security vulnerabilities since security should not be implemented at the UI level. But at least this shows you how to prevent people from "snooping" your application.
By implementing security properly. If your "security" can be thwarted with a tool like Snoop, then you're doing it wrong.
Suppose there's a command that only certain users can execute. It sounds like the only place you're enforcing this is at the UI level (by disabling the corresponding button, for example). That being the case, you're right - I could easily use Snoop to enable the button and execute the command. But you should be enforcing the security constraints on your server, or perhaps in your command execution logic if you have no server. Basically, security should be implemented as close to the thing you're trying to protect as possible. Security at the UI level is merely for convenience of the user.
Great responses for a very good question,
I want to add an example of the password that should never be saved in your datacontext, as snoop check also the datacontext of the UI, so if you use the right control PasswordBox you will find that you can’t bind the password property, that means even if you snoop the application you can’t get the password as it is not saved in any property
But we found many people who try to create a work around (helpers, behaviors, usercontrol ...) to bind the password, but they forget that snoop can get it like that
So your server should never trust your client , every time it should check the right privilege (as we can sniff the client request using Fiddler for exp then rebuild a custome request to by pass client application security)