Is there a way to create a window (similar to a screen-saver) that will be displayed once your running application is not 'interacting' (or being idle) with the user, meaning to say, no mouse movements happening on the application.
Some of my friends suggested to use a Timer for this one. Any suggestion for a good head start? Thanks.
If your looking to create your own screensaver just create another form. Remove the border from the form. Make it the top most and start maximized. Then you just paint the control to do whatever you want.
Then wire up the form to check if the mouse moves or a key is pressed. You'll need to create a timer that will determine if the screensaver should be shown.
This might help: http://www.codeproject.com/KB/miscctrl/csharpscreensaver.aspx.
There's a similar question on StackOverflow here: How to invoke the screen saver in Windows in C#?.
Related
I've been googling a lot for this one and I can't seem to find anything. Maybe it's the way that I'm wording it. So basically what I'm looking to do in C# using Windows Forms, is create a form and have it essentially take the shape of the taskbar and do the same functions as the taskbar, but it will sit above the task bar or at the top of the screen.
It can't be "ON TOP" (I'm not trying to block user buttons like the close button of a program they are using).
Autohide would be a plus.
This is the main thing I'm after:
It needs to act just like the task bar. When you maximize any other window, the taskbar does not go over the top of the window, even though it is set to "on top".
You'll want to use an Appbar to do this:
http://msdn.microsoft.com/en-us/library/cc144177.aspx
For more information, check out here and here and here.
If you don't want to deal with C++ and Native Code (as #FKunecke correctly proposed) then you'll not find anything predefined for this. What you can do is create a form for your bar and make the visualization calculations by hand, then you can set the screen location of it. That's all. Not forcing the bar form to stay on top will not hide the other app forms so you'll get that for free.
Now, to fully implement what you want there are some problems you need to deal with, such as Taskbar location and height. Then you'll need to use some native code tricks.
I am currently working on a desktop C# WPF application where the goal is to make it look and feel like a "real" Windows Store App.
I want to add an appbar that should be shown when the user swipes up from the bottom. To do this in a normal app you just position your finger outside the screen area, and swipe up.
But if I do that in a fullscreen WPF program I don't receive any TouchDown or TouchMove events - probably because the finger is already down when entering the actual screen area.
I have tried with the Manipulation framework also, but same result here. Even when I hook directly into the message queue using WndProc or other hooks I get no events at all.
The funny thing is that I can see the "touch cursor" move around the screen, so at least something in the underlying framework is notified.
Does anyone have an idea how to do this?
p.s. It is not an option for me just to use a windows store app instead, because of hardware connectivity issues ;-)
You will need to keep track of the cursor location coordinates, and see when the cursor (swipe) starts at the edge of the screen and moves in. When that triggers (with whatever trigger you want, distance covered most likely) you can fire up your Appbar.
There was a similar question asked on MSDN:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/d85dcde7-839a-44d3-9f2a-8b47b947576c/swipe-gesture-and-page-change?forum=wpf
I need to create a application which is similar to those we will get when we buy a laptop. It will be visible only when the mouse pointer reaches the top of the window. So how can I able to do this using C# 4.0 ?
http://www.notebookcheck.net/uploads/pics/win2_12.jpg
this link u can see the application. I need to create such type
Any idea pls share. Thanks
I suppose there are several different ways to achieve this effect:
You can place part of the window of your application above the visible screen, so only a part of it is visible (let's say you can see only it's bottom). Then you need to handle events when mouse enters (MouseEnter) and leaves (MouseLeave) the form to move the form up and down.
You can use a background thread to call GetCursorPos method at a set interval (i.e. each 500ms) second to check where currently the mouse is. See this link for more information about it and a sample code: http://www.pinvoke.net/default.aspx/user32.getcursorpos.
(If you need only to check the mouse position, you can use a timer to simplify you application.)
When you hit what's possible with C#, you can always start invoking native code - such as the windows API. Since you don't ask a specific question, I'll leave you with:
Position your app where you want it to appear and hide it.
Capture mouse position with windows api (see this SO answer)
When mouse is at screen corner / top, etc; make your app visible.
Now make sure all this works with dual screen setup, and you are done.
OK, anyone can explain how Jing take screen shots with that overlay form? It appears that it take a full screen shot and records all visible window handles and let you select within the form a specific hwnd. could be true? if is, what are the big steps to achieve this? could be a simple picturebox or without a custom control i don't have a chance to freeze the screen while taking a screen shot?
Thank you!
I'm not familiar enough with Jing to know exactly what it uses. But there are two basic techniques. One is as you mention, capture the screen and display it in a topmost borderless form. The Vista/Win7 Snipping tool works that way. You'll find the code you need to get this started it in my answer in this thread.
The other, perhaps more likely to be used by Jing, is similar to what Spy++ does, allowing the user to move the mouse and draw a selection rectangle around the window. Its advantage is that it can deal with windows resizing or disappearing while you've got the tool running. You implement it by using a topmost form the size of the screen that has its TransparencyKey property set to the value of the BackColor. Fuchsia is a popular choice. You can draw on this form with the OnPaint() method, the drawing appears on top of all the windows. You'd need some P/Invoke (GetWindow) to iterate the underlying windows in their Z-order to know which window the user is pointing at. GetWindowRect() to get the window rectangle. Plus some hassle to deal with Aero lying about the border size.
You can find sample code to get you started on that technique in my answer in this thread.
I have a WinForms app that is retrieving data from a web service on a worker thread and I need to disable all input to my app until the data is loaded.
Currently, I create a semi-transparent form and place it over my application. When the data call completes I close this overlay form. This works fine accept that it causes considerable performance problems for users running the application over terminal services. I tried making the overlay entirely transparent but that still triggers two redraws of the entire window so this did not help at all.
I know that a common recommendation for handling this is to disable all the controls, but that would also redraw much of the screen so I'm looking for another way to block all user input. Any assistance would be greatly appreciated!
UPDATE: I should have mentioned that we have considered the modal dialog. Currently we show the overlay, start the data access thread then construct the form. If there is no better way to block input (App.BlockInput() might be nice) then we could use the modal dialog idea, but we would need to wait until the form construction had completed and there isn't currently a nice, central location to do this.
You could display a small modal (modalForm.ShowDialog(yourForm)) form with progress bar rolling on top of your app. This won't cause big areas to be redrawed.
If your app really is blocked while the operation is running, I'd do what Microsoft frequently does: open a modal dialog box with some kind of throbber animation or ProgressBar, and a Cancel button. Redraw is limited because you're only drawing the size of the new dialog, and input to the rest of your application is blocked because the dialog is modal. Also, users are much more willing to wait when you have some kind of status updates and or animation, because it looks like the computer is "working".
However, if there are operations your user can do while your web service request is running, it's better to leave the controls accessible. At very least, there should always be a way to interrupt/abort the process.
Update: Since you now changed the question: How long is it taking to construct the modal dialog? Why not simply construct the dialog empty, and then populate its controls? If all you have is a small dialog box with a single button and a single ProgressBar, then calling dialog.ShowDialog() should happen faster than your user can interact with your UI. Is that not the case?
One thing you could try for keyboard input is setting the KeyPreview property of the form to True. This will pass all keyboard events to the Form object first instead of to the individual controls. Create an event handler for the KeyPress event of the form and in there you can set the Handled property of the KeyPressEventArgs to True to prevent the key stroke from being passed to any of the controls. If you're currently retrieving data from the web service, set the Handled property True otherwise set it to False and the key stroke will be passed to the controls.
If someone has a good idea on how to handle the mouse input yet you're set.
I'd typically create a LockUI() and UnlockUI() functions in my form that toggle controls and flip a local form field that acts a flag to indicate a long running process. This approach works really well if you use a command pattern.
As previously mentioned, you could toggle keyboard input by using the KeyPreview property of the form (as suggested by TLiebe).
As far as mouse input is concerned, you could disable mouse activity by hooking the WinProc messages and intercepting mouse input messages. This is basically what KeyPreview does.