C++ Compile error with classes and objects.

[md]

IIRC you can't handle ctrl+character like that. ctrl key combinations are used to send signals to programs, so some you won't get at all. Others I am not sure how you get them, but I'm fairly certain it's more complex then reading a character.

Instead of just getting single letter inputs you could always get word inputs, that solves the need for ctrl+key inputs. Shorter (say two or three) letter inputs would also work.

[Craige]

md wrote:

IIRC you can't handle ctrl+character like that. ctrl key combinations are used to send signals to programs, so some you won't get at all. Others I am not sure how you get them, but I'm fairly certain it's more complex then reading a character.

Instead of just getting single letter inputs you could always get word inputs, that solves the need for ctrl+key inputs. Shorter (say two or three) letter inputs would also work.

I know the ctrl + character key combinations are used to send signals to programs, and that is how I am using them. I am using them as quick 'variables' in the input.

Also, they are read like that fine. Each combination is the same as a single key input. You just have to know which ASCII codes are which combinations. The ctrl + key combinations are ASCII values 1-31. So, provided you read them and convert them right, there is nothing wrong with that.

[Craige]

Although, I didn't realize until now, I need to watch what key controls I use. ctrl + v is paste, so that should be changed. ctrl + n is generally new, but in a program like this, that won't be a factor, nor will the user expect ctrl + n to be the shortcut for new.

[OneOffDriveByPoster]

Craige wrote:

Although, I didn't realize until now, I need to watch what key controls I use. ctrl + v is paste, so that should be changed. ctrl + n is generally new, but in a program like this, that won't be a factor, nor will the user expect ctrl + n to be the shortcut for new.

Assuming Windows, Ctrl+C and Ctrl+Z may be problematic. I agree that this looks problematic.

If you are sticking to that though, you can try using this:

c++:

#define CTRL( x ) (char)( ( x ) - '@' )

[OneOffDriveByPoster]

c++:

std::string HandleCharacter ( char character, bool &quit )     {

c++:

case 4: //<ctl> + q - Quit           quit = true;         break;

What does the function return here?

c++:

std::cout << "Begin Composition:" << std::endl << std::endl;

While I would recommend against using "\n" exclusively, I would not recommend using "<< endl << endl".

c++:

while ( complete != true )       {

Why not use "!complete"?

c++:

letter = getch();

Oops. Maybe we should use std::getchar().

c++:

std::cout << this->HandleCharacter(letter, &complete);

I would be very concerned if this compiled. The function does not ask for a pointer to bool.

[Craige]

OneOffDriveByPoster wrote:

What does the function return here?

Nothing, but I should sub something in.

Quote:

c++:

std::cout << "Begin Composition:" << std::endl << std::endl;

While I would recommend against using "\n" exclusively, I would not recommend using "<< endl << endl".

Okay.

Quote:

c++:

while ( complete != true )       {

Why no
t use "!complete"?

Why not use '!=' ? It's not like it's bad practice. != is just my style.

Quote:

c++:

letter = getch();

Oops. Maybe we should use std::getchar().

I know getch() and the conio library arn't standard, but that's not to be said they can't be used. I'm using getch because as far as I know, there is not unbuffered character input in C++ that is standard. I need the unbuffered input because of the quick key replacements for words and functions.

Quote:

c++:

std::cout << this->HandleCharacter(letter, &complete);

I would be very concerned if this compiled. The function does not ask for a pointer to bool.

I don't remember if it did or not, but I don't have it as that now.

[md]

ctrl+key presses are filtered from input and sent as signals through a different IPC method. I'm sure there is a way to change that, but by default things like ctrl-c will kill your program (or should... windows is dumb).

[wtd]

If you're going to make your programs Windows-specific that's fine, though you'll probably find people here less than enthusiastic about your code.

Also, you may find it useful, if you plan to go the Windows-specific route, to skip all of this conio crap and learn the Win32 API when you need low-level stuff, and C#/.NET for the high-level stuff.

As for things like "!complete"... that was suggested because it more directly expresses the logic at work. It would be aided by a better variable name than "complete". A better variable name might be something like "is_complete", which includes not just a verb or state word, but also a word which indicates its boolean nature without resorting to something silly like Hungarian notation.

[Craige]

wtd wrote:

If you're going to make your programs Windows-specific that's fine, though you'll probably find people here less than enthusiastic about your code.

Who said I was going platform specific? That is not my intention at all. That is the furthest from it.

Quote:

Also, you may find it useful, if you plan to go the Windows-specific route, to skip all of this conio crap and learn the Win32 API when you need low-level stuff, and C#/.NET for the high-level stuff.

See the above comment.

Quote:

As for things like "!complete"... that was suggested because it more directly expresses the logic at work. It would be aided by a better variable name than "complete". A better variable name might be something like "is_complete", which includes not just a verb or state word, but also a word which indicates its boolean nature without resorting to something silly like Hungarian notation.

I see what you mean, but I have always found the != operator to be clearer. I don't know why.