I'm tryng to load into and paste data from the clipboard like this:
int main() {
Sleep(3000);
char buf[] = "Hello33";
HWND hwnd = GetActiveWindow();
if (OpenClipboard(hwnd)) {
EmptyClipboard();
HGLOBAL hClipboardData;
hClipboardData = GlobalAlloc(GMEM_DDESHARE, BUFLEN);
char * pchData;
pchData = (char*) GlobalLock(hClipboardData);
strcpy(pchData, LPCSTR(buf));
GlobalUnlock(hClipboardData);
SetClipboardData(CF_TEXT, hClipboardData);
CloseClipboard();
SendMessage(hwnd, WM_PASTE, 0, 0);
}
}
Starting the program, then open text editor, text editor is the top window and no text is pasted. If I do the paste command Ctrl-V I got Hello33 into the text area.
GetActiveWindow returns the main window not the child window
you should try GetFocus();
but even this will not work, be cause it is in an other thread that belong to other process.
to resolve that, call AttachThreadInput
finally i suggest to drop all of this, and try FindWindow instead and send message directly to the Edit Box, by using SendDlgItemMessage
Related
I'm writing a custom module to work with a proprietary software. (That software has been discontinued and I do not have its source code.) My module will run as a separate process. Its goal is to automate an operation via this proprietary software. To do that I need to be able to simulate saving the output from this software. I can bring up its Save As dialog via simulating a toolbar button click:
I then attempt to change the "Save as type" combo box to the file type required, add file path to save to, and simulate the click on the Save button. I came up with the following code to do that:
//All I have to work with are the following window handles:
//HWND hWndFileName = file name window handle
//HWND hWndSaveAsType = save as type window handle
//HWND hWndSaveBtn = Save button handle
DWORD dwComboIDSaveAsType = ::GetWindowLong(hWndSaveAsType, GWL_ID);
HWND hParWnd = ::GetParent(hWndSaveAsType);
//Select index for file type
int nSaveAsIndex = 3;
::SendMessage(hWndSaveAsType, CB_SETCURSEL, nSaveAsIndex, 0);
::SendMessage(hParWnd, WM_COMMAND,
(dwComboIDSaveAsType & 0xffff) | ((((DWORD)CBN_SELCHANGE) << 16) & 0xFFFF0000),
(LPARAM)hWndSaveAsType);
//Set path to save
::SendMessage(hWndFileName, WM_SETTEXT, NULL,
(LPARAM)L"C:\\Test\\test file");
//Simulate Save button click
::SendMessage(hWndSaveBtn, BM_CLICK, 0, 0);
Interestingly, the code above achieves the goal (by visually change the "Save as type" combo box) but when the file is saved, it still has the old, or originally selected type, i.e. "Quick Report file (.QRP)".
Any idea how to fix this?
I think I got it. Evidently I needed to send CBN_SELENDOK to the parent also. So it should be this:
//All I have to work with are the following window handles:
//HWND hWndFileName = file name window handle
//HWND hWndSaveAsType = save as type window handle
//HWND hWndSaveBtn = Save button handle
DWORD dwComboIDSaveAsType = ::GetWindowLong(hWndSaveAsType, GWL_ID);
HWND hParWnd = ::GetParent(hWndSaveAsType);
//Select index for file type
int nSaveAsIndex = 3;
::SendMessage(hWndSaveAsType, CB_SETCURSEL, nSaveAsIndex, 0);
::SendMessage(hParWnd, WM_COMMAND,
MAKEWPARAM(dwComboIDSaveAsType, CBN_SELENDOK),
(LPARAM)hWndSaveAsType);
::SendMessage(hParWnd, WM_COMMAND,
MAKEWPARAM(dwComboIDSaveAsType, CBN_SELCHANGE),
(LPARAM)hWndSaveAsType);
//Set path to save
::SendMessage(hWndFileName, WM_SETTEXT, NULL,
(LPARAM)L"C:\\Test\\test file");
//Simulate Save button click
::SendMessage(hWndSaveBtn, BM_CLICK, 0, 0);
I tried this:
int editlength;
int buttonid = 3324; // id to button, the numbers dont mean anything
int editid = 5652; // id to edit
LPTSTR edittxt;
HWND button; // created in wWinmain as a button
HWND edit; // created in wWinMain as an edit control
// LRESULT CALLBACK WindowProc
switch(uMsg)
{
case WM_COMMAND:
if(wParam == buttonid)
{
filedit = GetDlgItem(hwnd, editid); // I tried with and without this
editlength = GetWindowTextLength(filedit);
GetWindowText(filedit, edittxt, editlength);
MessageBox(hwnd, edittxt, L"edit text", 0);
}
break;
}
But I get don't see any text in the message box.
The last argument to GetWindowText() is the size of your buffer. Since you set it to the length of the string, you are telling the function that your buffer is too small because there's no room for the null terminator. And nothing gets copied.
In addition, you must already allocate the buffer to hold the copy of the text. What does edittxt point to? I don't even see where you initialize it.
Correct usage would look something like this:
TCHAR buff[1024];
GetWindowText(hWndCtrl, buff, 1024);
edittxt needs to be a pointer to a buffer that gets the text.. so try this...
char txt[1024];
....
GetWindowText(filedit, txt, sizeof(txt));
You may have to adjust for unicode.. sorry its been a while since I did raw win32.
is it possible to create a program that works as console application if started from the console and works as windows program (with GUI) when started otherwise?
If it is possible - how can I do that?
regards
Tobias
If you set the program up to build as a GUI program you can then attempt to attach to the console using AttachConsole(). You you attach OK then you were started from a console and you can proceed to redirect your standard handles to the newly attached console.
In this way you can start up and see if you are being started from a console that you can attach to and if so become a console program. If you cant attach you can show a GUI.
I've had some success with this, the main problem I have is redisplaying the command window's prompt when my program exits (which is how normal console programs operate), but I expect you could do something clever (read the console buffer on start up and find the prompt to redisplay when you exit?) if you really wanted to ...
If you need the program to act as a console application (e.g. print the usage information to the console) you must complile as a console application. A windows application will not have access to the console and cmd.exe will not wait for it to finish before printing the prompt and accepting the next command.
The best solution is to have two versions, one for command line and one for the GUI (which users usually run via a link on the desktop or start menu).
If you insist on using a single binary you will have to live with a console window appearing, at least for a short time. You can get rid of the console window using
FreeConsole();
You can tell that your application was run from GUI if it is the only process attached to the console. You can use GetConsoleProcessList to find the list of processes attached to the console.
This is the answer from Dan Tillett and it is remarkably effective. No flashes, no .com and .exe to trick cmd.exe. Seems to work flawlessly typing the command, in a .bat file, with focus, without focus and as double-click GUI app.
It's the bees knees!
Here is web page describing it, but I've posted it here because if that page goes 404 next month or 2 years from now, the excellent and "most complete" solution I've seen would be "off the grid".
http://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/
#define WINVER 0x0501 // Allow use of features specific to Windows XP or later.
#define _WIN32_WINNT 0x0501
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <io.h>
#include <fcntl.h>
#include <stdio.h>
#pragma comment(lib, "User32.lib")
// Attach output of application to parent console
static BOOL attachOutputToConsole(void) {
HANDLE consoleHandleOut, consoleHandleError;
int fdOut, fdError;
FILE *fpOut, *fpError;
if (AttachConsole(ATTACH_PARENT_PROCESS)) {
//redirect unbuffered STDOUT to the console
consoleHandleOut = GetStdHandle(STD_OUTPUT_HANDLE);
fdOut = _open_osfhandle((intptr_t)consoleHandleOut, _O_TEXT);
fpOut = _fdopen(fdOut, "w" );
*stdout = *fpOut;
setvbuf(stdout, NULL, _IONBF, 0 );
//redirect unbuffered STDERR to the console
consoleHandleError = GetStdHandle(STD_ERROR_HANDLE);
fdError = _open_osfhandle((intptr_t)consoleHandleError, _O_TEXT);
fpError = _fdopen(fdError, "w" );
*stderr = *fpError;
setvbuf(stderr, NULL, _IONBF, 0 );
return TRUE;
}
//Not a console application
return FALSE;
}
//Send the "enter" to the console to release the command prompt on the parent console
static void sendEnterKey(void) {
INPUT ip;
// Set up a generic keyboard event.
ip.type = INPUT_KEYBOARD;
ip.ki.wScan = 0; // hardware scan code for key
ip.ki.time = 0;
ip.ki.dwExtraInfo = 0;
//Send the "Enter" key
ip.ki.wVk = 0x0D; // virtual-key code for the "Enter" key
ip.ki.dwFlags = 0; // 0 for key press
SendInput(1, &ip, sizeof(INPUT));
// Release the "Enter" key
ip.ki.dwFlags = KEYEVENTF_KEYUP; // KEYEVENTF_KEYUP for key release
SendInput(1, &ip, sizeof(INPUT));
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR lpCmdLine, INT nCmdShow) {
int argc = __argc;
char **argv = __argv;
UNREFERENCED_PARAMETER(hInstance);
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);
UNREFERENCED_PARAMETER(nCmdShow);
BOOL console;
int i;
//Is the program running as console or GUI application
console = attachOutputToConsole();
if (console) {
//Print to stdout
printf("Program running as console application\n");
for (i = 0; i < argc; i++) {
printf("argv[%d] %s\n", i, argv[i]);
}
//Print to stderr
fprintf(stderr, "Output to stderr\n");
}
else {
MessageBox(NULL, "Program running as windows gui application",
"Windows GUI Application", MB_OK | MB_SETFOREGROUND);
}
//Send "enter" to release application from the console
//This is a hack, but if not used the console doesn't know the application has returned
//"enter" only sent if the console window is in focus
if (console && GetConsoleWindow() == GetForegroundWindow()){
sendEnterKey();
}
return 0;
}
The program itself will never know how it was started. Unless you are willing to pass an execution arguments to the program. For example: program.exe -GUI ... you can capture the passed parameters and decide how the program should run based on parameters passed.
your program whould be something like:
class MainClass
{
public static int Main(string[] args)
{
// Test if input arguments were supplied:
if(args[0]=="GUI")
new myGUI().show(); //runs an instance of your gui
else
//you know what should go here
}
}
You can sort of guess whether you are started from the console or not by doing this:
CONSOLE_SCREEN_BUFFER_INFO csbi;
GetConsoleScreenBufferInfo(GetStdHandle(STD_OUTPUT_HANDLE), &csbi);
fConsole = csbi.dwCursorPosition.X | csbi.dwCursorPosition.Y;
It's a guess -- if your cursor position is not 0,0 than you are in a console and can work as a console app. Otherwise go and create your windows.
Another way to guess is to look at the process tree and see what process launched your app. If it is cmd.exe go in console mode, otherwise go into GUI mode.
Make it a console application and put this into the code:
void ConsoleWindowVisible(bool show)
{
DWORD dummy;
if
(
!show && // Trying to hide
GetConsoleProcessList(&dummy, 1) == 1 // Have our own console window
)
ShowWindow(GetConsoleWindow, SW_HIDE); // Hide the window
else // Trying to show or use parent console window
ShowWindow(GetConsoleWindow, SW_NORMAL); // Show the window
}
int main(int argc, char** argv)
{
ConsoleWindowVisible(false);
}
Cheers.
gor.f.gyolchanyan#gmail.com
I have a fullscreen application wrtten in C++ and would like to open a dialog window so the user can select a file to be opened without the app breaking out of fullscreen mode.
On Windows, to run in fullscreen mode, I call ChangeDisplaySettings(&settings, CDS_FULLSCREEN). (Technically, I am using SDL, but this is the call it uses.)
To open the file dialog, I use the following code:
HWND hWnd = NULL;
SDL_SysWMinfo wmInfo;
SDL_VERSION(&wmInfo.version);
if( SDL_GetWMInfo(&wmInfo) ) {
hWnd = wmInfo.window; // Note: This is sucessful, and hWnd != NULL
}
OPENFILENAMEW ofn;
wchar_t fileName[MAX_PATH] = L"";
ZeroMemory(&ofn, sizeof(ofn));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hwndOwner = hWnd;
ofn.lpstrFile = fileName;
ofn.nMaxFile = MAX_PATH;
ofn.Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST;
if( GetOpenFileNameW( &ofn ) ) {
DoSomethingWith( fileName );
}
When run, hWnd is not NULL, but when this dialog is created, it shifts the window focus to the dialog, which breaks out of the fullscreen app, similar to alt-tabbing to another window while in fullscreen. Once the file is selected and the Open File dialog closes, I have to manually switch back to the fullscreen app.
Is it possible to do what I want using existing Windows dialogs, or do I have to write my own in-app file browsing system or run in windowed mode only?
Sure... you just have to pass the HWND of the full screen window as the parent of the Open File common dialog (it is the hwndOwner parameter in the OPENFILENAME structure that is passed to GetOpenFileName).
Can we change/increase the size of console output to view large size of data in console application at once?
There seem to be different ways to Rome:
This should be the recommended way I would think, cause the name says it all: GetConsoleWindow as is demonstrated here.
A quick hack might be the windows API function SendInput. If you simulate Alt+Enter, you could probably fullscreen the active window.
Here are some propositions using API calls from user32.dll
Check out the SetConsoleScreenBufferInfoEx API. It takes a CONSOLE_SCREEN_BUFFER_INFOEX as input and that has a dwSize member which contains the size of the console screen buffer, in character columns and rows.
MSDN for SetConsoleScreenBufferInfoEx Function: http://msdn.microsoft.com/en-us/library/ms686039(v=VS.85).aspx
I once used a small hack that is first setting the console's output buffer and then trying to find the console window and resize it. It worked well on XP, I never tested it on newer Windows versions.
HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
SMALL_RECT sr;
sr.Top = 0;
sr.Left = 0;
sr.Bottom = 10;
sr.Right = 79;
SetConsoleWindowInfo(h, TRUE, &sr);
TCHAR title[512];
GetConsoleTitle(title, 512);
HWND hWnd = FindWindow(NULL, title);
if(hWnd != NULL) {
HWND hWndInsertAfter = NULL;
UINT nFlags = SWP_NOSIZE | SWP_NOZORDER;
#if 0 // Don't move?
nFlags |= SWP_NOMOVE;
#endif
SetWindowPos(hWnd, hWndInsertAfter , 40, 350, 0, 0, nFlags);
SetForegroundWindow(hWnd);
}
If you are using the command prompt window, right click it's label on the task bar and click the Properties option.