perror always prints in red - using stderr / cerr .
Maybe I should just switch from cout to cerr to output in red,
Please observe that escape codes, which are still ignored, are printed instead of being reacted on.
That is THE ISSUE, the usage of while is NOT related to the issue at all.
I believe this is related either to complier or operating system.
I am searching for a solution in that direction for now.
Any other suggestions are welcome.
cout << "Function: " << __FUNCTION__ << endl;
cout << " START test area " << __LINE__ << endl;
errno = 0;
perror("TEST perror "); // default print in red
perror("\033[1;31mTEST perror "); // print the error details in red
cout << "\033[0m\n"; // restore to standard colours
errno = 5;
perror("\033[1;31mTEST perror ");
cout << "\033[0m\n";
printf("%c[%dmHELLO!\n", 0x1B, 32);
const std::string red("\033[0;31m");
cout << red << "red text" << endl;
std::cout << "\t\t\t Hello World" << std::endl;
cout << "Bluetooth client " << endl;
cout << " START test area " << dec << __LINE__ << endl;
cout << __FUNCTION__ << endl;
START test area 39
TEST perror : Success
[1;31mTEST perror : Invalid argument
[1;31mTEST perror : Input/output error
sh: 1: Color: not found
sh: 1: Hello World
START test area 58
set color @line [31m 443
set color @line [31m 449
PROGREESS TRACE START
Taking your code above and running it produces the following output:
START test area 17
TEST perror : No error --> in normal black
TEST perror : No error --> in bold red
TEST perror : Input/output error --> in bold red
HELLO! --> in green
red text --> everything from here in normal red
START test area 36
Which does not match with what you have produced. I can only conclude that there is something else going on in your system, or the actual code you run is different, that you are not telling us about.
Yet another "problem" got me stumped.
To verify "networking" I use system call such as
It does the job, however, I cannot figure out how to close the file.
The standard "vim" way is "Esc :q!" , and it is unclear which character should be "send" via standard console and which ones after responses from vim.
Either manually (cin) or as a string starting with "Esc".
I wondered about that too: if the point is just to verify that you can access a certain file across a network file path, then trying to open it with fstream::open() should do the job.
Whereas, emulating console input that is supposed to be passed into an external process would be kind of tricky, to say the least...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I am getting used to using cout, despite of its irrational behaviour.
In my main project I went overboard with debugging colouring scheme and it sort of works.
I just started the "client" part of the project and reusing a class from my main project where cout colouring and cout lines work just as expected.
In derived project - no coloring, cout lines have extra line feed and I am getting non printable characters to boot.
Just another bug to find.
I am finding out this setw does not always work....
I have a bitmap file of a red bullet Originally I tried to display it using RichEdit Ole Interface I copied the code modified it somewhat from
the "Q220844: HOWTO: Insert a Bitmap Into RTF Document Using RichEdit Control" I was able to display it however it didn't fit quite right
So I decided to go with a native Win32 and display on Static control adjacent to the rich edit
Thing is where the OleCreateFromFile worked the LoadImage API fails GetLastError return a zero as well using File Explorer I can see the red bullet
So much confusion and misunderstandings to know where to start.
Lets start with SetSel misunderstanding which starts at 0 NOT 1 it is a zero-based index.
Very important is the file type you didn't say what the file was look at the last 3 letters of the filename is it BMP, GIF, JPG or PNG?
Yes if you have a white border the white border will be on the image UNLESS it is a transparent image which needs a special header and depends on file format (so again we need the file format).
You said you change the code over to LoadImage and I warned you that you can only load files that are of BMP and PCX type. That is files that end with those 3 letters and have a proper matching header. If you try to load a wrong type it does pretty much what you describe returns NULL with a GetLastError of 0 because it can find the file but it's just junk it can't understand.
So can we at least get a filetype to start with so we know what we are dealing with, so 3 letter filename extension please. If you can't see them on windows go up to view settings and tick the box that says file name extensions.
In vino veritas
Last Visit: 31-Dec-99 18:00 Last Update: 13-May-21 19:26