I'd like to know with a .net language(C# or VB) if I can detect when a new app is launched.
e.g: an user opens Firefox.exe from desktop (not from my app!), is it possible to detect this event from my app? Also is it possible to "pause" it before running it?
So for example when an user double-clicks an application, my app comes first and then it displays a message if he is sure to open that file with Yes and No buttons.
I don't need all code, I just need to know how to catch that event that can happen anywhere in system.
There are some Windows API functions in user32.dll that you can use in your .NET application through System.Runtime.InteropServices.DllImport to get the information you're looking for. Take a look at GetWindowThreadProcessId. For sample code, see http://www.c-sharpcorner.com/UploadFile/satisharveti/ActiveApplicationWatcher01252007024921AM/ActiveApplicationWatcher.aspx. Because applications tend to become active when they are launched, you'll find that the techniques used in that example will cause it to detect new app launches.
That doesn't answer the question about letting the user confirm whether they want to run an app, but it will get you part of the way towards what you are trying to do.
Related
I'd like to make my own custom program run on windows 10 in replacement of the start screen and logon screen.
Is there any way I can do this? I've currently replaced the accessibility program (accessible from the logon screen) with a command prompt, if I accidentally lock myself out (it has happened once!).
I recall seeing a particular Winlogon.exe. Is this my starting point? Am I able to replace the program that windows runs with my own?
Also, wrapping up, If I manage to replace this program, can I logon to windows in my program? I'm writing it in c#.
Old post, but still relevant...
I don't know if you can, or should replace it, but you could write an overlaying app to cover it and do it's own thing, if you can use a little windows command-line magic combined with node.js. More of a work-around, but then you won't chance destroying any os-specific functionality, and it seems to be universal from Vista on up (to my knowledge at least). Here is how you can get your starting point to run a GUI app on the logon screen.
Node-Windows - Run GUI app on Logon screen
You can use this technique to run any app in any language that you can open it's window from a command-line.
There will be a brief period where the normal logon screen will be visible before your app starts, but this will let you do it.
Whatever language you use for your logon GUI, you will need to send simulated key input to the real logon screen, possibly mouse-clicks-- but you can likely use simulated tabs to get to the right logon. Likely MS has API's for C# as well as a variety of related dialects to programmatically logon to the desktop in a more elegant fashion than this last part, however.
Your app will be running as the SYSTEM user (unless you specify otherwise), therefore it will be running with the highest authority-- so you can basically do anything that is possible from there. Permissions won't stop you. Be careful with this.
I am currently writing a windows store app, where I want to offer the possibility to open a specific file directly, if there is a known app to open it. Otherwise I want to hide this option.
The common way to open a file is using the Launcher.LaunchFileAsync(IStorageFile)-Method. It opens the file directly or offers a list of possible apps to open the file. So it sometimes knows about the apps to open the file and sometimes not. But is there a way to find out whether there is such an app installed or not programmatically, so that i can decide whether to hide the open button?
This isn't supported for Windows Store apps.
The general model is to "keep the user in control" which means if there isn't an app already available for file or URI association, they have the option to find one in the Store to complete the workflow. This is also there, I believe, to encourage acquisition of new apps as well.
Put another way, association launching is demand-driven, wherein the user is invited to find apps exactly at the moment they need them, rather than separately looking for apps that somehow configure the device and then enable functionality in other apps (like enabling certain file types).
In the model you suggest, wherein an app working with files hides unassociated file types, ask yourself this: how would users ever enable a file type? That is, they could see a file on their system using the file explorer (or another apps). But in your app they don't see it listed. This in itself a point of possible confusion--I can see comments in your reviews that would say "How can I get these files to appear?" Your only answer would be "Well, you have to first install some other app that can handle that file type." Customer: "How do I find those apps?" You: "Um..." because the Store app doesn't give you a way to search by association support...maybe you can get lucky with keywords.
Or, let's say the user happens to acquire some other app from the Store, or a desktop app, which means that magically those files start to appear in your app for not clear reason. Customers are bound to ask why this happened.
In short, the model you suggest could potentially create a disconnect between what's on the file system and what shows in your app, which would be hard to reconcile. I imagine that in the course of dealing with that disconnect, you'd eventually be led to create a UI in which you show unassociated file types and then invite the user to go get an app that would support them (if you could even launch the Store with that criteria). I don't know for certain, but I would guess that a number of desktop apps did this very thing, which is why Windows chose, for Store apps, to build the UI directly into the launching API.
I don't know about native RT methods to get such a data, but windows-runtime is nonetheless still Windows. So you can access the registry. And all the needed information to determine whether the file type has the associated application is contained inside the registry.
Taking into account those two considerations you can try to use this SO thread as the basis for your enabling code.
P.S.: Native RT methods would have been much better solution but, sadly, I have very fleeting experience with Win-RT. May be someone more knowledgeable can propose better native solution.
Is there anyway to find what kind of window is opened on the desktop in real time?
It may need C# or C++. What I have found right now is to use C# Process.GetProcesses() method to find the opened windows on desktop.
But the output cannot be changed when the users have opened any new windows. So, is there any method I can use to track the opening windows in real time?
Also, is there any way to track the mouse movement on a specific window by using our web service?
Many many thanks!
I do agree with tnw that this sounds sketchy (possibly an example would be useful to help here). However, you want to look at the windows api calls:
GetForeGroundWindow
GetCursorPos
The first will only give you the current window, and not all open windows, but it sounds like this is what you really want anyway?
Source code to Windows keystroke logger that does this (in C++): http://16s.us/16k/
Edit: It shows the open window the user is typing in (in real time), but not all open Windows, only the active window in use.
I keep getting multiple verification prompt from a 3rd party application where on many instances I have to select the prompt window, type my password and click on Ok. I thought of writing a simple application in WHITE framework which can capture the window, enter my password and deliver a click automatically.
I need to detect whenever a new window has popped up in Windows environment. I don't want to use either a timer or a loop. Can I get an event when ever a new window appears (registers) ?
-- Regards
Akshay Mishra
Outside of managed code you could use global WindowHooks, however this involves injecting a DLL into another process space.
This is not easily done with managed DLLs (read: assemblies). (It can be done, see here)
I wrote an article on CodeProject a while ago on how to create a sort of managed global hook for WM_CREATE and WM_DESTROY messages.
It includes full source code and it probably has what you need. Your application will need administrator privileges for this!
I'm developing a commercial Windows 7 desktop application (somewhat shrink wrap, but not quite). The application has both Windows Service and a WPF User Interface components. In the event that our application fails at a customer site we want to be able to capture information about the runtime environmnent, including a crash dump of our processes to a dump location. That information could then be forwared to our support personnel upon request for further investigation. We also want to turn off any Windows Error Reporting and Send To Microsoft dialogs that might popup as a result of the failure.
The important thing is that we only want this to affect our application processes. We don't want to affect some global setting that will change the way all other applications on the customers desktop report fatal errors.
I'm looking for some suggestions and best practices for doing this sort of thing in a shrink wrap application.
The best way I know how to do this is by subscribing to the AppDomain.CurrentDomain.UnhandledException event. There you will be able to use the Win32 API function MiniDumpWriteDump to create your own minidump file. Check out this blog post to see a good example. Also, there is the ClrDump library.
Before you exit from your UnhandledException handler, call Environment.Exit() and you shouldn't see any more Windows error dialogs.
I have not actually used these minidump libraries myself yet, but I will soon. Hopefully this answer will at least give you a few keywords that you can plug into Google.