bonjour
Ayant (eu) une petite habitude des SGBD et Basic, j'ai toujours pu accèder à
tous les points de l'écran.
Et là :-(( plus rien. Je me sens un peu manchot.
J'ai d'intéressants exercices mais basés certainement sur des turbo C++ sous
dos, faisant appel à la fonction gotoxy().
Comment la remplacant en mode console sous windows ?
note : je commence tout juste à étudier la classe point avec initialisation,
déplacement et affichage.
renote à l'attention de 'je ne sais plus qui' futur auteur : ça me parait un
super exemple pour l'étude.
Si tu veux etre le + abstrait possible, crée-toi une interface (une classe abstraite C++) comme ceci, par exemple :
class iEcran { public: void SetPixel(int x,int y)=0; void Rectangle( int x1, int x2, int y1, int y2)=0; etc... };
dans tes programmes tu utilises pour "dessiner" une instance polymorphe de cette interface (donc un pointeur sur iEcran ou une référence sur iEcran) mais que tu initialises avec une classe dérivée, spécialisée pour ton système, par exemple : class EcranWin32 : public iEcran { HANDLE Hwnd; public: EcranWin32(HANDLE H):Hwnd(H){} void SetPixel(int x,int y) { ::HDC hdc = ::GetDC(Hwnd); ::SetPixel(hdc,x,y); ::ReleaseDC(hdc); } etc... };
Et nous voilà sous windows. Je voulais éviter les interfaces graphiques, mais rien n'est facile avec mes compétences. Bon va falloir digèrer tous ça. En tous cas merci à tous. Christophe
"Alexandre" <alex.g@netcourrier.com> a écrit
Si tu veux etre le + abstrait possible, crée-toi une interface (une classe
abstraite C++) comme ceci, par exemple :
class iEcran
{
public:
void SetPixel(int x,int y)=0;
void Rectangle( int x1, int x2, int y1, int y2)=0;
etc...
};
dans tes programmes tu utilises pour "dessiner" une instance polymorphe de
cette interface (donc un pointeur sur iEcran ou une référence sur iEcran)
mais que tu initialises avec une classe dérivée, spécialisée pour ton
système, par exemple :
class EcranWin32 : public iEcran
{
HANDLE Hwnd;
public:
EcranWin32(HANDLE H):Hwnd(H){}
void SetPixel(int x,int y)
{
::HDC hdc = ::GetDC(Hwnd);
::SetPixel(hdc,x,y);
::ReleaseDC(hdc);
}
etc...
};
Et nous voilà sous windows. Je voulais éviter les interfaces graphiques,
mais rien n'est facile avec mes compétences. Bon va falloir digèrer tous ça.
En tous cas merci à tous.
Christophe
Si tu veux etre le + abstrait possible, crée-toi une interface (une classe abstraite C++) comme ceci, par exemple :
class iEcran { public: void SetPixel(int x,int y)=0; void Rectangle( int x1, int x2, int y1, int y2)=0; etc... };
dans tes programmes tu utilises pour "dessiner" une instance polymorphe de cette interface (donc un pointeur sur iEcran ou une référence sur iEcran) mais que tu initialises avec une classe dérivée, spécialisée pour ton système, par exemple : class EcranWin32 : public iEcran { HANDLE Hwnd; public: EcranWin32(HANDLE H):Hwnd(H){} void SetPixel(int x,int y) { ::HDC hdc = ::GetDC(Hwnd); ::SetPixel(hdc,x,y); ::ReleaseDC(hdc); } etc... };
Et nous voilà sous windows. Je voulais éviter les interfaces graphiques, mais rien n'est facile avec mes compétences. Bon va falloir digèrer tous ça. En tous cas merci à tous. Christophe
Fabien LE LEZ
On Thu, 18 Dec 2003 16:02:51 +0100, "Christophe" wrote:
Comment faitent vous pour afficher un mot à tel endroit en C++ pur ?
Sur pas mal de machines, on ne peut pas. Ce genre de trucs est réservé aux machines disposant d'un écran (sauf peut-être les machines auxquelles on accède par Telnet ? Je ne sais plus si ce protocole permet le positionnement du curseur) [exit l'embarqué] pouvant fonctionner en mode texte [exit les Mac]. De plus le programme ne supporte alors plus les redirections. Sous Windows à l'heure actuelle, seuls sont utilisés des programmes en mode graphique (beaucoup plus puissant et agréable et pas beaucoup plus compliqué que le mode pseudo-graphique du DOS) en mode texte via les flux standard (l'entrée standard, qui peut être le clavier, un fichier, la sortie standard d'un autre programme, etc. ; la sortie standard, qui peut être l'écran, un fichier, l'entrée standard d'un autre programme, etc. ; et le flux d'erreur).
-- ;-)
On Thu, 18 Dec 2003 16:02:51 +0100, "Christophe"
<chrschneider@free.fr> wrote:
Comment faitent vous pour afficher un mot à tel endroit en C++ pur ?
Sur pas mal de machines, on ne peut pas. Ce genre de trucs est réservé
aux machines disposant d'un écran (sauf peut-être les machines
auxquelles on accède par Telnet ? Je ne sais plus si ce protocole
permet le positionnement du curseur) [exit l'embarqué] pouvant
fonctionner en mode texte [exit les Mac]. De plus le programme ne
supporte alors plus les redirections.
Sous Windows à l'heure actuelle, seuls sont utilisés des programmes en
mode graphique (beaucoup plus puissant et agréable et pas beaucoup
plus compliqué que le mode pseudo-graphique du DOS) en mode texte via
les flux standard (l'entrée standard, qui peut être le clavier, un
fichier, la sortie standard d'un autre programme, etc. ; la sortie
standard, qui peut être l'écran, un fichier, l'entrée standard d'un
autre programme, etc. ; et le flux d'erreur).
On Thu, 18 Dec 2003 16:02:51 +0100, "Christophe" wrote:
Comment faitent vous pour afficher un mot à tel endroit en C++ pur ?
Sur pas mal de machines, on ne peut pas. Ce genre de trucs est réservé aux machines disposant d'un écran (sauf peut-être les machines auxquelles on accède par Telnet ? Je ne sais plus si ce protocole permet le positionnement du curseur) [exit l'embarqué] pouvant fonctionner en mode texte [exit les Mac]. De plus le programme ne supporte alors plus les redirections. Sous Windows à l'heure actuelle, seuls sont utilisés des programmes en mode graphique (beaucoup plus puissant et agréable et pas beaucoup plus compliqué que le mode pseudo-graphique du DOS) en mode texte via les flux standard (l'entrée standard, qui peut être le clavier, un fichier, la sortie standard d'un autre programme, etc. ; la sortie standard, qui peut être l'écran, un fichier, l'entrée standard d'un autre programme, etc. ; et le flux d'erreur).
-- ;-)
kanze
Fabien LE LEZ wrote in message news:...
On Thu, 18 Dec 2003 16:02:51 +0100, "Christophe" wrote:
Comment faitent vous pour afficher un mot à tel endroit en C++ pur ?
Sur pas mal de machines, on ne peut pas.
Sur pas mal de machines, on n'a pas de fichiers disque non-plus. Ni des horloges temps réels (fonction standard time, etc.).
Je ne crois pas que ce soit un argument aujourd'hui.
Ce genre de trucs est réservé aux machines disposant d'un écran (sauf peut-être les machines auxquelles on accède par Telnet ? Je ne sais plus si ce protocole permet le positionnement du curseur)
[HS: telnet est assez transparent à cet égard. Si tu l'invoques sur un terminal qui comprend des séquences d'échappement, et ton application sait les envoyer, telnet les transmettra. Je me suis déjà servi de vi sur telnet, souvent même.]
[exit l'embarqué] pouvant fonctionner en mode texte [exit les Mac].
Tu ne peux pas ouvrir un xterm sur un Mac ? Ça m'étonnerait un peu.
De plus le programme ne supporte alors plus les redirections. Sous Windows à l'heure actuelle, seuls sont utilisés des programmes en mode graphique (beaucoup plus puissant et agréable et pas beaucoup plus compliqué que le mode pseudo-graphique du DOS) en mode texte via les flux standard (l'entrée standard, qui peut être le clavier, un fichier, la sortie standard d'un autre programme, etc. ; la sortie standard, qui peut être l'écran, un fichier, l'entrée standard d'un autre programme, etc. ; et le flux d'erreur).
Je crois que la question est beaucoup plus complex que ça. Pratiquement parlant, tous les arguments de ce genre qu'on présentent vaudrait également pour les fichiers. Les vraies raisons tienent plus de l'histoire et de la « culture » C.
Mais je te donne raison qu'aujoud'hui, standardiser quelque chose comme curses n'a pas de sens, son utilité pratique étant assez limitée suite à la généralisation des interfaces graphiques. Mais je me démande que si on commencait de rien, on ne pourrait pas dire à peu près la même chose en ce qui concerne les flux en général -- ils ne se mappent pas particulièrement bien ni aux interfaces graphiques ni aux bases de données. (Ils se mappent même assez mal aux fichiers disque classiques sur la plupart des systèmes historiques.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<jhg4uvs57en648n3ncclt9ucih2j22qrad@4ax.com>...
On Thu, 18 Dec 2003 16:02:51 +0100, "Christophe"
<chrschneider@free.fr> wrote:
Comment faitent vous pour afficher un mot à tel endroit en C++ pur ?
Sur pas mal de machines, on ne peut pas.
Sur pas mal de machines, on n'a pas de fichiers disque non-plus. Ni des
horloges temps réels (fonction standard time, etc.).
Je ne crois pas que ce soit un argument aujourd'hui.
Ce genre de trucs est réservé aux machines disposant d'un écran (sauf
peut-être les machines auxquelles on accède par Telnet ? Je ne sais
plus si ce protocole permet le positionnement du curseur)
[HS: telnet est assez transparent à cet égard. Si tu l'invoques sur un
terminal qui comprend des séquences d'échappement, et ton application
sait les envoyer, telnet les transmettra. Je me suis déjà servi de vi
sur telnet, souvent même.]
[exit l'embarqué] pouvant fonctionner en mode texte [exit les Mac].
Tu ne peux pas ouvrir un xterm sur un Mac ? Ça m'étonnerait un peu.
De plus le programme ne supporte alors plus les redirections. Sous
Windows à l'heure actuelle, seuls sont utilisés des programmes en mode
graphique (beaucoup plus puissant et agréable et pas beaucoup plus
compliqué que le mode pseudo-graphique du DOS) en mode texte via les
flux standard (l'entrée standard, qui peut être le clavier, un
fichier, la sortie standard d'un autre programme, etc. ; la sortie
standard, qui peut être l'écran, un fichier, l'entrée standard d'un
autre programme, etc. ; et le flux d'erreur).
Je crois que la question est beaucoup plus complex que ça. Pratiquement
parlant, tous les arguments de ce genre qu'on présentent vaudrait
également pour les fichiers. Les vraies raisons tienent plus de
l'histoire et de la « culture » C.
Mais je te donne raison qu'aujoud'hui, standardiser quelque chose comme
curses n'a pas de sens, son utilité pratique étant assez limitée suite à
la généralisation des interfaces graphiques. Mais je me démande que si
on commencait de rien, on ne pourrait pas dire à peu près la même chose
en ce qui concerne les flux en général -- ils ne se mappent pas
particulièrement bien ni aux interfaces graphiques ni aux bases de
données. (Ils se mappent même assez mal aux fichiers disque classiques
sur la plupart des systèmes historiques.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
On Thu, 18 Dec 2003 16:02:51 +0100, "Christophe" wrote:
Comment faitent vous pour afficher un mot à tel endroit en C++ pur ?
Sur pas mal de machines, on ne peut pas.
Sur pas mal de machines, on n'a pas de fichiers disque non-plus. Ni des horloges temps réels (fonction standard time, etc.).
Je ne crois pas que ce soit un argument aujourd'hui.
Ce genre de trucs est réservé aux machines disposant d'un écran (sauf peut-être les machines auxquelles on accède par Telnet ? Je ne sais plus si ce protocole permet le positionnement du curseur)
[HS: telnet est assez transparent à cet égard. Si tu l'invoques sur un terminal qui comprend des séquences d'échappement, et ton application sait les envoyer, telnet les transmettra. Je me suis déjà servi de vi sur telnet, souvent même.]
[exit l'embarqué] pouvant fonctionner en mode texte [exit les Mac].
Tu ne peux pas ouvrir un xterm sur un Mac ? Ça m'étonnerait un peu.
De plus le programme ne supporte alors plus les redirections. Sous Windows à l'heure actuelle, seuls sont utilisés des programmes en mode graphique (beaucoup plus puissant et agréable et pas beaucoup plus compliqué que le mode pseudo-graphique du DOS) en mode texte via les flux standard (l'entrée standard, qui peut être le clavier, un fichier, la sortie standard d'un autre programme, etc. ; la sortie standard, qui peut être l'écran, un fichier, l'entrée standard d'un autre programme, etc. ; et le flux d'erreur).
Je crois que la question est beaucoup plus complex que ça. Pratiquement parlant, tous les arguments de ce genre qu'on présentent vaudrait également pour les fichiers. Les vraies raisons tienent plus de l'histoire et de la « culture » C.
Mais je te donne raison qu'aujoud'hui, standardiser quelque chose comme curses n'a pas de sens, son utilité pratique étant assez limitée suite à la généralisation des interfaces graphiques. Mais je me démande que si on commencait de rien, on ne pourrait pas dire à peu près la même chose en ce qui concerne les flux en général -- ils ne se mappent pas particulièrement bien ni aux interfaces graphiques ni aux bases de données. (Ils se mappent même assez mal aux fichiers disque classiques sur la plupart des systèmes historiques.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
kanze
"Christophe" wrote in message news:<3fe1cfd0$0$29074$...
"Martinez Jerome" a écrit dans
De plus, ton besoin n'est pas le besoin d'un autre dans 90% des cas : personnelement, meme en interface texte je n'ai jamais eu besoin de ca. Ca fait donc un cas tellement spécifique que si il était intégré a la norme, d'autres choses pourraient l'etre aussi. Trop de choses.
Je n'en doute pas
J'aimerais bien resté en C++ pur...
Developpe sans cette fonction, je te promet qu'on s'en apsse très bien. Ou passe en mode graphique, ca sera mieux que du texte que tu formate dans tous les sens (mais sans C++ pur non plus, sauf que des API multi-platefomres existent : ncurses, wxwindows...)
Mais sans vouloir être indiscret, quelles sont les applications créées aujourd'hui n'ayant 'in fine' pas interface graphique et à affichage quasi séquentiel ?
Il y a énormement d'applications sans le moindre affichage sur un écran. Tous les serveurs, par exemple, et tous les applications embarquées. En plus de trente ans de programmation, je n'ai travaillé que sur une seule application interactive.
Évidemment, les serveurs se servent d'autres choses non-standard : les sockets, les bases de données, etc.
En fait, la seule chose que je trouve dans à peu près toutes les applications, ce sont des fichiers de log ou de configuration. Chose pour laquelle les flux standard font très bien l'affaire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Christophe" <chrschneider@free.fr> wrote in message
news:<3fe1cfd0$0$29074$636a55ce@news.free.fr>...
"Martinez Jerome" <jerome.martinez@aenlever-orangefrance.com> a écrit dans
De plus, ton besoin n'est pas le besoin d'un autre dans 90% des cas
: personnelement, meme en interface texte je n'ai jamais eu besoin
de ca. Ca fait donc un cas tellement spécifique que si il était
intégré a la norme, d'autres choses pourraient l'etre aussi. Trop de
choses.
Je n'en doute pas
J'aimerais bien resté en C++ pur...
Developpe sans cette fonction, je te promet qu'on s'en apsse très
bien. Ou passe en mode graphique, ca sera mieux que du texte que tu
formate dans tous les sens (mais sans C++ pur non plus, sauf que des
API multi-platefomres existent : ncurses, wxwindows...)
Mais sans vouloir être indiscret, quelles sont les applications créées
aujourd'hui n'ayant 'in fine' pas interface graphique et à affichage
quasi séquentiel ?
Il y a énormement d'applications sans le moindre affichage sur un
écran. Tous les serveurs, par exemple, et tous les applications
embarquées. En plus de trente ans de programmation, je n'ai travaillé
que sur une seule application interactive.
Évidemment, les serveurs se servent d'autres choses non-standard : les
sockets, les bases de données, etc.
En fait, la seule chose que je trouve dans à peu près toutes les
applications, ce sont des fichiers de log ou de configuration. Chose
pour laquelle les flux standard font très bien l'affaire.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Christophe" wrote in message news:<3fe1cfd0$0$29074$...
"Martinez Jerome" a écrit dans
De plus, ton besoin n'est pas le besoin d'un autre dans 90% des cas : personnelement, meme en interface texte je n'ai jamais eu besoin de ca. Ca fait donc un cas tellement spécifique que si il était intégré a la norme, d'autres choses pourraient l'etre aussi. Trop de choses.
Je n'en doute pas
J'aimerais bien resté en C++ pur...
Developpe sans cette fonction, je te promet qu'on s'en apsse très bien. Ou passe en mode graphique, ca sera mieux que du texte que tu formate dans tous les sens (mais sans C++ pur non plus, sauf que des API multi-platefomres existent : ncurses, wxwindows...)
Mais sans vouloir être indiscret, quelles sont les applications créées aujourd'hui n'ayant 'in fine' pas interface graphique et à affichage quasi séquentiel ?
Il y a énormement d'applications sans le moindre affichage sur un écran. Tous les serveurs, par exemple, et tous les applications embarquées. En plus de trente ans de programmation, je n'ai travaillé que sur une seule application interactive.
Évidemment, les serveurs se servent d'autres choses non-standard : les sockets, les bases de données, etc.
En fait, la seule chose que je trouve dans à peu près toutes les applications, ce sont des fichiers de log ou de configuration. Chose pour laquelle les flux standard font très bien l'affaire.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Alexandre
Et nous voilà sous windows. Je voulais éviter les interfaces graphiques, mais rien n'est facile avec mes compétences. Bon va falloir digèrer tous ça.
En tous cas merci à tous. Christophe
Si tu veux éviter une interface graphique, fais du mode console, mais alors
tu ne pourras pas controler un pixel de l'écran... ça dépend de ce que tu veux faire exactement...
Et nous voilà sous windows. Je voulais éviter les interfaces graphiques,
mais rien n'est facile avec mes compétences. Bon va falloir digèrer tous
ça.
En tous cas merci à tous.
Christophe
Si tu veux éviter une interface graphique, fais du mode console, mais alors
tu ne pourras pas controler un pixel de l'écran...
ça dépend de ce que tu veux faire exactement...
Pas d'accord, il peut toujours coder en asm et inclure ca dans le code...
Fin bon c'est lourd et laborieux mais ca devrait marcher
(ndlr : faut voir si windows autorise toujours d'aller chipoter avec les interruptions du bios et à accéder au matos directement...)
Si tu veux éviter une interface graphique, fais du mode console, mais alors
tu ne pourras pas controler un pixel de l'écran... ça dépend de ce que tu veux faire exactement...
Christophe
"Vaguener Frank" a écrit
(ndlr : faut voir si windows autorise toujours d'aller chipoter avec les interruptions du bios et à accéder au matos directement...)
tu ne pourras pas controler un pixel de l'écran...
Je crois savoir que l'accès direct à la mémoire vidéo par l'adresse A000:000 n'est plus possible contrairement à Dos. La chose est interdite, même en assembleur je crois. a+ Christophe
"Vaguener Frank" <fvaguener@hotmail.com> a écrit
(ndlr : faut voir si windows autorise toujours d'aller chipoter avec les
interruptions du bios et à accéder au matos directement...)
tu ne pourras pas controler un pixel de l'écran...
Je crois savoir que l'accès direct à la mémoire vidéo par
l'adresse A000:000 n'est plus possible contrairement à Dos.
La chose est interdite, même en assembleur je crois.
a+
Christophe
(ndlr : faut voir si windows autorise toujours d'aller chipoter avec les interruptions du bios et à accéder au matos directement...)
tu ne pourras pas controler un pixel de l'écran...
Je crois savoir que l'accès direct à la mémoire vidéo par l'adresse A000:000 n'est plus possible contrairement à Dos. La chose est interdite, même en assembleur je crois. a+ Christophe
