I have an idea to write a multimotor taskbar application in c# for windows xp. So, does anyone have any information how
to put a taskbar on the second
monitor,
to make it use windows styles,
to prevent aplications running on the
second monitor to appear in default
taskbar,
so on...
Any help would be ...helpful )))
You can P/Invoke SHAppBarMessage() to create a task bar. The APPBARDATA.hWnd you'll need could simply be the Handle of a Form class. Anything goes as far as what you display.
Getting the notifications you'll need to make the task bar display active windows is going to be a whole lot more difficult. You'll need to use the global WH_SHELL hook, set by SetWindowsHookEx() to receive the notifications you'll need. You cannot set this hook in C#, it requires an unmanaged DLL that you can inject into a process. You'll find crucial help in this project.
Getting the Windows taskbar to not do its normal job is going to be impossible unless you somehow find the undocumented information you'll need. Microsoft doesn't document this for a good reason, the taskbar is an important part of the way they innovate on the Windows look-and-feel. Quite visible in Win7. They don't want any code to take a dependency on this, they'd have a near-impossible job of keeping the next version of Windows compatible. I'd have to recommend you completely disable the Windows taskbar and replace it by your own.
Related
I have an application that uses a low level keyboard hook to capture the user's choice of keyboard shortcuts at a global level to activate the application's main window. Because I want to allow sometimes "odd" shortcuts, like F12 or Ctrl+Ctrl (double tap), I use the hook instead of the RegisterHotkey API function. Until Windows 8, this feature worked great. In Windows 8, some windows prevent my application from receiving the event but only while those windows are in the foreground. The Windows 8 Task Manager is one such offender.
Note that, because the problem only occurs while the offending window is in the foreground, I know that my hook is still registered with the system, just temporarily not reaching my application.
The current code base is C# Framework 4.0; however, I tested the previous code base, which was unmanaged C++ and the problem is the same.
Version of Windows is 8.1 Pro with Media Center
One thing I have not yet tried is moving the hook procedure to a separate DLL. I think I read that the low level keyboard hook procedure must be in a DLL but I have never found this to be true. Before I go to the trouble of trying that, I wanted to ask whether I am missing something easier and more obvious.
Now I understand. Although my application runs under a Windows account that is in the Administrators group, it needs to be launched with "Run as Administrator" in order to avoid being blocked by UIPI.
The solution, at least for me, is to ask a Windows 8 end user to launch my application as Administrator, if s/he wants to use "fancy" global keyboard shortcuts like the ones I mention in the question. (I also allow the user to use "simple" shortcuts, which are implemented with RegisterHotkey() instead of with WH_KEYBOARD_LL and therefore do not suffer from UIPI.)
Say I have started application on Windows (created in WPF for .NET in case that would help), that opens some windows/panels and just runs in a background. User don't want to interact with it constantly, however once in a while needs to urgently execute some actions in it.
Is it possible to bind some key shortcut e.g. alt+key to running application, so on hitting it app gets focus? It doesn't necessarily need to be brought to front, altough that would be nice as well.
"a hotkey that works out of your application" is this what you want?
if so, you need global hotkey that i can reference to!
(Sorry i didn't have enough reputation for commenting!)
I think I found sort of semi-solution, that doesn't need any coding or changing any system settings, but only:
1) keyboard with Windows key
2) possibly forcing user to re-arrange icons on his task bar (or pin my application as one of first 9 applications on his taskbar)
pressing WinKey+digit brings up digit'th application from the taskbar. Pressing it again hides it.
This works for Windows 7.
Obiously doing this way is a bit lame and not customizable at all, but it's always something... Still happy to find better way if there exists such.
I've got an issue with the focus management in WinRT. The issue is specific for the application startup. Let me share the example of it:
If during the startup I change the focus (for instance I can start selecting some text in a browser), the runtime will decide that it doesn't need to show the application. The application is being started in a 'hidden mode'. It means that I do not see the UI, but I still can find it in process explorer.
So what I need here is to make the application be active in all possible cases. I tried to use several native functions such as ShowWindow, SetActiveWindow, SetForegroundWindow, but without any success.
I also noticed that any WinRT app is being started under WWAHOST.exe and mainwindowhandle is 0. The app shows up if I use 'Switch to' option in Process Explorer context menu.
WinRT applications are sandboxed and have very little control on the way the OS handles them, and almost no way to affect the behavior of other applications running on the same host. What I would suggest then is for you to design your application in such a way that it shows some UI as early as possible, then asynchronously you can load any other resources that your application may need.
Anyone know of an efficient way of detecting movement of any windows currently open on a windows system? I need to detect a window's movement, determine if it collides with my applications Form, and bump it out from underneath if necessary.
I know I can scan through an enumerated list and check each window -- but that is way to intensive to perform constantly.
Background:
I have a taskbar-esque application that docks on the side of a user's screen. When the "Always on Top" feature is on, maximized windows will take up the remaining available space without covering the toolbar, as expected.
However, if you drag a non-maximized window over the toolbar, the application goes behind the toolbar (also expected), but you can no longer grab onto the title bar to move it back -- the window is stuck unless you disable "Always on Top" and then move it. So, I want to bump the window out from underneath.
Although not a direct answer, one possible solution to this is to create your application as an application desktop toolbar rather than a regular window. From the docs:
An application desktop toolbar(also called an appbar) is a window that is similar to the Microsoft Windows taskbar. It is anchored to an edge of the screen... The system prevents other applications from using the desktop area occupied by an appbar. (emphasis added)
This may not be a great fit for your scenario because it is oriented towards COM and unmanaged code rather than managed apps: however see this CodeProject article for info about using this feature from C#.
Failing that, you could try installing a hook (see SetWindowsHookEx) and listening for move messages but this is pretty low-level...
Try checking your PaintEventArgs ClipRectangle ..
(edit: and/or WindowFromPoint shooting match)
You can get notification of window movements using a CBT Hook: http://msdn.microsoft.com/en-us/library/ms644977(VS.85).aspx
http://www.codeproject.com/KB/dialog/FindWindow.aspx?msg=3262771
"FindWindow By Jörg Bausch"
Will get you the external (not your app's) window ID (IntPtr) the mouse went up over from within your C# application. For the desktop, and everything else on the desktop, it will return the same pointer (you can't distinguish, using this code, between as mouse-up on a folder, the desktop, the Recycle Bin).
http://www.codeproject.com/KB/cs/globalhook.aspx
"Processing Global Mouse and Keyboard Hooks in C# By George Mamaladze"
Will allow you to create GlobalHook for keyboard and mouse-events in C#. I've used it recently in VS 2010 beta 2 : it is NOT USABLE compiled against FrameWork 4.0, but does compile and work okay against FrameWork 3.5 and lower. If you download only George's demo app, be aware the download doesn't include the required dll, and will fail when you launch the .exe file (which I have brought to George's attention).
I've never worked with a "desktop application toolbar;" I hope this is relevant.
best,
Is there a way to build a C# wrapper for an existing application that will allow me to remove it from the taskbar?
More info:
I have an timer app that I suppose to use but don't because it well... sucks. See https://superuser.com/questions/92774/quickbooks-timer-replacement-windows.
So to make it suck less I wonder if I can build a wrapper then just interact with that wrapper instead. Removing the timer from the taskbar and then having my app hid/show it would be a step in that direction.
The other option is to reverse engineer the timer. But that is another project for another day. Right now I would be happy with hiding the thing.
You would need to locate the window that is being represented in the taskbar, and remove the "show in taskbar" bit from its (extended) style. This will involve dropping down to the Windows API level. The functions you will need are:
GetWindowLongPtr - to retrieve the existing extended style (GWL_EXSTYLE)
SetWindowLongPtr - to set the new existing extended style (GWL_EXSTYLE)
The extended style bit you need to remove is WS_EX_APPWINDOW.
Please see the SetWindowLongPtr docs for info about restrictions on the use of SetWindowLongPtr to affect windows in other threads, and potentially needing to call SetWindowPos to cause a visual update. Windows may even prevent you from doing this altogether (e.g. for security or usability reasons)
I haven't tested this and it may depend on the target application. Finally, if this does work it will remove the window from the taskbar altogether, which may be confusing when you re-show the window, so your app may want to re-enable the WS_EX_APPWINDOW style before showing the other app's window.