Using WinForms application, I would like it to show some help (when asked && started from console). In Main, I use kernel32's AttachConsole(-1), write some info using standard Console.WriteXXX(...) and then kernel32's FreeConsole().
Problem:
After the application exits, the standard console prompt (the current directory) is not restored, the cursor stays blinking on last line (written by the application). After pressing the Enter key, the prompt is restored. It seems like the application waits until the key is pressed, but it does not, because any key press is interpreted already by the console.
Any tips what I'm doing wrong?
Related
I am writing a program to automate some work for me.
I have another program (OBS Studio) installed, which I use to capture video. OBS Studio is minimized to the system tray and listens to my configured hotkey CTRL + 1.
When I press CTRL + 1 anywhere, the software starts recording. It does not matter which application is in the foreground.
I am trying to do the same thing from my application, send a "global" hotkey. I have spend hours trying to achieve this, but without any result. SendKeys only works for the current open window (which does not exist), no results with PostMessage either and I tried the wrapper "InputSimulator"
So, to summarize:
Is it possible to send a hotkey/keystroke globally (for every application?)
If not, how would I send a hotkey to a program that is running in the background, without a window? I don't want to bring the app to the foreground.
Hopefully someone with a deeper understanding of these concepts can guide me...
I've found similar questions, but they remain unanswered:
Send global keystroke / fake a global hotkey from a Winforms application
Sources I studied (among others):
https://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys(v=vs.110).aspx
https://dailyoverdose.wordpress.com/2009/10/28/postmessage-and-sendmessage/
https://ourcodeworld.com/articles/read/520/simulating-keypress-in-the-right-way-using-inputsimulator-with-csharp-in-winforms
Ok, so in my c# console application it starts somewhat similar to this
static void Main()
{
OpenLoginForm();
}
OpenLoginForm()
{
while(true)
{
//This breaks when user has logged in
}
}
Anything that a user tries to type in the console WILL NOT output to the console UNTIL OpenLoginForm() has stopped running, the problem is, that when OpenLoginForm() STOPS running any text that the user tried to type into the console BEFORE OpenLoginForm() stopped running will output to the console AFTER OpenLoginForm() has stopped running even though while OpenLoginForm() was running the text DIDN'T output to the console. I need it so even if a user types in the console when OpenLoginForm() is running, the text the user tries to input will not output even when OpenLoginForm() stops running.
Here is a gif that shows me typing into the console when OpenLoginForm() is running, but you will be able to see when OpenLoginForm() stops running the text i tried to type then gets outputted even though this is what I'm trying to prevent.
Hopefully i worded this question in a way some of you will understand, I'm new to c# (I'm sure you can tell).
The thing is that everything here is being run on the same thread, so while the console window is open, nothing appears in the console. However, the console input buffer is still filling with keystrokes.
You should be able to address this by clearing the input buffer, as described in this question. It is based on using Console.ReadKey(true) which (somewhat counter-intuitively) causes the input key to not appear in the console window (false will allow to appear). You then just throw the input away.
Here's the MSDN article on Console.ReadKey(bool).
This is an issue with threads. Basically the input buffer for the console is active wgile the output is disabled. When you box closes then the output buffer for the console is turned on and the input buffer is flushed to the output buffer.
The simplest solution is to use multiple threads. The main thread which will run the console and a child thread which will run the login box. Also as a child if the console is closed it will close the child
I found no solution/answer to this.
private void LogToConsole(EventLog eventLog)
{
var type = TypeToStringOfUniFormLength(eventLog.Type);
Console.WriteLine($"# {type} {eventLog.Message}");
}
This i my "Event-Logger" and i have a very special behaviour. Most of time it's works great. My Console (in console-application) is updated, but sometimes it just stops at the line "Console.Writeline...". The Console is not updated and the execution pauses there. When i click in the console and hit Enter. The Console is updated an the execution continues. There is no specific scenario to reproduce. Is anybody familiar with this error, or even has a solution to this. My next work arround is to just not use a console-app for this.
thank you for your help in advance.
Windows 10 console automatically enters the Mark/Selection mode when you click it(no need to right-click->Mark, like it is with earlier windows consoles).
This is what prevents the application from printing anything, but the application actually continues to work:
The application itself keeps running, but nothing is written to the
screen.
Then
When you exit the selection mode, the process will resume as normal.
If it is not the case, then you will have to debug/dump your application to determine the culprit.
I just wrote a clever program called helloworld. It's a C#/.NET 4.5 console app. Deep within the twisted nested mazes of logic there's use of Console.WriteLine().
When I'm running this at a command line, it runs and I see the output. I can do other commands and mess around a bit, and later scroll up to see the output again.
Now I'm in Visual Studio, tweaking the source ("Hi" is more efficient than "Hello") and testing by tapping F5. What happens is a console window pops up and immediately vanishes. I have no idea what the program printed. How can I see the output?
I don't want to modify my source at all. After searching for solutions, I find some who say to use Console.ReadKey() - but then it would suck to be using the program at the command line. There's no real reason the user should have to tap a key when the program has already done its work. Even if i go with this, there's the problem of the output disappearing when the console window closes after a key tap.
I don't want to use Debug.WriteLine() which does write to the output window in VS, but doesn't write ordinary output for the end user to see.
I have discovered ctrl-F5, which runs the program as if it had a final Console.ReadKey() line, but there's still the problem of when I tap any key, all the output vanishes along with the window. Three minutes later, I'm thinking "Oh wait, did it print 'Hello' or 'Helo'?" No way to check.
Seems like the Visual Studio IDE should somehow capture all that a freshly built program writes to its stdout or the Microsoft equivalent thereof, and show it in its "Output" panel, or some panel, for later scrutiny. Maybe it does do this, and I don't yet know the trick to it? Seems like this would be a common desire among millions of C# developers.
If you're working on a .NET Core console application (or .NET Framework via the .NET SDK) using Visual Studio 2019, the behaviour of leaving the console window open after the program has executed will now happen by default:
Specifically:
This should prevent the need to add Console.Read() calls to console apps to prevent the console window from closing immediately after the program has finished executing. The launched console window is also re-used for subsequent runs, so if you’re used to using ctrl+f5, you won’t have lots of console windows to close after you’ve launched your application a few times.
The reason it closes automaticly is because it's done running the program. If you want to see what it did, make it need a new command like hitting any key. The Console.ReadKey(); pauses it and waits for a User to hit a key to continue. Put that command after the commands of instruction you are doing and it will pause it until you hit any key.
Console.ReadKey(); // Pauses until you hit any key
You can also run your program pressing F10 (executes one line by one), with F11 (goes inside a function).
The other option you have is to set breakpoints in Visual Studion and run the program by pressing F5 - it will stop at the next breakpoint. And the breakpoints can have conditions - i.e. conditional breakpoints.
Some options are:
1. wrap #if DEBUG around Console.ReadKey()
2. run directly from an open terminal
3. create a Test project - but again you'll need Console.ReadKey() to stop it closing.
I'm working a small WPF based program for launching applications through system wide hotkeys implemented using hooking. I'm implementing it in C# and Visual Studio 2010.
When I detect the specific keypress I use Process.Start(...) to run the application. This works fine while Visual Studio is active, placing the new application in the foreground with input focus, as I would expect. If my launcher is in the background (behind another active program), it still detects the key and starts the application correctly, in front of everything else.
The problem is, that when I run the launcher without Visual Studio active, and my launcher application isn't front, neither will applications it starts. They appear in front of the launcher but behind the active application.
I can see that other software, like AutoHotkey, is able to do hotkey launching with this behavior, but I fail to see what I'm doing wrong.
Update: Just figured out a solution to this issue that works in my development environment. I first register a global hotkey through the Windows API RegisterHotKey using the launcher main window handle. The key could be any, but should be one that normally doesn't exist physically, F24 in my case. Then, whenever I detect a keypress through the hooks that should launch an app, I first call keybd_event to 'fake' a keypress for the hotkey.
For WPF use:
keybd_event((byte)KeyInterop.VirtualKeyFromKey(Key.F24),0,KEYEVENTF_KEYUP,0);
For WinForms use:
keybd_event((byte)Keys.F24,0,KEYEVENTF_KEYUP,0);
This will bring enough focus to the launcher, so that Process.Start(...) makes the executed program get in front. It does not bring the launcher window to front, nor does it make the launcher accept inputs.
If Activate() is called on the main window after the keybd_event(), this will bring the main window to front and allow for keyboard input, just as if the user had task switched.