I think that is what this is called:
I want to be able to add stuff like that to my program. Such as an open button and other buttons that would execute a method within the app. This is in C#, by the way.
I DID look into the Windows 7 API Code Pack, but it.. doesn't work the way I want. It won't let me execute a method inside my app like I want. It just lets you open other apps.
Is something like this possible?
I think its you who doesnt understand how JumpLists work.
"It just lets you open other apps" Is exactly what it does, nothing else. Thats Windows 7 feature, not API Code Pack limitation. Key point to this is fact, that your application is not running, so WHERE it should execute your method?
Correct implementation would be to make your JumpList run your application with correct parameters and then inside your application Main method invoke different methods depending on those parameters.
Dont forget, even window applications have input parameters, just like console apps.
If you look at Outlook and Messenger, they invoke other commands within the app, so you know it is possible. But as #Euphoric says, the architecture of jumplists is really simple - choosing a destination (eg a file name or URL) results in Windows launching another instance of the app and passing that destination as a command line argument. Choosing a task results in Windows launching that task, which needs to be some other exe.
How to resolve this seeming paradox? The other exe is a helper exe that communicates with the main app. Examples of this are in short supply but I am working on a demo for an early November talk, and will blog it when I have it done. Perhaps this architectural pointer will get you started.
Assign URLs to the jump list items and use an HTTP listener to invoke methods upon your application. Like this URL mapping with C# HttpListener
Additionally, you can go the awekward route and use a shared mutex to make your application single instance only and forward command line arguments across a named pipe. But the http listener is nicer ;)
Related
I want to make a GUI Windows application that can run console applications. When this happens, the console window should not be shown. Instead its content should be shown in a visual component (memo/richedit). This component should show exactly the same content which would appear in the console window, even the color of the text and its background should be displayed. So this visual component should work exactly as a console window. I know that the standard output can be captured but many console applications do not use it. Is it possible to capture the output of a console application this way? Are there Windows API calls that can handle this?
I use Delphi XE2 but C# code would also be helpful.
You have to run the console mode program with stdout redirection to a pipe that your Delphi program will create. Your Delphi program can read the pipe to get the console mode program output and do whatever it needs to. By the way, this works not only with Delphi but also with any language able to create pipe and run program with I/O redirection.
If you need Delphi code to do that, have a look at this reference.
There is a ready-to-run component on GitHub: DosCommand
The Demo shows two ways how to do what you describe.
I am not sure if it works for older versions like XE2, but at least you can give it a try.
Traditionally you would call CreateProcess with stdin/stdout set to pipes you created. This should work for most programs but not for anything that uses a ncurses style "GUI" and you also lose the color information. An example can be found on MSDN.
Windows 10 (1809?) added support for pseudoconsoles. This is used by the new Terminal application and is your best bet for full console compatibility.
The last alternative is to inject into the child process and hook WriteFile, ReadFile and all the console functions but this is ugly and error-prone.
I have a C# console application program running on windows server anytime.
On the same machine I have zend server and apache running.
It is possible to send a command to the running C# program directly from the PHP without having an endless loop on the C# program that taking the info from outsourced files?
For example, the command "/init" would initialize all the variables on the C# program.
Can I write a init.php file to send the "/init" command to the running C# windows application?
This will be in order to initialize all the variables on the running "Program.exe" by opening the URL "http://example.com/init.php".
Thanks in advance.
There is a number of approache for IPC.
As I understand it, you want to do that without a loop. The thing is: You have to have a loop anyway to keep the console application alive. The programm is staretd. Executes all code. And then ends. You could block it via stuff like ReadKey(), but then it would not be able to process anything.
Unfortunately all approaches to IPC I know either require a loop. Or a GUI that already has a loop - the EventQueue. You will not get around some multitasking, and for that alone I always advise a GUI application.
It is also pretty unclear what data you actually want to send and what that application doe with that data. Depending on those requirements, it might be possible to just do this via commandline parameters.
However the biggest issue might be rights. Web Servers are notoriously vulnerable to hacking, being online 24/7/365. As a result, they are usually run under the most restrictive user rights imaginable. Read access to it's content and programm folder is the only thing you can asume. Reading anywhere else, writing or even Execution is not usually on the list of things it can do. And will raise some eyebrows from the admin too.
What I thought would be pretty easy is quickly defeating me. I'm not a native C# programmer, but was asked to create a WinForm application that has a single instance. I''ve seen the Mutex examples already on StackOverflow, but the one thing that eludes me is the ability to pass parameters to window on the command line, parse the values and repaint the form with the new values.
Anyone have an example of this? The main thing that seems to be tripping me up is the threading. I want to run my.exe and show the window. Each time the form is run, I don't want a new form -- just to get the new parameters and show them in the form.
Any/All replies are appreciated!
When you starting another instance of your application, you are running same code, but on different process. So, you need to look on passing data between processes. Something like Named Pipes or Remoting.
#lazyberezovsky is right. Invoking again the application from the command line will spawn a different, unrelated process and you would require inter-process communication to forward the new parameters to the previously running app instance, before quitting the new process being invoked.
IMHO, the easiest way (not the best certainly) to communicate between these two processes would be using the Windows Registry, as this is already thread-safe and the API is very simple.
First, when the application runs, before showing the main form, I would perform a check to see if another instance of the app is running.
If false, it is the first time the app runs and I would process the command line and show the form as regular. I would also clear the registry key used for inter-process communication (see below).
If true, then I would store the command line in the registry on a specific key that will serve for inter-process communication and then I would terminate the application without even showing the main form.
Your running application (the first instance) will require to start a polling mechanism (could be a Windows timer firing once each second) that regularly examines the registry key where a new command line is expected . It would normally find and empty string and do nothing, but if the retrieved value is not empty, then it would mean the user spawned again the application with a different set of parameters, then you can proceed to decode your command line and repaint the window as necessary. After this, make sure you clear the registry entry again, so the polling mechanism resumes and detects the next time the application is invoked by the user.
Named pipes, WCF, .remoting or TCP sockets are IPC mechanisms that can be used and won't require a polling mechanism, that may be frowned upon by some. ;)
Hope this helps!
I have a C# Console app than runs a pre-build step (to get NuGet Packages).
When I am debugging this, I want to pass in a parameter and show the console. When I am not debugging it I don't want to see it. I don't even want it to flash up there for a second.
I have found ways to hide it, after it has shown. But I can't find a way to never make it show unless I am willing to change it from a console app to a Windows app. (Which I would do if I could then find a way to show the Console when needed.)
Build as a Windows application and show the console when you need it. To show the console when needed use P/Invoke to call AllocConsole (pinvoke.net has the declaration you need).
(Console sub-system processes always get a console, their parent process's if there was one, otherwise a new one. This is the way Windows works at a deep level.)
Use FreeConsole WINAPI function:
http://pinvoke.net/default.aspx/kernel32/FreeConsole.html
Another solution is to simply switch to a WinForms application as project type. No console will be allocated then (and you do not need to show a form).
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).