First, to clarify, I am not asking how to drag-and-drop a file onto an exe's icon. I want to know how to handle drag and drop onto an already running win32 console application. I'm also not asking how to handle drag and drop inside of WinMain based applications through the Windows message pump. I want to do this inside of a program with the entry point int main() that doesn't have a WndProc (yet) or anything.
That said, I'm wondering if my goal is achievable (and hoping that it is).
I have a server application that is running within a console window. Due to a large codebase and a lot of weird coupling, it is an 'output only' console for all intensive purposes. Within it though, I can still handle things like key presses, as I have an update loop ticking. I'd like to be able to drag and drop files full of commands (which use a custom syntax) onto my running application and have it process them.
Is this possible to do? I was thinking that potentially I could get a pointer to the HWND of the console (which hopefully is a thing?), and then maybe subclass that window to use a custom WndProc to listen for the WM_DROPFILES message.
I've never really tried to set up handling of windows messages in an int main() program instead of a WinMain program, but I'm hoping it's somehow possible.
Any help would be greatly appreciated!
Weird solutions are fine.
AFAIK, a console window does not support drag&drop by default. You can always create your own separate popup window with its own message loop so the user has something to drag items onto.
To use drag&drop on the console window itself, try using GetConsoleWindow() to get the console HWND, then either:
subclass the HWND using SetWindowLong/Ptr() or SetWindowSubClass(), then register the HWND using DragAcceptFiles() to start receiving WM_DROPFILES messages. Be sure to call DragAcceptFiles() again to stop receiving the messages and then unhook your subclass before exiting the app.
implement the IDropTarget interface and then register the HWND using RegisterDragDrop() to start receiving notifications. Be sure to call RevokeDragDrop() before exiting the app.
WM_DROPFILES is easier to code for, but IDropTarget is more flexible as it handles virtual items as well as physical files.
#include <vector>
#include <string>
#include <iostream>
#include <conio.h>
int main()
{
std::cout << "Please drop files and press [Enter] when done ...\n";
std::vector< std::string > files;
for( int ch = _getch(); ch != '\r'; ch = _getch() ) {
std::string file_name;
if( ch == '\"' ) { // path containing spaces. read til next '"' ...
while( ( ch = _getch() ) != '\"' )
file_name += ch;
} else { // path not containing spaces. read as long as chars are coming rapidly.
file_name += ch;
while( _kbhit() )
file_name += _getch();
}
files.push_back( file_name );
}
std::cout << "You dropped these files:\n";
for( auto & i : files )
std::cout << i << '\n';
}
Related
I am asking if there is any way, and how to print text like the Windows installation "We're setting things up for you" to the middle of the screen? If I can, can I make it so only the text gets displayed and the text background should be your desktop.
The classic way to deal with the console in Windows is via the Console API. To get the console size you can use GetConsoleScreenBufferInfo(). Here's a very simple example that draws a string at the center of the screen
#include <iostream>
#include <sstream>
#include <algorithm>
#include <cstdint>
#include <windows.h>
int main(void)
{
auto stdout_handle = GetStdHandle(STD_OUTPUT_HANDLE);
std::string str;
CONSOLE_SCREEN_BUFFER_INFO oldcsbi{};
COORD coord{};
while (1)
{
CONSOLE_SCREEN_BUFFER_INFO csbi;
GetConsoleScreenBufferInfo(stdout_handle, &csbi);
if (csbi.srWindow.Bottom != oldcsbi.srWindow.Bottom || csbi.srWindow.Right != oldcsbi.srWindow.Right)
{
std::fill(str.begin(), str.end(), ' ');
SetConsoleCursorPosition(stdout_handle, coord);
std::cout << str; // clear the old text
oldcsbi = csbi;
std::ostringstream s;
s << "Console size: " << csbi.srWindow.Right << 'x' << csbi.srWindow.Bottom;
str = s.str();
coord.X = (short)((csbi.srWindow.Right - str.size()) / 2);
coord.Y = (short)(csbi.srWindow.Bottom/2);
SetConsoleCursorPosition(stdout_handle, coord);
std::cout << str; // draw the new text
}
Sleep(1000);
}
}
The above code gets the console size periodically and redraws the screen if the size has been changed. It loops indefinitely until you press Ctrl+C or close the program
For more information about the Console API see Using the Console
But of course polling the size like that isn't very good because it makes the output not very smooth and also eats up CPU cycles. The real solution is to listen to the resize events and do the necessary things in that callback function
There's a mode called ENABLE_WINDOW_INPUT which passes the resize events to the console where you can read by the blocking ReadConsoleInput() or PeekConsoleInput() APIs. You can see an example in Reading Input Buffer Events. Just run it and resize the window, the resize events will be printed out
Unfortunately in that mode only the console buffer size change event is fired through the WINDOW_BUFFER_SIZE_RECORD and there's no console screen size change event, so if you change the number of rows then most of the time no events are generated. That means you'll need to go to a lower level and listen to the Console Winevent named EVENT_CONSOLE_LAYOUT:
HWINEVENTHOOK eventHook = SetWinEventHook(EVENT_CONSOLE_LAYOUT, EVENT_CONSOLE_LAYOUT,
NULL, EventProc, 0, 0, WINEVENT_OUTOFCONTEXT);
...
MSG msg;
while (GetMessage(&msg, g_hWindow, EVENT_CONSOLE_LAYOUT, EVENT_CONSOLE_LAYOUT)) {
DispatchMessage(&msg);
You can find more details in
How do I disable or detect mode changes in Windows Console?
Can I prevent the user of my program to resize the console window? (in C)
The easier and even better way is to use ncurses and handle something similar to SIGWINCH. There were many Windows ports for ncurses in the past, and given Windows 10 console supports ANSI sequences it's even easier to write an ncurses port. In fact nowadays it's recommended to use ANSI sequences for terminal interaction instead of the ole Console API for portability
Is ncurses available for windows?
NCurses-Like System for Windows
Any Windows Substitutes For Curses/NCurses?
Ncurses for Windows
<Window x:Class="YourApplication.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="600" Width="800" WindowStyle="None" AllowsTransparency="True" Background="Transparent" Topmost="True">
<StackPanel>
<TextBlock Text="Your Text Here"/>
</StackPanel>
</Window>
Please note that this will work only until some other application declares itself TopMost.
Suggestion by Window “on desktop”
I have transcribed a c++ console app to GUI using wxWidgets. Most of my functions were written for the commandline flow. I am creating handles and additional code to interface GUI with the functions. I have emulated a console for output stream, which works good (using wxStreamToTextRedirector). However, I can't find a simple solution to take user input from a textcontrol and substitute the std::cin command in cases like the code below. Event handlers and GUI controls for my frame are in MainFrame.cpp and object data and functions in another Data.cpp
I have a function in Data.cpp which will be called on a button press event from MainFrame.cpp:
bool Data::run_yn_prompt()
{ //Run Y or N input prompt
do {
std::string input = "";
std::cout << "\n Input Y/y to proceed, N/n to cancel:"; **//OUTPUT TO DISPLAY CONSOLE**
std::getline(std::cin, input); **//Need to fetch wxTextCtrl input at this point only**
std::cout << input;
if ( (input=="Y") || (input=="y") ) return true;
if ( (input=="N") || (input=="n") ) return false;
} while(1==1);
}
The problem is I need the input to be fetched only after:
the previous std::cout is run and
the user enters the input and presses ENTER (to be signaled by wxEVT_TEXT_ENTER event handler)
The only way I guess I could do it is by adding a lot of conditionals and boolean flags to watch for user input and enter press. Is there any simple strategy to make this work? My goal is not to publish this app, but learn to get wxWidgets elements to work as per my need. I have so many std::cin in the middle of my code like this. This problem has stopped me from moving forward with wxWidgets. And I would like to keep everything in a single frame without additional dialogs.
The only way to preserve the code using std::cin in a GUI program is to use modal dialogs for text entry (e.g. wxGetTextFromUser()) instead. This is not going to be nearly as convenient for the user as using a text control inside the main program window, but it's the only way to preserve the existing control flow.
This question already has answers here:
How and why does QuickEdit mode in Command Prompt freeze applications?
(2 answers)
Closed 6 years ago.
for an application of mine I have been playing around with the Windows API a bit, namely creating a very small wrapper for window functionality. Since I like to have console output as well, I created a console via AllocConsole(). I then noticed that highlighting text in this console (like if you want to copy something) 'freezes' the open window, ie. no messages will be processed, it is not click- or closable. Message loop and wndProc are both standard.
Two questions: is that intended/documented behaviour (I couldn't find anything about it) and if yes, is there a way to disable it? It's kind of annoying.
Thanks in advance
EDIT: as requested, the console creation code:
FILE *conOut = NULL;
FILE *conIn = NULL;
if (::AllocConsole())
{
::freopen_s(&conIn, "CONOUT$", "r", stdin);
::freopen_s(&conOut, "CONOUT$", "w", stdout);
// ...
if (conOut != NULL)
::fclose(conOut);
if (conIn != NULL)
::fclose(conIn);
::FreeConsole();
}
I created a test Win32 application with a basic Win32 project. I added a simple class to handle the console creation and tested two scenarios. What I found was the console window output will stop as if the thread generating the output is suspended when an Edit->Mark is done until the Mark is completed with a Copy or canceled.
The two scenarios tested with the Win32 application were: (1) printing to console window in a separate thread and (2) printing to console window in the main window message handling logic.
The particulars of the test program and details of the two scenarios tested are as follows.
Console.h
#pragma once
#include <stdio.h>
class CConsole
{
public:
CConsole(void);
~CConsole(void);
int Create(void);
public:
FILE *m_conOut;
FILE *m_conIn;
};
Console.cpp
#include "StdAfx.h"
#include "Console.h"
CConsole::CConsole(void)
{
}
CConsole::~CConsole(void)
{
}
int CConsole::Create(void)
{
if (::AllocConsole())
{
::freopen_s(&m_conIn, "CONIN$", "r", stdin);
::freopen_s(&m_conOut, "CONOUT$", "w", stdout);
}
return 0;
}
In the main file at the near the top where the Win32 project wizard put some global variables, I added an additional global variable CConsole myConsole; for my console and then I added a bit further down a simple function that is the target of a _beginthreadex(). The function looks like:
unsigned __stdcall myThread( void *x )
{
HWND hWnd = (HWND)x;
// allow for two different test scenarios depending on whether the
// SendMessage() is commented out or the fprintf() is commented out.
// if SendMessage() is live then the main window will write to the console window
// if fprintf() is live then this thread will write to the console window.
for (int i = 0; i < 50; i++) {
// SendMessage (hWnd, WM_USER, i, 0); // send a message to main window to request print
fprintf (myConsole.m_conOut, "This is line %d\n", i); // print from this thread
Sleep (1000);
}
return 0;
}
In the InitInstance(HINSTANCE hInstance, int nCmdShow) just before the return statement, I added the following two lines of code:
myConsole.Create();
_beginthreadex (NULL, 0, myThread, hWnd, 0, NULL);
Finally in the main message loop that handles the messages for the main window I added an additional message target:
case WM_USER:
fprintf (myConsole.m_conOut, "This is line %d\n", wParam);
break;
I then tried two different experiments by commenting out one of the two lines in my function that is the target of the _beginthreadex().
One was to print to the console window using fprintf() within that thread. The second test case was to send a message of WM_USER to the main window and ask it to use fprintf() to print to the console window.
What I found was that with the printing being done by the thread then I observed the following behavior when I used the Edit->Mark to begin the procedure of marking text to copy:
the main window was responsive to menu choices
the console window output stopped
when I cleared the mark or copied text, console window output resumed
The behavior was as if the thread writing to the console window was suspended until the Mark and Copy procedure was completed.
When the printing was done by the main window's message loop when handling the WM_USER message then I observed the following behavior when I used the Edit->Mark to begin the procedure of marking text to copy:
the main window was unresponsive to menu choices
the console window output stopped
when I cleared the mark or copied text, main window responsiveness returned as did console output
For some additional information about the Console Window Subsystem see Consoles. For a bit of information about the technology see WinEventProc Callback Function along with SetWinEventHook which describes this functionality to some extent as well as What Are WinEvents? and In-Context Hook Function Precautions.
See also Console Window Host in the book Windows Internals for a brief overview of the Console Window Subsystem.
And see Windows 7 / Windows Server 2008 R2: Console Host for an introduction to the architecture changes.
Finally The Console Host Process in Windows 7 from the book Inside Windows Debugging shows how to "discover the various layers involved in the printf sequence".
It may be possible to use the Console functions at a lower level to directly interface with the Console Window Subsystem in order to prevent the freezing of the thread which is doing I/O to the console window.
I am currently experimenting with xdotool to send keys to a process (I understand that it may not work for all processes that does not set _NET_WM_PID). I have trouble sending keystrokes to windows other from the focus. It does work if you are sending keystrokes to the CURRENTWINDOW. Below is the snippet that I used to test xdotool's functionality.
extern "C"{
#include <xdo.h>
}
//extern "C" xdo_window_search
#include <iostream>
#include <string.h>
using namespace std;
int main(){
xdo_t* p_xdo = xdo_new(NULL);
// Allocate memory for search query.
xdo_search_t s;
// Clear the allocated memory.
memset(&s, 0, sizeof(xdo_search_t));
// Set the search query.
s.pid = 1916;
s.max_depth = -1;
s.searchmask = SEARCH_PID;
s.require = xdo_search::SEARCH_ANY;
// Allocate memory for output
Window* windows;
int no_windows;
xdo_window_search(p_xdo,&s,&windows,&no_windows);
cout << no_windows << endl;
// Prints all windows' names with matching criteria
for( int i=0;i<no_windows;i++ ){
unsigned char * name;
int size;
int type;
xdo_get_window_name(p_xdo,windows[i],&name,&size,&type);
cout << i << ":" << name << endl;
}
for( int i=0;i<no_windows;i++ ){
xdo_type(p_xdo,windows[i],"Hello World",0);
}
//xdo_type(p_xdo,CURRENTWINDOW,"Hello World",0); // This does work.
return 0;
}
In additional to testing xdotool's functionality, I've looked into xdotool's source code. Interestingly, I found that they are using Xtest to send keystrokes to the focused window (CURRENTWINDOW) and X11's XSendEvent for other windows. I turned to xdotool because I couldn't get XSendEvent to work and Xtest cannot send keys to any other windows than the focused window.
Am I not using the xdotool correctly? Does xdotool not work with all *nix OS with X11?
[I am running this on Ubuntu 13.04.]
EDIT
So, it looks like that does work but not for all windows that it finds. For example, it works for firefox but not gedit and gnome-terminal although it found gedit and gnome-terminal by its pid. It behaves differently if I used CURRENTWINDOW.
So, it would be great if someone can explain why is this so. Like, is it related the force send flag in an XEvent?
Directly from the xdotool manual:
SENDEVENT NOTES
If you are trying to send key input to a specific window, and it does
not appear to be working, then it's likely your application is ignoring
the events xdotool is generating. This is fairly common.
Sending keystrokes to a specific window uses a different API than
simply typing to the active window. If you specify 'xdotool type
--window 12345 hello' xdotool will generate key events and send them
directly to window 12345. However, X11 servers will set a special flag
on all events generated in this way (see XEvent.xany.send_event in
X11's manual). Many programs observe this flag and reject these events.
It is important to note that for key and mouse events, we only use
XSendEvent when a specific window is targeted. Otherwise, we use XTEST.
Some programs can be configured to accept events even if they are
generated by xdotool. Seek the documentation of your application for
help.
Specific application notes (from the author's testing): * Firefox 3
seems to ignore all input when it does not have focus. * xterm can be
configured while running with ctrl+leftclick, 'Allow SendEvents' *
gnome-terminal appears to accept generated input by default.
I'm wondering how to accept keyboard and mouse input in C++, using Visual Studio 2010, for Windows 7 32-bit.
--EDIT: I forgot to mention that I need keyboard / mouse input without interrupting the flow of the program. Something like a listener. I don't want to have to pause the program and ask for input, and then have the user type it out and press enter. What I'm looking for is more like:
If user presses W, S, A, D -> something happens.
Or: If user presses leftmousebutton in -> something happens.
I have to mention that I'm still very new to programming as a whole. I know basic OOP programming but that's about it. I'm definitely sure that this will involve things I don't know about yet, and I don't mind, I just ask that you explain it thoroughly, and possibly give an example so I know how to use it.
Thanks.
keyboard / mouse input without interrupting the flow
#include <windows.h>
#include <iostream>
using namespace std;
int main()
{
HANDLE hIn;
HANDLE hOut;
COORD KeyWhere;
COORD MouseWhere;
COORD EndWhere;
bool Continue = TRUE;
int KeyEvents = 0;
int MouseEvents = 0;
INPUT_RECORD InRec;
DWORD NumRead;
hIn = GetStdHandle(STD_INPUT_HANDLE);
hOut = GetStdHandle(STD_OUTPUT_HANDLE);
cout << "Key Events : " << endl;
cout << "Mouse Events : " << flush;
KeyWhere.X = 15;
KeyWhere.Y = 0;
MouseWhere.X = 15;
MouseWhere.Y = 1;
EndWhere.X = 0;
EndWhere.Y = 3;
while (Continue)
{
ReadConsoleInput(hIn,
&InRec,
1,
&NumRead);
switch (InRec.EventType)
{
case KEY_EVENT:
++KeyEvents;
SetConsoleCursorPosition(hOut,
KeyWhere);
cout << KeyEvents << flush;
if (InRec.Event.KeyEvent.uChar.AsciiChar == 'x')
{
SetConsoleCursorPosition(hOut,
EndWhere);
cout << "Exiting..." << endl;
Continue = FALSE;
}
break;
case MOUSE_EVENT:
++MouseEvents;
SetConsoleCursorPosition(hOut,
MouseWhere);
cout << MouseEvents << flush;
break;
}
}
return 0;
}
There are a number of related concepts behind this.
At the very low level, the keyboard and the mouse are hardware devices that generates some "interrupts" (in the form of electric signals) to the CPU.
The operating system provides some drivers that handle such interrupts by decoding the device communication specific protocol, and "standardizing" (at OS level) those signals in the form of events.
With "console applications", the operating system handles those events (the keyboard in particular) by filling up an input buffer (essentially a char[]) that is made accessible as a "virtually infinite sequence of characters" (complicated name for "file") named "CON", thus mimicking the "infinite teletype model" of the early days computers.
In a C++ program, the standard library -at program startup- associates to that "file" the std::cin and std::cout stream objects, so you can read the input character sequence using the std::istream functions and operators.
With "graphical applications", unfortunately, there is no "early days model" to mimic, and "events" are left available as the operating system native structure.
Different operating system differs in the way such events are represented and handled, but certain similitude can be seen.
For Windows (since your question is about), a typical program retrieves those events in sequence with a "message loop" in which calling certain OS APIs.
In that loop, the typical program will also give call another OS API to dispatch those event to appropriate "call-back" procedure, associated to a previously created "window".
That callback procedure has to detect the event code, cast the parameter as appropriate and manage them doing the action required.
A more precise detail can be seen with a WIN32 programming tutorial like http://www.winprog.org/tutorial/.
The most of the code is essentially C, since C is the language the API are formalized.
For C++, a number of libraries have then been written to represent OS objects is the form of C++ classes, and mapping the OS APIs to those classes members.
These libraries can be either OS specific (like MFC, WTL ...) or "multi-platform" (they exist in different version, mapping the API of various OSs into a same C++ interface) like WxWidget, Qt, Gtk, Fltk ...
Hope this can give you more hints to think about.
If you're writing a console application, you can use scanf or cin to get keyboard input. Console applications don't have any support for the mouse.
If you're writing a GUI application, you'll build the app out of standard windows controls that have built-in behaviors for mouse and keyboard input. You can use these re-usable controls as is, or you can augment them to make them behave exactly how you want for your application.
For example, in a GUI application, there's a standard edit control you can use that the user can type into. Your program receives messages when the user enters text into it, and based on those messages, or on other events, you can retrieve the text and do things with it as required by your program.
Windows or Console?
If console, use:
std::cin >> myVar;