I am trying to get a simple console program to work in windows (it works in linux). I uses curses on linux, and when moving to windows I found that the least troublesome way port my program was to use pdcurses. I have used pdcurses before in windows, but with the win32a addon. However, I would like this program to run inside the windows console.
The problem is that it just seems to completely ignore all color commands. Is this a problem with pdcurses on windows or am I just being stupid? Even the demos that come with the package don't have color. I am using MSVC++ express 2010 on Win7 64x.
hasColors() returns TRUE. When Ii run this simple example from the documentation, everything is still in black and white:
#include <curses.h>
int main()
{
initscr();
if(has_colors() == FALSE)
{ endwin();
printf("Your terminal does not support color\n");
exit(1);
}
start_color();
init_pair(1, COLOR_BLACK, COLOR_RED);
init_pair(2, COLOR_BLACK, COLOR_GREEN);
attron(COLOR_PAIR(1));
printw("This should be printed in black with a red background!\n");
attron(COLOR_PAIR(2));
printw("And this in a green background!\n");
refresh();
endwin();
}
It may not fix anything, but I have found at times programs don't update color on GCC Codeblocks, and I add a getch(); at the end of it and it seems to fix any issues I have with color or adding text to a screen.
Make sure the getch(); is before refresh though
Aren't you missing:
attroff(COLOR_PAIR(1))
attroff(COLOR_PAIR(2))
after each print?
Add them and see what happens.
I'm using pdcurses with code::blocks under x64 win7 and I have no problems with colors. There's the off chance that only MSVC++ has this issue but I doubt it.
Related
I'm trying to develop C++ code in VS Code on a mac. I have no problems building and debugging. However, my editor is full of red ink. Is there a way to fix my editor so it is as smart as the compiler?
Here's a simple example: https://github.com/TradeIdeasPhilip/compress/tree/master/mac-os/eight. I can open this folder in VS code and build and run, but the editor is ugly.
One of the first error messages is on line 22 of EightShared.C:
const std::string preloadContents = "\xdc\xe4\xeb\xf1\xf6\xfa\xfd\xff";
This should be very straightforward. It's a string constant. I'm importing <string> through another header file. (And adding directly to the top of this file did not make a difference.) But VS code marks the first : in red and when I hover over it I see expected a ; and when I ask it to help me, it offers to disable the red squiggles.
The editor also complains about the class keyword on line 31 even though it accepts classes in other files.
The editor also complains about most (but not all) references to types like uint32_t even though I #include <stdint.h> and that works without any red ink. Here's an example from EightShared.h
Those are just a couple of samples. My editor is filled with red marks.
I'm using Microsoft's C++ extensions for VS Code. I'm guessing that one of these needs to be configured better.
Any thoughts on how to get rid of all of these red marks? Maybe a sample of a working config file or a suggestion of what I'm doing wrong? Thanks.
I eventually found a problem in my .vscode/c_cpp_properties.json file. I removed "/Library/Developer/CommandLineTools/usr/include/c++/v1" from the "includePath". Then intellisense started working again.
I have no idea how that line got into that file. I certainly didn't type it.
The change in GitHub.
Whenever I run a compiler on a bash cmd and I get an error, the command prompt changes back to 'default' like colors. It stays like this till I change it manually again.
I have tried changing "right click->properties->color" and "right click->defaults->color" and I have went where the cmd is in the file system and change the color through properties. Same problem occurs.
I am very unsure where else I could change the color to fix this problem.
System = Razerblade Steath 2017
OS = Updated Windows 10
Compilers Using = g++ and gcc (same problem on both)
Picture of how and when it occurs. The code I am running is just one line in the main function purposely giving an error.
You can use -fno-diagnostics-color on your command line to disable this. gcc tries to determine if your window supports color and it will use it to try to make the error messages easier to read. Apparently, it's not restoring the original colors correctly.
Windows command prompts stopped supporting color long ago, but that feature has recently be re-enabled in one of the Windows 10 releases.
is it possible to render to Windows' desktop (to overwrite the wallpaper)?
It wouldn´t be Windows if this was not possible, so there must be a way.
One i found out is, to call "GetDC()" with 0. But this draws on the top -
so all windows are overwriten.
I just want to overwrite the background wallpaper.
Is it possible to render there with DirectX (should be possible if with GDI+)?
Any suggestions? :)
Thanks
R
It was possible before, MS killed the feature in Vista, and it no longer works.
AVS2 (visualization library in Winamp) used IDirectDrawSurface7::Blt with DDBLT_COLORFILL flag to present stuff to desktop, with some setup code before that.
Source code. What it did.
I'm trying to create context menu using TrackPopupMenu function in my application, the code I use in it is like the following:
CMenu menu;
if (menu.LoadMenu(IDR_MENU_TRAY))
{
CMenu* pSubMenu = menu.GetSubMenu(0);
if (pSubMenu != NULL)
{
pSubMenu->ModifyMenu(IDM_CLOSE,MF_BYCOMMAND,IDM_CLOSE ,g_cfg->GetLang(TEXT_MAIN_CLOSE,"Exit(&X)"));
pSubMenu->ModifyMenu(IDM_SHOW,MF_BYCOMMAND,IDM_SHOW ,g_cfg->GetLang(TEXT_MAIN_OPEN_SHUTTER,"Open(&O)"));
CPoint point;
GetCursorPos(&point);
SetForegroundWindow();
pSubMenu->TrackPopupMenu(TPM_LEFTALIGN|TPM_RIGHTBUTTON, point.x, point.y, messageOnlyWnd);
}
}
The code runs perfect on WinXP, while on win7 and vista it doesn't. The Problem on win7 and vista is that it takes a fairly long time to pop up the menu, maybe 1 min or more. But if I turn off the Aero on win7 or vista, it runs smoothly just like on winXP, so I guess somethin must be conflicted with Aero in the code, but I just don't know how to fix it. Is there anyone can help me with that? I will appreciate it a lot if anybody helps me out.
I don't see anything wrong with this code. I've used TrackPopupMenu on Vista without any problems. The source of the problem might lie elsewhere. Try removing the call to SetForegroundWindow. If that doesn't work, try creating an empty project with just the popup menu code.
I have a Win32 console app that is showing this behavior.
1) Using VC 2005 cl to compile and link, the application works fine. What I mean by working fine is that characters above 128 display correctly according to Code Page 437.
2) When I use QT qmake to construct a project (QT += console) and SOURCES = main.c, the build goes fine and my main.exe is created. But the characters above 128, using WriteConsoleOuput function display differently (some weird characters). I have the felling that this has to do with the Code Page not being set up correctly. I did not call any QT functions, neither have I created QApplication, or QCoreApplication object. When I created QApplication Object or QCoreApplication Object, the results where the same (Not displaying the correct characters).
Is there anyway to display the characters above 128 correctly using Win32 console and QT ?
I certainly wouldn't recommend using WriteConsoleOuput if that's a Windows specific API. Qt provides an easy way to write out strings using QTextStream:
// setup
QFile f;
f.open(stdout, QIODevice::WriteOnly);
QTextStream qout(&f);
// usage
qout << tr("translate this text");
I would recommend you use UTF-8 for everything, if possible. Then you don't have to worry about the different encodings, etc. If you are required to output in your local encoding for some reason, then consider QString::fromLocal8bit().
I solved the problem by using WriteConsoleA functions.