I have written a console application, which is essentially a Console.ReadLine()-Loop. When the application is waiting for input, pressing the up arrow key iterates through all previous lines of input. My application does not contain any code for this feature. What part of Windows provides this? How can I disable it?
I can only image that it's either a feature of the console subsystem or implemented in Console.ReadLine().
Here is some sample code that exhibits the described behavior:
namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
string input;
do
{
input = System.Console.ReadLine();
} while (input != "exit");
}
}
}
I would like to disable the history feature for now, and re-implement it later using my own code. The current behavior is too limited.
you can change this behaviour of windows programmatically by calling SetConsoleHistoryInfo with a correctly setup CONSOLE_HISTORY_INFO structure... there seems to be no managed class/method so you will have to use DllImport etc.
http://msdn.microsoft.com/en-us/library/ms686031%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms682077%28v=VS.85%29.aspx
IF need be - several other aspects of the console can be handled in a managed way - see c# console, Console.Clear problem
The history feature is built into the Windows Command shell, it is not a feature of your application. AFAIK there's no way to disable this in your code as it's specific to the Windows Shell Environment (unless there's a setting that can be changed, which there probably is)
You could possibly override the default behavior by using a key listener to get all up arrow keypresses and execute your own code, that way the event doesn't drop down to the shell to handle.
Yes, this is a feature of the console subsystem, not your application. To change it, click the console's control box (top left), properties, options tab: "Command history." The default is 50 items, 4 buffers. Supposedly this can be configured programmatically with DOSKEY from the command line, but a few minutes tinkering didn't lead me anywhere.
ALT+F7 will clear the command history, as will executing the command DOSKEY /reinstall. I tested in Windows 7.
Update: The corresponding Win32 API call is SetConsoleHistoryInfo and the p/invoke signature can be found at http://pinvoke.net/default.aspx/kernel32/SetConsoleHistoryInfo.html
Not tested, but it looks like passing an instance of CONSOLE_HISTORY_INFO to SetConsoleHistoryInfo with buffer size and count set to 1 would give the same control as the console window properties dialogue.
P/Invoke definitions at pinvoke.net
Also note this requires Windows V6 or later (ie. Vista/2008/7/2008R2).
Related
I have a application in which i want to open a calculator on a button click and once the operation are performed on calculator and calculator is closed, I want that value back to my text box.
How can I achieve this functionality.
private void btnDollarTransferHelp_Click(object sender, EventArgs e)
{
System.Diagnostics.Process myProcess = System.Diagnostics.Process.Start("calc.exe");
}
I am using C# 4.0 and its a window based application.
Regards and Thanks
You may use the Microsoft Script Control to implement the calculator functionality in your C# app. The control has a simple Eval() method to evaluate expressions that may range from simple "2+2" to VBScript commands. More information here:
http://msdn.microsoft.com/en-us/library/aa227637(v=vs.60).aspx
It is indeed simpler to implement a calculator in your app: reading the content of another's process window is not trivial! And being notified when the calculator is "about to close" is even harder.
It involves, for sure, widows API (FindMessage/SendMessage) (see for example https://stackoverflow.com/a/360247/863564), probably P/Invoke, probably even hooking calc.exe (the technique used by Spy++ -- you need it to capture the WM_CLOSE message - see here what happens when you are closing a window)
(You need to capture WM_CLOSE, because it is the latest sensible moment to grab the result from the control on the window)
So, the alternative: a great one is scriptcs, but it may be well too much! A quick search revealed
some
great
projects
Either way, have fun!
you could use an existing library e.g. http://nclac.codeplex.com to provide calculation within your application.
a few days ago, I developed a WinForms application in C# using VC#2010 Express. After creating and saving the project, I made it a console application in the project settings, so additional to the start form, a windows command line pops up. I used the console to output debug information (simply with the Console.Write() function).
So now, my app is ready for a release. I do not want the user to see the console, for sure, but I'd like to integrate a way to show the console to interested persons. So, the best way is an argument, I think (like -console), but I dont know how to start the program as a console application only when an argument is set. I know how to handle the args[] array, for sure, but I have no idea how to show the console when there is an arg. I already tried it by simply starting the program via command line(CMD -> prog.exe), but it did not work. The program starts, but the console directly shows the current path after starting the program, as usual.
Is there any possibility for my intention?
AFAIK, there is no way to have a single binary support both console and non-console behaviour, with the choice being made on start-up. All the work-arounds I've seen use two binaries.
There's a discussion here on how Python deals with the problem (boldface mine):
The standard Python.exe that comes with Python is known as a console application (this means it has been built to interact with a Windows console, otherwise known as a DOS box or command prompt). Although you can execute your Tkinter programs using Python.exe, your program will always be associated with a Windows console. It works just fine, but has the following side effects:
If you execute Python.exe from Windows Explorer, a new empty console window is created; then the Tkinter windows are created.
If you execute a Tkinter application under Python.exe from a command prompt, the command prompt doesn't return until the Tkinter application has finished. This will be a surprise for many users, who expect that executing a GUI program returns the command prompt immediately.
To get around this problem, Python comes with a special GUI version called Pythonw.exe. This is almost identical to the standard Python.exe, except it's not a console program, so doesn't suffer the problems described previously.
You could get the command line arguments for the Winform in the forms load event and then if the argument is for the console, open the console.
private void Form1_Load(object sender, EventArgs e)
{
string[] args = Environment.GetCommandLineArgs();
foreach(string arg in args)
{
if(arg == "consoleargument")
{
// Run console
}
}
}
You can link to kernel32.dll and use the function AttachConsole.
Here's an example: http://www.csharp411.com/console-output-from-winforms-application/
I'm working on an existing project that has a text import tool written in C#. It essentially shuffles to the last window that had focus, copies the text, switches back and pastes the text in the textbox. To do this it essentially issues keyboard commands so: Alt + Tab, Ctrl + A, Ctrl + C, Alt + Tab and then finally get the text from the clipboard and add it to the textbox.
Currently, it works terrific on XP. It doesn't, however, work on Vista/Win 7. It will switch to the new window and that appears to be it but when I go back to the C# it has added whatever was previously in the clipboard (not successfully copying the new text). My guess is that there's some problem telling another window to use the keyboard keys (Select All and Copy).
I have done some moderate searching online and haven't really found anything so I was hoping to see if anyone may have had a similar problem.
Assuming you're using SendKeys, you might want to look at this comment on the SendKeys MSDN page. If this is something introduced with Vista, it'd almost certainly affect Windows 7 as well, Id' think:
Note
The SendKeys class has been updated
for the .NET Framework 3.0 to enable
its use in applications that run on
Windows Vista. The enhanced security
of Windows Vista (known as User
Account Control or UAC) prevents the
previous implementation from working
as expected.
The SendKeys class is susceptible to
timing issues, which some developers
have had to work around. The updated
implementation is still susceptible to
timing issues, but is slightly faster
and may require changes to the
workarounds. The SendKeys class tries
to use the previous implementation
first, and if that fails, uses the new
implementation. As a result, the
SendKeys class may behave differently
on different operating systems.
Additionally, when the SendKeys class
uses the new implementation, the
SendWait method will not wait for
messages to be processed when they are
sent to another process.
If your application relies on
consistent behavior regardless of the
operating system, you can force the
SendKeys class to use the new
implementation by adding the following
application setting to your app.config
file.
To force the SendKeys class to use the
previous implementation, use the value
"JournalHook" instead.
http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys.aspx
I am trying to writing a console application. It has its original console, let's name it console A. And I want this application to do the following things via C#:
Open another console B in another thread, then get input from A and output it to B;
type a command in A, such as dir, and show the output in B;
while doing the above things (still not done yet. X_X ), I find myself lack a through understanding of what a console window is, and how it is assigned to a console application, especially the very first console when my console application starts to run. Could some one shed some light on me?
Is console window physically a memory area in the video memory? Or something else?
Could different threads within the same process have different console of its own for its own I/O?
Many thanks.
Now I am using one console application to start another console application in a new process. Thus I can have 2 consoles output at the same time.
My understanding now is that, for Windows OS, a console is a special window, and it's a system resource that OS assigned to the application without-a-UI as a necessary user interface. Windows OS handles the wiring between the system-prepared console window with our UI-less application.
In Windows terms, a Console is a textual GUI window that you see when you run "cmd.exe". It allows you to write text to, and read text from, a window without the window having any other UI chrome such as toolbars, menus, tabs, etc,..
To get started you'll want to load Visual Studio, create a new project and choose "Console Application". Change the boilerplate code that Visual Studio produces to:
using System;
using System.Text;
namespace MyConsoleApp
{
class Program
{
static void Main(string[] args)
{
Console.Write("Hello, world!");
Console.ReadKey();
}
}
}
When you run your application, a console window will open with the text "Hello, world!" and it'll stay open until you press a key. That is a console application.
Is console window physically a memory area in the video memory? Or something else?
It's not physically a memory area in video memory, it's "something else". The Wikipedia Win32 console page gives a fairly robust descrption of the ins and outs.
A console application has only one window. It does not have window management functions in order to spawn child "consoles".
You can start additional console applications, but these are separate entities.
No. It's a windows GUI subsystem. In WinAPI there are functions to work with console: http://msdn.microsoft.com/en-us/library/ms682073%28VS.85%29.aspx
A (OS) console is a process (containg one or more threads of executions, all of them sharing the same memory space), and this process has:
standard input (a stream of input bytes), what you key in
standard output (a stream of output bytes), what the program prints
standard error (a stream of output bytes), what the program prints when it's complaining about something
So if you want to create another console (from .Net) and link the input/outputs I understand you have to create a process (executing "cmd.exe" by example).
I don't know the API of .Net for process manipulation but if it's like Java you can hook up stdin, out and err so you can play with your created process from the original one.
A windows application can have one console, or no console, it can't have more than one. See the documentation for AllocConsole.
The console is basically an emulation of the 'pre-Windows' days when there would literally be a 'control console' i.e. a keyboard and screen attached to a mainframe computer.
To do what you want you could spawn another process with its own console and communicate between the two, or make a GUI application which looks like a console window.
How can I make my C# application the default "Print Screen" handler in Windows?
I wrote a screen capturing utility and I want to, ideally, have it replace the default print-screen handler, or otherwise have a unique key combination that would trigger it.
I know how to do it in C++ using global hooks, etc., but it's not clear to me how this can be done in .Net. Also, if there's a way of doing it without using a memory resident application that would be super.
As long as you are using a WM_KEYBOARD_LL hook to capture the PrintScreen key, there is no reason you can't do this in C#. It's one of the few global hooks that can be used in managed code because it doesn't require a DLL to be injected into every target process. Instead the context will switch back to the originating application for processing.
Adam's blog has a great post on how to setup such a hook in C#: http://www.seesharpdot.net/?tag=wh_keyboard_ll
Why not use AutoHotKey (OpenSource, free) with the following script?
This script was taken from the newsgroup of AutoHotKey, it will map the printscreen to use IrfanView. You can use it to trigger your program.
~printscreen::
ifexist,%screenshot1%\irfanview.exe
{
run, "%screenshot1%\irfanview.exe" "/capture=0 /convert=%screenshots%\%A_now%_screenshot.jpg"
sleep,500
run,%screenshots% ;open folder
return
}
return
~!printscreen:: ;copy only active window
ifexist,%screenshot1%\irfanview.exe
{