Is there any way to prevent the systemtray from auto hiding? I have this set on the xaml but it you need to click on the area, it then shows it and then shortly afterwards it auto-hides it.
shell:SystemTray.IsVisible="true
There is no way to alter the hiding behavior of the system tray, but what data you want to display constantly?
Unfortunately there is no way to directly access the signal strength or battery life, so there is no other way to display these things to the user, but you can use the NetworkInterface class to get information about which kind of network he's connected to.
http://msdn.microsoft.com/en-us/library/microsoft.phone.net.networkinformation.networkinterface.networkinterfacetype(v=vs.92).aspx
Related
I want to detect when a window is being moved in real time and figured that CGDisplayStreamCreate etc. should provide just that. But I'm having difficulty deciding which window is being moved when my CGDisplayStreamFrameAvailableHandler is called. Is there a direct way to match the updated rects with with an app and its windows?
CGDisplayStream cannot tell you which applications/windows are responsible for a given screen update. You might be able to use another API like Accessibility to determine window locations and then guess which of the kCGDisplayStreamUpdateMovedRects corresponds to each window, but that will not be very reliable. If you're going to go the route of Accessibility, you may as well use Accessibility notifications for window move events: How can my app detect a change to another app's window?.
If you also need the pixel contents of the windows when they are moving, then you'll need to do some unfortunate time alignment between CGDisplayStream and Accessibility callbacks.
I’m writing a little Windows application which has two list-view-controls. I have set it up so that the user can tab (focus) between the two, but I need a way of visually indicating which is the active control. I don’t want to go to the trouble of messing with owner-drawn controls, so I experimented with some of the different window styles like border and client edge, but none look good. I decided to toggle the disabled property because it looks best and is easy to use.
The problem now is that I have the controls set up so that whenever the user clicks on either one, it grabs the focus (calls SetFocus(), sets a handle to itself, etc.) but of course, disabled controls don’t get event notifications like mouse clicks.
Does anyone have a suggestion on how I can retain the visual distinction of the active control and also be able to toggle the active window with the mouse?
Hans’ suggestion of using CTRLCOLOR reminded me of using that a long time ago to easily make some changes to the colors of controls which then reminded me of CustomDraw.
I decided to use CustomDraw to indicate the currently active control because it is even easier, and yet provides even better control.
I want to check for changes in the aplication state every time interval, and if it has changed, to open a window, and give the user 10 seconds to press on the window, if he does press on the window, then to allow him to navigate freely in the window, and if he doesn't press, to return back to the window before. I thought to implement it with a thread running in the background and waking up every time interval I want. Maybe there is a better way?
This strikes me as a scenario with lots of potential issues.
How do you stop the "window" appearing at an inconvenient time to the user? (e.g. when they were just about to tap on som.ething)
Why not just raise the notification when the state actually changes? This way you wouldn't need to poll.
What is the "Window" you are displaying? How does it differ from the page it is replacing? Is this a popup or are you actually navigating to a different page?
What is the state that's changing? How is it changing without user interaction?
Can't you notify the user of the state change without a potentially intrusive display of a new "window"?
I agree with #matt-lacey, this could be dangerous and might result in a bad user experience.
With that said, this might work
Deployment.Current.Dispatcher.BeginInvoke(() =>
{
//navigation code here
});
I didn't know you could do a pop-up window, could you elaborate?
I've made a thread that is running at the background and making some work, if it decides that a change is necessary, I want to give the user a chance to react to it, or ignore it.
I'm pretty new to this, so if there is a better way than to navigate to a different page i would love to hear it.
Thanks.
It sounds to me like you want to notify the user that something has happened/changed and give them the option to do something about it, which is exactly what "toast" notifcations are all about. They pop up at the top of the screen to inform the user, and then the user can tap that toast to do something, e.g. when WiFi networks are available, you tap the toast to select an available network.
The Silverlight Windows Phone Toolkit includes the ToastRequestTrigger that you use to display toast notifications. The Windows Phone Developer Guide from the patterns & practices team gives examples of using the ToastRequestTrigger. You will need to implement the tap handling yourself in the toast content, but this should be simple enough.
I'm creating an app that calls a sheet, however, the interaction with the window must stay enabled while the sheet is open. Here's a mock-up:
The user must be able to use the play and record buttons. Does anyone knows a way to keep it enabled?
This seems a slightly questionable UI. But if you really want to do it, think the only solution will be to either:
Subclass NSWindow to force handling of the events
Run the event loop for that window while the sheet is visible, and dispatch desired events yourself
Sheets are intentionally designed to block interaction with the window they're attached to. If you don't want that behavior, you shouldn't be using a sheet.
Under Windows their is something called a Windowless Control.
RichEdit
What is a Windowless Control and what are its benefits?
A Windowless control is an object that gives you the behavior of a control without requiring you to create a window.
This is useful when you want to modify or extend the behavior, or when you want to make use of the behavior in places where creating a window would be awkward or difficult.
Say, for instance, you want to imbed hundreds of rich edit controls on a page, if they were each windows, then each would have to get focus in order to get user input, and each would paint individually, etc.
But if you are willing to keep track of the locations of the windowless controls and do some other housekeeping that you would normally get for free by creating a window (i.e. routing keyboard messages), then you can get better results with lower overhead by using windowless controls.
This might be helpful.
Anon's right. It's a control that doesn't require an underlying window handle (HWND). The need for those arose especially with web browsers, since there's a limit of 10,000 max handles per process. You would open like two tabs of semi-complicated web pages and you'd run out of handles.
Working with and especially rolling your own windowless controls is hard, because at least you need to recreate their original, sometimes very complex and tricky implementation. (f.e.: IE's listbox is still windowed control because of all the tricky intricacies)
Windowless controls do not have a dedicated window handle.
in my opinion,windowless control might use less sys resource and it's easiser to customize