Programming Forums > Application Development > C++

mrynit · Mar 12th, 2006, 10:09 PM

Quote:

Originally Posted by DaWei

*nix on what platform? You'll need one for each combination of OS/Hardware. If you've noticed, your QBasic statement is worthless except where it's been specifically provided for. That's the point. If you want portability, you'll have to have different code for each port. If portability isn't important, go for what you can do on the system you're targeting. It's really simple: output devices vary; their interfaces vary; the software to drive them varies. You probably aren't going to get a decent gotoxy on a braille device or an old model 28 tty, if you get what I mean. Define your problem. Solve it.

thanks for the help on that. i didnt realize the large scope of portability.

what i'm doing is making a text based version of stratego and to draw things on the screen i need spesific x,y points.

DaWei · Mar 13th, 2006, 7:18 AM

I'm going to presume that your main objective at this time is learning some things. I'm going to presume further that xy positioning is of reasonable importance, though what you learn there will not be Good Across The Board. Actually, I pointed to the resources back in post #4, because I don't consider non-portability to be Evil, just unfortunate. Despite my mentioning it twice, you haven't answered the question of "what OS/platform". Thus, at this point, there is no reasonable answer for you. (The conio in post #5, that I mentioned in post #4, generally presumes Windows and sometimes Dev-Cpp. The functions therein are easily reproduced, as I mentioned, with the Console API. If you're on Linux, you'll need something else.

mrynit · Mar 13th, 2006, 4:30 PM

Quote:

Why can't I use conio.h functions like clrsrc()?
Because conio.h is not part of the C standard. It is a Borland extension, and works only with Borland compilers (and perhaps some other commercial compilers). Dev-C++ uses GCC, the GNU Compiler Collection, as it's compiler. GCC is originally a UNIX compiler, and aims for portability and standards-compliance.

i'm using Borland 5.5, OS is winXP pro, x86 ATX hardware(how do i define that the right way?). i thouhgt that all the libraries, ect. were already ported to *nix. i'm wrong there. as for hardware, my understanding is the complire makes an exicutable file for that specific computer based on it's OS/hardware. the file will run on similar computers. like the .exe i have been making under winXP should run on win9x up to XP. when it comes to temerinal screen size are not most of them 80 X 25? that is what i have assumed in my code so far, but would it be better to deffine the size? to clarify, my target users are on moder computers running either *nix or windows(modern or close to it) using moder hardware. do i really need to address hardware for this type of program? is so what?(i'm trying to learn to be portable)

i looked up the Curses Library and for this

(Toggle Plain Text)

#include <curses.h>
int setsyx(int y, int x);

is curses.h universal throught out *nix world?

thanks for the help

DaWei · Mar 13th, 2006, 9:35 PM

Actually, my Windows screen ISN'T 25 lines, see the attached image. I adapt for that when I write my non-portable code.

The Borland compilers and assemblers that introduced the BGI and a lot of other neat tools are no longer universally available and applicable. They were designed to run under MSDOS. The modern cmd.exe and command.exe provided with, say, XP, are not really MSDOS, but 16-bit and 32-bit replacements for fundamentally the same operations. Dev-Cpp originally had much of the old Borland conio stuff, but has reduced it in the last couple of years. If you get your hands on that, you'll find that it uses the same things I'm showing you here.

One thing you'll need to do is include windows.h because of definitions it has for API types (like HANDLE, etc.). If you have a late-model .NET-centric compiler, you might not have windows.h in your include directory. You can get it from some outside source. Better yet, you can download the SDK and add its stuff to you include and library paths.

To talk to the console, you'll need a HANDLE for reading and another for writing. These handles will be to the default stdin and stdout devices. You'll no doubt be relieved to know that those are 80 x 25; you'll only need to get into those details if you want to do some different, weirder things (weird is my middle name, DaWei Weird Bubba).

I can't address your curses question with any authority.

Here's some example code.

(Toggle Plain Text)

#include <iostream>
#include <cstdlib>
#include <windows.h>

using std::cout;
using std::cin;
using std::endl;

// For messing with colors without remembering their values
typedef enum
{
    BLACK,
    BLUE,
    GREEN,
    CYAN,
    RED,
    MAGENTA,
    BROWN,
    LIGHTGRAY,
    DARKGRAY,
    LIGHTBLUE,
    LIGHTGREEN,
    LIGHTCYAN,
    LIGHTRED,
    LIGHTMAGENTA,
    YELLOW,
    WHITE
} COLORS;

// I'm going to make these global for ease of seeing what's going on.
// In my application, I actually made classes for most everything
HANDLE consoleIn;
HANDLE consoleOut;
CONSOLE_SCREEN_BUFFER_INFO screenInfo;

// For some return stuff
unsigned long ulVal;

// Write some common functions
void gotoxy (int x, int y)
{
   COORD here;
   here.X = x;
   here.Y = y;
   SetConsoleCursorPosition (consoleOut, here);
}
void erase ()
{
   COORD zip = {0, 0};

   FillConsoleOutputAttribute (consoleOut, (WORD) (LIGHTGRAY + (BLACK << 4)), 2000, zip, &ulVal);
   FillConsoleOutputCharacter (consoleOut, ' ', 2000, zip, &ulVal);
   SetConsoleCursorPosition (consoleOut, zip);
}

int whereX ()
{
    GetConsoleScreenBufferInfo (consoleOut, &screenInfo);
    return screenInfo.dwCursorPosition.X;

}

int whereY ()
{
    GetConsoleScreenBufferInfo(consoleOut, &screenInfo);
    return screenInfo.dwCursorPosition.Y;

}
int main (int argc, char *argv [])
{
   consoleIn = GetStdHandle (STD_INPUT_HANDLE);
   consoleOut = GetStdHandle (STD_OUTPUT_HANDLE);

   // At this point, you're ready to do some stuff.
   // If you'd like to find out where the cursor is, or what characters are
   // at some particular position, you're going to need some screen info.  This
   // goes in a special structure, see above.

   erase ();
   gotoxy (30, 12);
   cout << "hit";
   gotoxy (29, 12);
   cout << "S";
   gotoxy (25, 14);
   cout << "x: " << whereX () << ", y: " << whereY ();

   cin.get ();
   return 0;
}

Here's output, some blank lines removed:

(Toggle Plain Text)



                             Shit

                         x: 25, y: 14

Mar 13th, 2006, 7:18 AM	#12
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	I'm going to presume that your main objective at this time is learning some things. I'm going to presume further that xy positioning is of reasonable importance, though what you learn there will not be Good Across The Board. Actually, I pointed to the resources back in post #4, because I don't consider non-portability to be Evil, just unfortunate. Despite my mentioning it twice, you haven't answered the question of "what OS/platform". Thus, at this point, there is no reasonable answer for you. (The conio in post #5, that I mentioned in post #4, generally presumes Windows and sometimes Dev-Cpp. The functions therein are easily reproduced, as I mentioned, with the Console API. If you're on Linux, you'll need something else. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Mar 13th, 2006, 9:35 PM	#14
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Actually, my Windows screen ISN'T 25 lines, see the attached image. I adapt for that when I write my non-portable code. The Borland compilers and assemblers that introduced the BGI and a lot of other neat tools are no longer universally available and applicable. They were designed to run under MSDOS. The modern cmd.exe and command.exe provided with, say, XP, are not really MSDOS, but 16-bit and 32-bit replacements for fundamentally the same operations. Dev-Cpp originally had much of the old Borland conio stuff, but has reduced it in the last couple of years. If you get your hands on that, you'll find that it uses the same things I'm showing you here. One thing you'll need to do is include windows.h because of definitions it has for API types (like HANDLE, etc.). If you have a late-model .NET-centric compiler, you might not have windows.h in your include directory. You can get it from some outside source. Better yet, you can download the SDK and add its stuff to you include and library paths. To talk to the console, you'll need a HANDLE for reading and another for writing. These handles will be to the default stdin and stdout devices. You'll no doubt be relieved to know that those are 80 x 25; you'll only need to get into those details if you want to do some different, weirder things (weird is my middle name, DaWei Weird Bubba). I can't address your curses question with any authority. Here's some example code. (Toggle Plain Text) #include <iostream> #include <cstdlib> #include <windows.h> using std::cout; using std::cin; using std::endl; // For messing with colors without remembering their values typedef enum { BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, LIGHTGRAY, DARKGRAY, LIGHTBLUE, LIGHTGREEN, LIGHTCYAN, LIGHTRED, LIGHTMAGENTA, YELLOW, WHITE } COLORS; // I'm going to make these global for ease of seeing what's going on. // In my application, I actually made classes for most everything HANDLE consoleIn; HANDLE consoleOut; CONSOLE_SCREEN_BUFFER_INFO screenInfo; // For some return stuff unsigned long ulVal; // Write some common functions void gotoxy (int x, int y) { COORD here; here.X = x; here.Y = y; SetConsoleCursorPosition (consoleOut, here); } void erase () { COORD zip = {0, 0}; FillConsoleOutputAttribute (consoleOut, (WORD) (LIGHTGRAY + (BLACK << 4)), 2000, zip, &ulVal); FillConsoleOutputCharacter (consoleOut, ' ', 2000, zip, &ulVal); SetConsoleCursorPosition (consoleOut, zip); } int whereX () { GetConsoleScreenBufferInfo (consoleOut, &screenInfo); return screenInfo.dwCursorPosition.X; } int whereY () { GetConsoleScreenBufferInfo(consoleOut, &screenInfo); return screenInfo.dwCursorPosition.Y; } int main (int argc, char argv []) { consoleIn = GetStdHandle (STD_INPUT_HANDLE); consoleOut = GetStdHandle (STD_OUTPUT_HANDLE); // At this point, you're ready to do some stuff. // If you'd like to find out where the cursor is, or what characters are // at some particular position, you're going to need some screen info. This // goes in a special structure, see above. erase (); gotoxy (30, 12); cout << "hit"; gotoxy (29, 12); cout << "S"; gotoxy (25, 14); cout << "x: " << whereX () << ", y: " << whereY (); cin.get (); return 0; } #include <iostream> #include <cstdlib> #include <windows.h> using std::cout; using std::cin; using std::endl; // For messing with colors without remembering their values typedef enum { BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, LIGHTGRAY, DARKGRAY, LIGHTBLUE, LIGHTGREEN, LIGHTCYAN, LIGHTRED, LIGHTMAGENTA, YELLOW, WHITE } COLORS; // I'm going to make these global for ease of seeing what's going on. // In my application, I actually made classes for most everything HANDLE consoleIn; HANDLE consoleOut; CONSOLE_SCREEN_BUFFER_INFO screenInfo; // For some return stuff unsigned long ulVal; // Write some common functions void gotoxy (int x, int y) { COORD here; here.X = x; here.Y = y; SetConsoleCursorPosition (consoleOut, here); } void erase () { COORD zip = {0, 0}; FillConsoleOutputAttribute (consoleOut, (WORD) (LIGHTGRAY + (BLACK << 4)), 2000, zip, &ulVal); FillConsoleOutputCharacter (consoleOut, ' ', 2000, zip, &ulVal); SetConsoleCursorPosition (consoleOut, zip); } int whereX () { GetConsoleScreenBufferInfo (consoleOut, &screenInfo); return screenInfo.dwCursorPosition.X; } int whereY () { GetConsoleScreenBufferInfo(consoleOut, &screenInfo); return screenInfo.dwCursorPosition.Y; } int main (int argc, char argv []) { consoleIn = GetStdHandle (STD_INPUT_HANDLE); consoleOut = GetStdHandle (STD_OUTPUT_HANDLE); // At this point, you're ready to do some stuff. // If you'd like to find out where the cursor is, or what characters are // at some particular position, you're going to need some screen info. This // goes in a special structure, see above. erase (); gotoxy (30, 12); cout << "hit"; gotoxy (29, 12); cout << "S"; gotoxy (25, 14); cout << "x: " << whereX () << ", y: " << whereY (); cin.get (); return 0; } Here's output, some blank lines removed: (Toggle Plain Text) Shit x: 25, y: 14 Shit x: 25, y: 14 __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > C++

X,Y placement in console