I'm working on a docking project, in which I need my form to dock itself into a window that doesn't belong to my application. I have no problem detecting the location of the window, however I haven't got a clue on how to intercept the event of movement of the window. Does anyone know how can I intercept the event of movement of a window?
Maybe this post will give you some clues.
An alternative way (but not very nice) would be to have a timer that fires every 500 milisecs and checks each time for window position and compare with the previous one. Then if different adjust your window accordingly.
Listening for window messages requires injecting code in the process whose window you want to dock to. You cannot inject C# code, you can't reliably get the CLR initialized in that process. You'll only have a fighting chance if you use native code. Google EasyHook. Black belt Win32 API skills are required to bring this to a good end.
Related
My app screencaptures another window that runs on a second monitor. Now I'd also like to forward mouse clicks made in my app to that window. I tried using SendMessage in user32.dll for this, but this also makes window focus switch, which causes some issues, like the two windows rapidly fighting for focus. Is there are way to place those mouse events without making the hidden window active and losing focus on the main app?
Is there are way to place those mouse events without making the hidden window active and losing focus on the main app?
No, there is not even a way to forward mouse input to another receiver. Messages are only part of the input processing. The system also does internal bookkeeping and you cannot replicate that.
The only reliable way to inject input is by calling SendInput. Doing so doesn't allow you to specify a receiver. Input goes to whichever thread is determined to be the receiver by the system.
Although, more often than not, this question is asked when the problem that needs to be solved is a different one altogether: How do you automate a UI? The answer to that question is UI Automation.
So I have tried searching for the better part of a day for the answer to a simple question. I want my C# application to popup another winform on a timer and then close it after a delay. Simple enough, done and done. Now my issue is that I want it to actually be on top of other applications UNLESS they are full screen. By that I mean a true full screen application such as a game. I do not want to interfere with such an application since it should take priority over my application.
The issue is that I am using the 'OnTop' property on the popup form and, while it works perfectly for any other applications I have been testing it while playing a full screen game and the form, when it "Show()"s, takes the full screen application and drops it into windowed mode.
Is this the intended effect of the 'OnTop' property with full screen applications? If so is there a way that I can have my form popup on top of normal windowed windows and not interfere with full screen applications?
Any links, example, a kick in the general direction is great. The only hits that I come up with when searching for winforms involving full screen is people trying to get their application into full screen or having their application take focus away from another application.
Thanks on advance.
(I didn't post any code due to it just being a simple winform that is "formX:Show()" on a timer with the "onTop" property set)
(EDIT) So thanks to awilson53 for putting me on the right track I was able to find a method (albeit somewhat picky) to determine if an application is full screen. Seems kinda simple, and an "well duh", answer after all is said and done.
95% of the credit goes to the author of the article: http://www.richard-banks.org/2007/09/how-to-detect-if-another-application-is.html
~5% goes to awilson53 for getting me on the right track. :)
Check out this wrapper for the EnumWindows function. This will allow you to enumerate all open windows and determine their window state. You will want to check the EnumWindowItem.Maximized property, and if it is true set your OnTop property to false. If none of the EnumWindowItem's return Maximised you can set OnTop to true.
We have a C# .NET 3.5 UI client application that runs in a multiple monitor desktop environment (typically 4 screens) on Windows 7. Every so often, after running several of these applications, the screen stops redrawing.
Controls continue to be reactive to clicks or keypress and values can be updated programmatically, but the entire form is not redrawn to reflect any changes. For example buttons that are enabled/disabled based on state may be remain grayed out, but be reactive to clicks or vice versa. Buttons do not animate when clicked.
Workaround: minimizing and restoring the window appears to clear the problem. After this, the application begins to draw correctly.
The must frustrating aspect of this problem is that programmatically, everything appears to be running normally. No exceptions are caught in our logs. Nothing was visible in the system event logs. We have not found a way to detect this condition is happening yet.
Other miscellaneous aspects: logging uses log4net, server communication layer uses ZMQ
Update:
Calling form Invalidate() and Update() does not fix the problem.
When dragging the window between screens, it shows different values on each screen.
Minimize/restore still resolves the issue.
I can't be sure of anything without seeing the app and the code, but my best guess is someone calls .SuspendLayout() before a complicated update, and an exception (probably swallowed) prevents the code from ever reaching the corresponding .ResumeLayout(). To test this, try adding a button that calls .ResumeLayout() for the form.
It seems the solution is there:
1) http://blogs.msdn.com/b/alejacma/archive/2009/08/11/controls-won-t-get-resized-once-the-nesting-hierarchy-of-windows-exceeds-a-certain-depth-x64.aspx
2) http://support.microsoft.com/kb/2664641/en-us
This may be a long short or not even possible but no harm in asking.
What I am trying to do is monitor an application for any new windows it creates in its MDI control. I have implemented hooking in C# and can capture the MDICREATE window message but because I need to get information about the window after is has been created the MDICREATE message isn't much help because at that stage the window hasn't been created in the other application yet.
Without going into to much detail I just need to be able to see when a new window has been created.
Is this possible?
Thanks
I'm not aware of another message that gets the info that you are looking for off hand. But if that message works for you, you could hook that message and then do another scan of the windows to find the one you are missing. You can enumerate the child windows of the parent window. Use Spy++ to see the exact window hierarchy.
If you can watch for a particular function call, I would use some kind of hooking library to grab that (EasyHook comes to mind).
You can hook the MDI create function (assuming there is one), watch for that, then inn your code, call the original and do any lookups using the returned value. You'll have access to the returned value and any parameters, so you should be able to get some info out of those.
Two options off the top of my head.
Hook the WM_MDIACTIVATE event, the first time the window is being activated, use a flag to determine the first time the window is being activated.
If you need to run your code after the WM_MDICREATE or WM_MDIACTIVATE, you can post a new custom message from one of these messages, which is then handled after these messages have completed. You then write your code to handle the custom message.
I want to create an alarm app for myself. On certain conditions (i need to poll websites) i want my app to inform me and make it HARD TO MISS. So i can take appropriate action or ignore it if i need to do something else.
I wrote a test app and using a BalloonTip (ShowBalloonTip with notifyIcon) isnt great. One of my previous apps brings the window in front of you and does a MessageBox however that doesnt always work or work well (if i somehow miss it or accidentally forget to click ok no futher messages will occur).
What are your suggestions?
You could also make it a system tray application and change the icon out if there is something which requires attention, a la a messenger application. That may not be "hard to miss" but I am trained (for better or worse) to look down at the icon tray when I see something blinking.
Where I work, we have a TimeTracker application (built in house) with which developers are supposed to log what we worked on and when. I am notorious for not using it. So, I wrote my own (Windows Forms) version for my own use which, every hour opens up and takes over my screen:
It is a frameless dialog which consumes the entire screen.
TopMost = True.
On resize, it sets WindowsState = Normal and resizes to fill the screen.
While it is open, it polls for taskmgr.exe and procexp.exe and kills them if found.
It disables the start menu to prevent cmd.exe commands from the menu in Windows 7.
The only way to close it is to enter a log, only then is the OK button shown!
So far, it's working out well - no one has been able to break it!
My less drastic suggestion would be to have a notification which pops up momentarily above the system tray. After a second or two, fade it out. Keep showing the notification every 30 seconds or so until it is dismissed.
Always-on-top window in the corner of the screen?
You could always set your window to be a top most window, make it full screen, and activate it. It would be very, very hard to miss...
Granted, it would also be very annoying, and not something I'd do to other users...
My "real" suggestion would be to use sound along with standard notification methods if this is going to be used by other people, as that's an easy way to grab attention without necessarily killing their workflow. A modeless window that appears in a corner of the screen, especially if combined with sound and color, can be very effective to grab attention.
The industry has been adopting these ambient orb devices and variations of it when such a hard-to-miss notification is required. It is used for tracking the stock-market and for broken-daily-builds.
http://www.ambientdevices.com/cat/orb/MAN_Ambient%20Orb_3-23-03.pdf
Regards