I am trying to use libgpm, looks like the program detects mouse clicks,
but as a side effect it prints something like this to the terminal:
^[[M <7^[[M#<7^[[M <7^[[M#<7^[[M <7^[[M#<7^[[M <7^[[M#<7^[[M Y=^[[M#M<^[[M !=^[[M#)=
Even if I remove any calls to Gpm_Getc(), leaving the code as simple as this:
#include <gpm.h>
int main(int argc, char *argv[])
{
Gpm_Connect conn;
int c;
conn.eventMask = 0;
conn.defaultMask = ~0;
conn.minMod = 0;
conn.maxMod = ~0;
if (Gpm_Open(&conn, 0) == -1)
printf("Cannot connect to mouse server\n");
while (1);
Gpm_Close();
return 0;
}
I still see those gibberish codes. I reckon, they represent the mouse events. But in my code there is no direct instruction to print them. Why are they printed to my terminal? How can this be avoided?
I use gnome-terminal on linux, not a real console, if that matters.
If the TERM environment variable is xterm, GPM won't try to open the Linux console.
Instead, it simply turns on xterm mouse-mode (which makes the terminal send escape sequences), and it turns out, expects the application to handle that rather than transforming the escape sequences into its protocol.
From ncurses' viewpoint, for instance, that makes its behavior in a terminal emulator less than useful, and the library checks for this case and ignores GPM (since 2010).
Related
I'm trying to implement a serial cli where you can type and edit a command using a console like screen/minicom. In my testing, I'm using screen to connect to the serial interface. In trying to implement a delete character option, I'm not seeing the results I'm expecting.
I've been reading online on how to use ANSI escape sequences, which I'm finding that some such as ESC c to clear screen, and ESC[?25l to hide the cursor are working with my tests. But when I try to use ESC[1D to move the cursor to the left by 1, or any other cursor escape sequences, it isn't working as I would expect.
I've read through https://www.lihaoyi.com/post/BuildyourownCommandLinewithANSIescapecodes.html and https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797 for help on how to do this right.
For an example of some test code I'm using:
void SendESC(const char *code) {
Serial.write(27);
Serial.print(code);
}
void loop() {
char byteRead = Serial.read();
if (byteRead==8) {
if (m_buffer_read!=0) {
m_buffer_read--;
m_buffer[m_buffer_read] = '\0';
SendESC("[1000D");
SendESC("[0K");
Serial.print(m_line_indicator);
Serial.print(m_buffer);
size_t lineLen = strlen(m_line_indicator)+m_buffer_read;
char buf[7];
SendESC("[1000D");
sprintf(buf, "[%dC", lineLen);
SendESC(buf);
}
}
}
In running the above test, it seems like screen does not know the escape sequences are over and it does not pick up on the updated information. I can however confirm with a hex view of the serial data received that the escape sequences are being sent exactly as I expect.
Am I missing something?
Ok, so I cheated a bit and looked at the hexadecimal output from Linux over serial. Apparently Linux is using \x08\x1b[K to tell screen to delete, and also I learned that screen sends the ASCII code 127 instead of 8 for delete. I will continue to look at what Linux uses to finish developing this. Hopefully this helps someone else trying to do the same thing.
I am able to compile and run my visual c++ program. It is not a console application. I am modifying an existing MFC application. I am trying to troubleshoot my program. I cannot run in debug and get the traces I need because my program also reads the mouse cursor. I also tried to use a messagebox to output this string, but again, a message box interferes with the mouse.
In the output window, I right-click and make sure that Program Output is enabled.
cout << "something" << endl;
However, in the output window, I do not see anything.
Looking at SO posts, I tried
std::string stro = "something ";
OutputDebugString(stro);
error C2664: 'void OutputDebugStringW(LPCWSTR)' : cannot convert
argument 1 from 'std::string' to 'LPCWSTR'
So changed to std::wstring stro
and
OutputDebugString(stro.c_str());
to append an int, I had to
std::wostringstream wso;
wso << i;
stro = stro + wso.str();
OutputDebugString(stro.c_str());
But I cannot see output in the window when not running in DEBUG. Is there any way to see output in non-DEBUG? This is surprisingly frustrating.
In the comments, writing a separate overloaded class was suggested; this seems like overkill. Java has System.out.println even in GUI programs. Android has Log.v(). Such a pity the equivalent is not available here.
Console applications have console output, which is what cout sends to. Since this isn't a console application, you'll want to try another approach. It's strange you object "I don't see Debug output when I'm not in Debug", that's the point of it - don't use OutputDebugString and expect it to be for something other than debug output.
I think the best way to understand what your application is doing, without interacting with it under the debugger (I know the frustration of trying to debug event handlers that keep being re-triggered by your debugging activities) is to try tracepoints. I blogged about them back in 2006 and they're still a great technique. Reading the mouse cursor won't interfere with tracepoints, and you can turn them on and off without rebuilding your app or making any code changes.
Set up a breakpoint, then right-click the red dot and choose When Hit. You can adjust the default message that goes into the output window to show you any values you are interested in - you can even call functions in the trace message, as you can see in the blog entry where I call the size() method of a collection. If necessary, you can even debug a release build.
Actually OutputDebugStrng should work in release builds - as long as you're running the app from the debugger. However cout cannot route output to the VS output pane.
If you already have a lot of 'cout' style debugging code, the easiest route might be to replace it with a custom ostream overload which does print to the output pane. Here's one, here's another.
If you can rewrite the debugging code completely, some macro wrappers around OutputDebugString might be better for you.
Having a stdout/stderr console window for debugging is very useful, and I always miss it when working on WinMain based apps. I use this code fragment to create a console for windows apps (and chain it in with existing loggers, etc.) After running this, your cout/cerr should work fine. OutputDebugString output can be seen outside of DevStudio using the DebugView app, but I prefer this:
#include <io.h>
#include <fcntl.h>
...
// DOS box console for stdin/stdout/stderr
void makeConsole()
{
AllocConsole();
HANDLE handle_out = GetStdHandle(STD_OUTPUT_HANDLE);
int hCrt = _open_osfhandle((long)handle_out, _O_TEXT);
FILE* hf_out = _fdopen(hCrt, "w");
setvbuf(hf_out, NULL, _IONBF, 2);
*stdout = *hf_out;
HANDLE handle_in = GetStdHandle(STD_INPUT_HANDLE);
hCrt = _open_osfhandle((long)handle_in, _O_TEXT);
FILE* hf_in = _fdopen(hCrt, "r");
setvbuf(hf_in, NULL, _IONBF, 2);
*stdin = *hf_in;
HANDLE handle_err = GetStdHandle(STD_ERROR_HANDLE);
hCrt = _open_osfhandle((long)handle_err, _O_TEXT);
FILE* hf_err = _fdopen(hCrt, "w");
setvbuf(hf_err, NULL, _IONBF, 2);
*stderr = *hf_err;
ios::sync_with_stdio();
}
I'm just starting learning C++/XAML windows store app development but for the life of me I can't find a nice way to print variable values to the "Output" window in VS2012.
Debug.WriteLine() doesn't seem to exist for Windows Store apps and I can't find a way to print other than OutputDebugString() which I can't use to print variable values (without some heavy formatting).
Is there just an easy way to print the example line:
mouse position X: 12
for example, where 12 is an integer that comes from MouseDelta.
Thanks for your time,
Poncho
Not really, no. You could write a little function that formatted like printf and passed along the resulting string to OutputDebugString() but there's nothing more straightforward available.
I guess you could use ToString(), Platform::String::operator+, and Platform::String::Data() to accomplish this; though it's a little ugly:
OutputDebugString( ("mouse position X:" + MouseDelta.X.ToString())->Data() );
Here is a nice alternative: http://seaplusplus.com/2012/06/25/printf-debugging-in-metro-style-apps/, basically it allocates a console for your Windows Store App, obviously this will fail certification but given that this may be just for debug purposes only, it will fine. I'm copying the relevant code here:
// Include Windows.h for WINBASEAPI and WINAPI:
#include <Windows.h>
// Declare AllocConsole ourselves, since Windows.h omits it:
extern "C" WINBASEAPI int WINAPI AllocConsole();
auto main(Platform::Array<Platform::String^>^) -> int
{
AllocConsole();
std::wcout << L"Hello there!" << std::endl;
std::getchar();
return EXIT_SUCCESS;
}
However if you want to see such output inside your app, then you may want to use Console Class for Modern UI Apps which implements part of the .NET System.Console and can be safely used inside Windows Store apps.
This solution uses a wrapper around OutputDebugString:
void WinLog(const wchar_t *text, int n)
{
wchar_t buf[1024];
_snwprintf_s(buf, 1024, _TRUNCATE, L"%s %d\n", text, n);
OutputDebugString(buf);
}
which can be called as follows:
WinLog(L"The Answer is", 42);
My app reading escape sequences from terminal in raw mode. And when it's running on xterm I got F2 like "\eOQ". But when it's running in linux tty terminal (Switching by Ctrl-Alt-F1) I got "\e[[[B".
What is the correct way to determine that I got F2 independent from terminal type application running on?
If you're wanting to read terminal keypresses, you likely want to look at something like libtermkey , which abstracts the general problem away for you. Internally it uses a combination of terminfo lookups, or hardcoded knowledge of the extended xterm-like model for modified keypresses, so it can understand things like Ctrl-Up, which a regular curses/etc... cannot.
while((ret = termkey_waitkey(tk, &key)) != TERMKEY_RES_EOF) {
termkey_strfkey(tk, buffer, sizeof buffer, &key, TERMKEY_FORMAT_VIM);
printf("You pressed key %s\n", buffer);
if(key.type == TERMKEY_TYPE_FUNCTION &&
!key.modifiers &&
key.code.number = 2)
printf("Got F2\n");
}
Ok, as I got the best way to use [n]curses library. It is read terminfo (termcap) database and determine what mean escape sequence you got depend on terminal type.
It is not necessary using it's terminal graphics functions. To get correct escape sequences using curses you may do the following:
newterm(NULL, stdout, stdin);
raw();
noecho();
keypad();
ch = getch();
if (ch == KEY_F(2)) printf("Got F2");
endwin();
Also, it is probably possibly do it manually by reading terminfo database in you app.
I have a simple Win32 GUI app which has an edit control in the main window. If I write:
printf("Hello world!\n");
I would like the text to appear in that control instead of the console. How to?
Update: The app is just simple window with edit control and I can compile it with or without displaying the console (gcc -mwindows). Sometimes I call an external function, which might printf() something - and I would like to catch that something and display it in the edit control. So far, SetStdHandle() seems to be closest to what I try to achieve but I cannot get it to work, yet...
Update 2:
Please, can someone tell me why this is not working and how to fix it?
HANDLE hRead, hWrite;
CreatePipe(&hRead, &hWrite, NULL, 0);
SetStdHandle(STD_OUTPUT_HANDLE, hWrite);
printf("Hello world!\n");
CloseHandle(hWrite); // Why is this needed?
DWORD dwRead;
BOOL bSuccess;
CHAR chBuf[4096];
bSuccess = ReadFile(hRead, chBuf, 4096, &dwRead, NULL); // This reads nothing :(
Also, it still prints "Hello world" to the console, I expected it not to..?
Check out the API call SetStdHandle. Once the stdout is redirected to your stream, read from it and send the text to the edit control.
[Edit]
Take a look at using dup2. The following code seems to work.
int fds[2];
_pipe (fds, 1024, O_TEXT);
_dup2 (fds[1], 1); // 1 is stdout
printf ("Test\r\n");
char buffer[100];
_flushall(); // Need to flush the pipe
int len = _read (fds[0], buffer, 100);
buffer[len] = 0; // Buffer now contains "Test\r\n"
You can do that in Windows by redirecting stdout when you create the process. You do so by setting flags and setting some handles in the STARTUPINFO structure passed to CreateProcess. See this example on MSDN for detail on how to set this up.
Once you have that setup can use ReadFile to read from the redirected stdout of the console process then send it to the edit control.
Write a internal __printf function can output the text to edit control, then replace all printf functions with that.