I know something about MACROS. I don't mean the ASSEMBLY language kind. I am talking about those programs that you can use perform repetitions actions on another program. I am talking about those programs that you can use to record a series of events on your computer, like, mouse movements and button clicks and then you can play them back. Some of them are elaborate enough to run only on a paricular app that you designate.
I wrote one of sorts once. It was a program that launched an Excel sessions and then used the dynamic data exchage pipe of some kind to feed the excell session script commands. It worked.
But something on the level of the operating system, I imagine, is a whole different story.
How does someone go about writing a "macro" in C#?
I think the approach I will take is to use the spy routine that comes with the development environment to get a list of the proper messages and parameters (wm_lbuttondown for example) and then use dynamic data exchange to send those messages to the app.
So I have three questions.
Is this the best way to do this?
How do I get a handle to an app that is already running?
How do I send user-like messages to an app that is already running?
There are different answers based on many following factors:
is it 3rd party or your own
application?
does it have automation interface
GUI toolkit used in app
If it is a 3rd party app then you need to work on Windows API level via PInvoke - subclassing WinMain proc, capturing and sending input messages, etc. There are 3rd party library for that task. C# obviously is not a right choice for such task.
In case application has automation model (like Excel) it's a pretty straight forward to write program that will be interact with this app.
If it's your own application you want to enhance with macros functionality then you should take this into account on design state. If you use Command pattern from the beginning then it's not hard to program macro recording.
You should provide more details to get a better answer.
Oh, I almost forgot to answer those three questions
Is this the best way to do this?
Depends on concrete scenario
How do I get a handle to an app that is already running?
Depends on application. If it's a native Win app you can easily get process Id and window's handle via WinApi.
How do I send user-like messages to an app that is already running?
Once again it depends on application type. For native win apps you can easily send WM_XXX messages via WinAPI
Unless its something you need to add in your own program you can just download a keyboard/mouse macro program and use it to perform these repeatable actions.
On the other hand to perform macro's in your own program you would want to find a way to record the buttons clicked and write them to a temporary list that can be saved and then run the list by clicking the buttons (programmically).
Related
I am currently looking for a solution in C# how to capture window-messages like WM_MINIMIZE for another application for which I do not have any source code, for example Notepad. My goal is to prevent a user or the system from minimizing a certain application. So my basic idea is to have a process running that filters all Window-messages, and just does nothing, unless a message is posted to the application I define (for example by knowing the window-handle of the applications mainwindow), and then look if this message is a certain size-operation, like WM_MINIMIZE. Only in this case, the message should be removed from the Windows message queue.
What would be a first approach to achieve this? At the moment I am stuck a little bit at finding online resources because most topics concerning resizing deal about messages of own applications, but not to control messages posted to other, external applications running on the same computer.
Either you trap all messages of windows by creating a dll which does a global hook (in c++) (risk of slowdown the OS)
Either You have something to hook the program and in this case:
EasyHook is your friend
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.
I am developing a C# application. I am looking for a way to monitor different events in 3rd party applications.
Example 1: Calculator is running, and I want to know when the user has clicked on "=" button.
Example 2: Skype is running and I want to monitor when the user hits the "Call" button.
Example 3: Word is running and I want to monitor when the user opens the "Font" drop down list.
I am not looking for simple Mouse or Keyboard events.
Take a look at EventSpy, Both of those seams to do what you need.
http://www.codeproject.com/Articles/11918/EventSpy
http://eventspy.codeplex.com/
You basically need to tap into the "Windows Messaging" loop. In order to properly filter the GAZILLION messages that come flying through you'll also need to be able to periodically scan through all of the active windows to see which ones (if any) are relevant to you.
Be aware that this whole subsystem of windows is a GIANT security hole. (I have not worked with it much since NT4 / W95/W98 days so they might have tried attempts to "secure" it since then so it might be even harder to get to than it used to be.
You're going to need a good ide / 3rd party tools to help you get started on your way to have some idea of what you're looking for.
In a "previous" life we used this basic technique to get ~4,000 workstations to install their own software, updates, patches, etc through monitoring for existence of certain windows, controls, etc and "injecting" messages into the Windows Messaging loop to control Application Setup Programs, configuration changes that were not stored in the registry, etc, etc...
I have been looking for a way to create a simple GUI for users to stop,start,create, list running VMs in Citrix XenServer. I will create a form that has input boxes for users to put the name of the vm in, then a button to do the wanted task for that name. I would will also create a list box that will list all VM's and another that will list all running VM's. The same for all paused VM's and so on. my biggest issue is I cant find a way to run the command on the remote linux system then list the output into the area I want.
They do have Citrix XenCenter but I am wanting a GUI that will give the users limited functionality.
Apparently this question was asked some time ago, but I'll post the answer anyway. All the
Citrix XenServer operations can be performed via XML RPC. Download the XenServer SDK, it has code samples to get you started.
Moreover, SDK also provides .NET bindings, http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb/sdk.html#language_bindings-c-sharp, which means you won't have to make the XML RPC calls yourself.
Is it true that a service written in C# is unable to give visual feedback to the desktop?
I understand that services start up before user logon and at that point ther is no desktop available. My question then, apart from logging events in the system event log which is not a very efficient way of communicating to the user, what are my alternatives for showing a message box from a service?
Only two options come to mind:
MessageBox.Show - Looking around it seems this is not going to be an option.
Show a custom form
I've not given the reasons for why this messagebox needs to be shown.
Please assume that it needs to be shown as I don't want responses on "good practice". Not at this point at least.
A windows service should not perform interactions with a user. Instead you should create a seperate control or configuration application - often put into the system tray - that communicates with the service an can present information to the user or gather inputs.
See this Knowledge Base article and this MSDN article if you really want to do this. They contain some hints how to achiev this an you will probably need to use P/Invoke from C#.
Here are some ways that you can make interactive services. But, those have gone away with Vista.
One way you can have a user get information from a service is to build a separate UI for the purpose. The service could have a WCF endpoint for example and push messages out that the GUI would show. That way, you only show a message when there is a user logged in and it's not a security risk by popping up a window from the LocalSystem account. You could easily make this GUI run from the tray and pop-up toast so it is non-intrusive and begins when the user logs in. Much much better than trying to interact directly with the desktop.
I've never used it, and I include all of the disclaimers about not doing this.
However, you may want to check out the MessageBoxOptions.ServiceNotification enum.
Here's a good blog post detailing its use.