WinAPI Tutorials diskussion
Henno Buschmann
ok, dann lege ich mal los :-).
1.) Ich möchte, wenn ich eine neue Funktion einführe, einen Link zum
MSDN machen. Nun kann ich dort aber die Seite einmal im "Fullscreen"
anzeigen lassen, oder ich linke mit dem Rahmen und der Navigation usw.
dazu. Der Fullscreen hat den Vorteil, dass die Seite schnell geladen
ist. Wenn man dies öfter in einem Tutorial machen muss, ist es schon
wichtig. Andererseits soll der Anfänger auch mit dem MSDN vertraut
werden, denn es ist ja schließlich die Hauptinformatinsquelle. Stört es
so sehr, dass man Online gehen muss, um nun die Referenz des MSDN
anschauen zu können (also direkt durch den Link)?
Ich habe ja flatrate ;-), aber mancheiner zahlt da Bares Geld.
Meine Seiten sind ja auf Deutsch. Nun muss man aber für das MSDN
Englisch können. Ich finde es aber dringend notwendig, dass man Englisch
beherscht und sich im MSDN zurechtfindet.
Kurz:
- Links zum MSDN mit Rahmen oder ohne?
- Ist das linken auf Onlineseiten zu verkrafen?
- Muss das MSDN übersetzt werden?
2.) Ich bekam mal von jemandem eine Mail, dass es vielleicht Sinnvoll
wäre als zweites Tutorial (nach dem MessageBox Programm) ein Fenster aus
einer Button Windows Klasse zu erzeugen. Damit würde man den Anfänger
noch ein Tutorial von der Registrierung einer Fensterklasse fernhalten.
Man führt jedoch schon die Buttonklasse ein, was ich als größeres Übel
sehe.
Kurz:
- als zweites Tutorial ein Button?
3.)Ist Syntax Highleighting auf der Homepage wichtig? Da meine Seite
auch ein bisschen dem Design unterliegt :-), ist erstens der Code in
Hellblau (auf Schwarz) und zweitens würde ein rot oder grün das ganze
aus dem (Farb)konzept werfen.
Kurz:
- ist Syntax Highlighting auf der Homepage wichtig?
4.)Ist es Sinn voller die Zeile const char szAppName[] = "Programmname";
global zu definieren oder so lokal wie es geht. Über dies bin ich mir
schon lange nicht einig. Einerseits sollen Variablen so lokal wie
möglich sein, aber andererseits soll es dem Anfänger einheitlich gemacht
werden. Denn ich habe gerade eine Übung geschrieben, in der man
szAppName auch in der WndProc Funktion brauchte und nicht nur in der
WinMain.
Kurz:
- const char szAppName lokal oder global?
5.)Das mag jetzt vielleicht ein wenig kleinlich wirken. Aber wie soll
ich die Datei nennen, die als einzige zu dem Windows API Projekt gehört.
Ich bin dazu übergegangen sie nicht wie der Name des Projekts zu
bennenen, sonder WinMain.cpp. Das hat auch den Vorteil, dass ich die
makefile für den BC nicht so stark anpassen muss.
Kurz:
- Name der Hauptdatei?
6.)Dann finde ich die Überschrift von Tutorial 3 sehr unpassend "Text im
Anwendungsbereich". Dabei geht es Hauptsächlich um das Vorstellen von
WM_PAINT und BeginPaint/EndPaint usw. Die TextOut Zeile kommt zwar auch
vor, aber...
Kurz:
- Wie soll das 3. Tutorial heißen?
7.)Was meint ihr, sollen die Tutorials benutzen? C oder C++. Ich
persönlich würde C++ aber ohne die Objektorientierung bevorzugen, denn
das hat doch seine Vorteile. Ich könnte dann in einer Übung (Teile das
minimale Fenster in drei Funktionen auf) die Funktionen CreateWindow und
RegisterClass überladen.
Kommentare al á C++ mache ich ja schon länger. Aber auch das deklarieren
der Variablen mitten in einem Block wäre nicht erlaubt. struct müsste
vor jede Struktur usw.
Und wenn man sich für C++ entscheidet muss dann in jedes Projekt
typedef 0 NULL;
oder #define STRICT
Kurz:
- C++ (ohne OOP) oder C?
8.)Ist es in fast allen Fällen davon abzuraten, festes Koordinatensystem
zu benutzen?
Ich bedanke mich für die rege Diskussion,
--
Henno Buschmann * Loggy...@gmx.de
Windows API Programmierung (Tutorials/Referenz):
http://www.Loggy.de.st/
Edzard Egberts
"Henno Buschmann" <Loggy...@gmx.de> schrieb im Newsbeitrag
news:3A31184F...@gmx.de...
> Hallo,
>
> ok, dann lege ich mal los :-).
>
> 1.) Ich möchte, wenn ich eine neue Funktion einführe, einen Link zum
> MSDN machen. Nun kann ich dort aber die Seite einmal im "Fullscreen"
> anzeigen lassen, oder ich linke mit dem Rahmen und der Navigation usw.
> dazu. Der Fullscreen hat den Vorteil, dass die Seite schnell geladen
> ist. Wenn man dies öfter in einem Tutorial machen muss, ist es schon
> wichtig. Andererseits soll der Anfänger auch mit dem MSDN vertraut
> werden, denn es ist ja schließlich die Hauptinformatinsquelle. Stört es
> so sehr, dass man Online gehen muss, um nun die Referenz des MSDN
> anschauen zu können (also direkt durch den Link)?
Das Problem ist mir nicht ganz klar - _muss_ man online gehen um das
Tutorial zu verstehen, so dass der Link wichtige Informationen ersetzt?
Das erscheint mir nicht als besonders gute Idee.
Wenn die MSDN dagegen nur als weiterführende Referenz angegeben wird, sehe
ich überhaupt kein Problem - wenn man es nicht auf CD hat, muss man eben
online gehen - das Leben ist hart!
> Ich habe ja flatrate ;-), aber mancheiner zahlt da Bares Geld.
Wusste gar nicht, dass die Flatrate umsonst ist. ;-)
> Meine Seiten sind ja auf Deutsch. Nun muss man aber für das MSDN
> Englisch können. Ich finde es aber dringend notwendig, dass man Englisch
> beherscht und sich im MSDN zurechtfindet.
Wer programmiert muss Englisch können - die meisten wichtigen
Informationen im Netz sind auf Englisch und meistens bleibt einem nichts
anderes übrig als sich da durchzukämpfen und das muss man eben üben.
Noch ein anderer praktischer Aspekt - wer soll denn 1,5 _Giga_byte
Informationen übersetzen?
> 2.) Ich bekam mal von jemandem eine Mail, dass es vielleicht Sinnvoll
> Kurz:
> - als zweites Tutorial ein Button?
Ächz - schwierig zu entscheiden. Manchmal hilft es, einfach mit
irgendetwas anzufangen und hinterher zu sortieren...
> Kurz:
> - ist Syntax Highlighting auf der Homepage wichtig?
*g* nur wenn Du es so machst, wie ich es gewohnt bin (Ein Operator muss
z.B. _rot_ sein ;-) - ansonsten übernehme ich das lieber kurz in den
Compiler, was ja auch unter anderen Gesichtspunkten sinnvoll ist.
> 4.)Ist es Sinn voller die Zeile const char szAppName[] = "Programmname";
> global zu definieren oder so lokal wie es geht. Über dies bin ich mir
> schon lange nicht einig. Einerseits sollen Variablen so lokal wie
> möglich sein
Genau!
>, aber andererseits soll es dem Anfänger einheitlich gemacht
> werden.
Naja, ein grösserer Geist als ich sagte einmal "So einfach wie möglich,
aber nicht einfacher" (Oder so ähnlich ;-).
Einheitlich hin und her, IMHO wird dem Anfänger kein guter Dienst
erwiesen, wenn ausgerechnet ein Tutorial die "quick and dirty"-Lösung
vorstellt - man sollte da eher darauf eingehen, wie solche Infos
vernünftig übergeben werden. Andererseits ist das eher der
objektorientierte C++-Ansatz und in einem reinen C-Programm sind globale
Variablen AFAIK die Regel - vielleicht löst sich dieses Problem von
selber, wenn Du Dich konsequent für eine Sprache und einen Programmierstil
entscheidest.
<snip wegen auch keiner Idee >
> 6.)Dann finde ich die Überschrift von Tutorial 3 sehr unpassend "Text im
> Anwendungsbereich". Dabei geht es Hauptsächlich um das Vorstellen von
> WM_PAINT und BeginPaint/EndPaint usw. Die TextOut Zeile kommt zwar auch
> vor, aber...
> Kurz:
> - Wie soll das 3. Tutorial heißen?
"Ausgaben im Fenster" hätte ich als Vorschlag anzubieten.
> 7.)Was meint ihr, sollen die Tutorials benutzen? C oder C++.
Keine Ahnung - konsequent wäre C für eine C-Schnittstelle (sonst könntest
Du ja gleich ein MFC-Tutorial machen), allerdings musste ich kürzlich ein
C-Programm schreiben und fand das grauenhaft! C++ ist dagegen wunderhübsch
und für den PC-Bereich ist ein reiner C-Compiler doch eher selten
geworden.
Zu einem objektiven Urteil sehe ich mich nicht in der Lage, subjektiv bin
ich C++-Fan!
> 8.)Ist es in fast allen Fällen davon abzuraten, festes Koordinatensystem
> zu benutzen?
Häh???
Gruss,
Ed
Henno Buschmann
Edzard Egberts schrieb:
> "Henno Buschmann" <Loggy...@gmx.de> schrieb im Newsbeitrag
Danke für deine Antwort :-)
> > 1.) Ich möchte, wenn ich eine neue Funktion einführe, einen Link zum
> > MSDN machen. Nun kann ich dort aber die Seite einmal im "Fullscreen"
> > anzeigen lassen, oder ich linke mit dem Rahmen und der Navigation usw.
> > dazu. Der Fullscreen hat den Vorteil, dass die Seite schnell geladen
> > ist. Wenn man dies öfter in einem Tutorial machen muss, ist es schon
> > wichtig. Andererseits soll der Anfänger auch mit dem MSDN vertraut
> > werden, denn es ist ja schließlich die Hauptinformatinsquelle. Stört es
> > so sehr, dass man Online gehen muss, um nun die Referenz des MSDN
> > anschauen zu können (also direkt durch den Link)?
>
> Das Problem ist mir nicht ganz klar - _muss_ man online gehen um das
> Tutorial zu verstehen, so dass der Link wichtige Informationen ersetzt?
> Das erscheint mir nicht als besonders gute Idee.
Mhmm, für das Tutorial nicht direkt. Beispiel:
"Mit der CreateWindow Funktion (im MSDN: CreateWindow) erstellen wir ein
Fenster nach unser registrierten Fensterklasse. Dem ersten Parameter
lpClassName wird der Name der Fensterklasse als Zeichenkette übergeben.
Über den zweiten Parameter können wir den Text in der Titelleiste
beeinflussen. Im dritten Parameter speichern wir den Stil des Fensters.
Die nächsten vier Parameter sind für die räumliche Position des Fensters
verantwortlich. Der vorletzte Parameter muss wieder der Handle auf
unsere Programm Instanz sein, damit man das Fenster unserem Programm
zuordnen kann. Die anderen drei
Parameter sind im Moment unwichtig, daher belassen wir sie bei Null. Die
CreateWindow Funktion liefert als Rückgabewert den Handle auf das
Fenster zurück.
hWnd = CreateWindow(szAppName,
"Titelleiste",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, // X-Position auf dem
Monitor
CW_USEDEFAULT, // Y-Position auf dem
Monitor
CW_USEDEFAULT, // Fensterbreite
CW_USEDEFAULT, // Fensterhoehe
NULL,
NULL,
hInstance,
NULL);"
Das ist schon aus dem überarbeiteten 2 Tutorial. Eigentlich sind alle
Parameter beschrieben. *Muss* man dann Online gehen, um nachzuschauen?
Ich denke, es geht so.
> Wenn die MSDN dagegen nur als weiterführende Referenz angegeben wird, sehe
> ich überhaupt kein Problem - wenn man es nicht auf CD hat, muss man eben
> online gehen - das Leben ist hart!
Die andere Möglichkeit wäre die Referenz mit ins Tutorial mit
aufzunehmen, aber das wäre sehr viel Arbeit, was ja nicht so schlimm
wäre, nur das ich dazu auch keine Lust hätte :-(.
> Wer programmiert muss Englisch können
Da sind wir uns einig...
> > 2.) Ich bekam mal von jemandem eine Mail, dass es vielleicht Sinnvoll
> > Kurz:
> > - als zweites Tutorial ein Button?
>
> Ächz - schwierig zu entscheiden. Manchmal hilft es, einfach mit
> irgendetwas anzufangen und hinterher zu sortieren...
Obwohl ich immer noch für den geordneten Einstieg bin.
Ja, es ist wirklich schwierig...
> > Kurz:
> > - ist Syntax Highlighting auf der Homepage wichtig?
>
> *g* nur wenn Du es so machst, wie ich es gewohnt bin (Ein Operator muss
> z.B. _rot_ sein ;-) - ansonsten übernehme ich das lieber kurz in den
> Compiler, was ja auch unter anderen Gesichtspunkten sinnvoll ist.
_rot_ hätte ich ihn niiieee gemacht ;-)
Also weglassen. Man kann sich den Source ja auch downloaden.
> > 4.)Ist es Sinn voller die Zeile const char szAppName[] = "Programmname";
> > global zu definieren oder so lokal wie es geht. Über dies bin ich mir
> > schon lange nicht einig. Einerseits sollen Variablen so lokal wie
> > möglich sein
>
> Genau!
>
> >, aber andererseits soll es dem Anfänger einheitlich gemacht
> > werden.
>
> Naja, ein grösserer Geist als ich sagte einmal "So einfach wie möglich,
> aber nicht einfacher" (Oder so ähnlich ;-).
> Einheitlich hin und her, IMHO wird dem Anfänger kein guter Dienst
> erwiesen, wenn ausgerechnet ein Tutorial die "quick and dirty"-Lösung
> vorstellt - man sollte da eher darauf eingehen, wie solche Infos
> vernünftig übergeben werden. Andererseits ist das eher der
> objektorientierte C++-Ansatz und in einem reinen C-Programm sind globale
> Variablen AFAIK die Regel
Das muss aber nicht sein, man darf auch in C direkt nach einem
Blockanfang Variablen deklarieren/definieren!
- vielleicht löst sich dieses Problem von
> selber, wenn Du Dich konsequent für eine Sprache und einen Programmierstil
> entscheidest.
Vielleicht...
> <snip wegen auch keiner Idee >
>
> > 6.)Dann finde ich die Überschrift von Tutorial 3 sehr unpassend "Text im
> > Anwendungsbereich". Dabei geht es Hauptsächlich um das Vorstellen von
> > WM_PAINT und BeginPaint/EndPaint usw. Die TextOut Zeile kommt zwar auch
> > vor, aber...
> > Kurz:
> > - Wie soll das 3. Tutorial heißen?
>
> "Ausgaben im Fenster" hätte ich als Vorschlag anzubieten.
Nja, das ist eigentlich zu allgemein, denn eine Messagebox ist ja auch
ein Fenster und hat Text. Naja, eigentlich doch nicht so schlecht...
Mir fällt gerade: "Im Fenster zeichnen" ein, aber das ist nicht gut...
> > 7.)Was meint ihr, sollen die Tutorials benutzen? C oder C++.
>
> Keine Ahnung - konsequent wäre C für eine C-Schnittstelle (sonst könntest
> Du ja gleich ein MFC-Tutorial machen),
Bin ich mit beidem nicht einverstanden :-)
- Windows API ist keine C-Schnittstelle!
- Und das man ja gleich die MFC benutzen kann, stimmt einfach nicht :-)!
Lies doch mal die Einleitung des Petzold. Oder, wenn meine draußen ist,
kannst du auch meine Lesen ;-).
> allerdings musste ich kürzlich ein
> C-Programm schreiben und fand das grauenhaft! C++ ist dagegen wunderhübsch
> und für den PC-Bereich ist ein reiner C-Compiler doch eher selten
> geworden.
> Zu einem objektiven Urteil sehe ich mich nicht in der Lage, subjektiv bin
> ich C++-Fan!
Geht mir eigentlich genauso...
Aber da werden wir wohl keinen finden, der von Subjektivität befreit ist
:-(
> > 8.)Ist es in fast allen Fällen davon abzuraten, festes Koordinatensystem
> > zu benutzen?
> Häh???
Beispiel:
Ellipse(hDC, rect.right / 2 + (int)(cos(dGrad *pi/180) * 100) - 10,
rect.bottom / 2 + (int)(sin(dGrad *pi/180) * 100) - 10,
rect.right / 2 + (int)(cos(dGrad *pi/180) * 100) + 10,
rect.bottom / 2 + (int)(sin(dGrad *pi/180) * 100) + 10);
ist noch aus dem alten ;-).
bis dann,
Edzard Egberts
>Die andere Möglichkeit wäre die Referenz mit ins Tutorial mit
>aufzunehmen, aber das wäre sehr viel Arbeit, was ja nicht so schlimm
>wäre, nur das ich dazu auch keine Lust hätte :-(.
Möglicherweise unterliegt so etwas auch rechtlichen Einschränkungen.
>> *g* nur wenn Du es so machst, wie ich es gewohnt bin (Ein Operator muss
>> z.B. _rot_ sein ;-)
>_rot_ hätte ich ihn niiieee gemacht ;-)
Komisch - mein Syntax-Highlight Marke "Psychedelic" lässt eigentlich jeden
aus den Schuhen kippen :-( Ich dachte immer, unter Windows muss _alles_
*bunt* sein! ;-)
> > > 7.)Was meint ihr, sollen die Tutorials benutzen? C oder C++.
> >
> > Keine Ahnung - konsequent wäre C für eine C-Schnittstelle (sonst
könntest
> > Du ja gleich ein MFC-Tutorial machen),
> Bin ich mit beidem nicht einverstanden :-)
> - Windows API ist keine C-Schnittstelle!
"Die Header-Dateien, mit denen man unter C/ C++ auf die Windows-API
zugreift, sind im C-Stil formuliert." Sagt es Dir so mehr zu?
> - Und das man ja gleich die MFC benutzen kann, stimmt einfach nicht :-)!
> Lies doch mal die Einleitung des Petzold. Oder, wenn meine draußen ist,
> kannst du auch meine Lesen ;-).
"Dieses Buch ist für alle jene gedacht, die sich mit der
Programmiersprache C auskennen" "Eine sehr beliebte Option ist C++, das
_im_allgemeinen_ mit Klassenbibliotheken wie den Microsoft Foundation
Classes ... eingesetzt wird"
Ähm - vielleicht hast Du eine neuere Ausgabe?
> Beispiel:
> Ellipse(hDC, rect.right / 2 + (int)(cos(dGrad *pi/180) * 100) - 10,
> rect.bottom / 2 + (int)(sin(dGrad *pi/180) * 100) - 10,
> rect.right / 2 + (int)(cos(dGrad *pi/180) * 100) + 10,
> rect.bottom / 2 + (int)(sin(dGrad *pi/180) * 100) + 10);
Naja, früher habe ich auch so programmiert...
enum
{ // Parameter für Zeichnung
Abstand= 100, // Abstand des Kreises vom Mittelpunkt
Radius= 10 // Radius des Kreises
};
// Ausgabe im Rechteck zentrieren:
int OffsetX= rect.right/ 2;
int OffsetY= rect.bottom/ 2;
double dWinkel= dGrad *pi/ 180;
// Winkel werden in Bogenmaß gerechnet
Ellipse(
hDC,
OffsetX + cos(dWinkel)*Abstand - Radius,
OffsetY + sin(dWinkel)*Abstand - Radius,
OffsetX + cos(dWinkel)*Abstand + Radius,
OffsetY + sin(dWinkel)*Abstand + Radius
);
Ich gebe in Programmen grundsätzlich nicht mehr Konstanten direkt an,
sondern definiere sie irgendwo als Konstante. So ein Wert wie "10" neigt
dazu, sich im Quelltext zu verteilen und mehrfach in unterschiedlichen
Zusammenhängen vorzukommen. Wenn man den Wert dann ändern will, stöbert
man den ganzen Text durch, mit Suchen und Ersetzen wird garantiert eine
"10" geändert, die mit dem Kreis nichts zu tun hat. Nebenbei ist man auf
diese Art gezwungen, die Sache zu benennen und nächstes Jahr ist "Radius"
irgenwie aussagekräftiger als "10".
Soweit möglich zerlege ich komplexere Ausdrücke immer und führe
Zwischenwerte ein. Dadurch ist mir erst aufgefallen, dass Deine Ausgabe
für Rechtecke, die links oben nicht auf 0,0 sitzen, ziemlich daneben gehen
kann:
int OffsetX= rect.left + (rect.right - rect.left)/ 2;
Kurz:
Jeder Ausdruck, der so komplex ist, dass man ihn nicht auf einen Blick
versteht, stellt einen potentiellen Programmierfehler dar!
Und da ich mein Projekte sowieso nicht mehr ausdrucken kann (Tapete) und
schnell schreibe, stört es mich auch nicht, wenn ich aus 4 Zeilen 16
mache - so viel Platz ist noch auf der Festplatte. ;-)
Ach ja, "enum" verwende ich, um zumindest int-Konstanten in die
Header-Dateien packen zu können - das ist natürlich Geschmackssache,
gefällt mir als Hinweis auf "Vorgabewerte" aber besser als Konstanten mit
Initialisierungsliste.
Gruss,
Ed
Henno Buschmann
Edzard Egberts schrieb:
> "Henno Buschmann" <Loggy...@gmx.de> schrieb im Newsbeitrag
> >Die andere Möglichkeit wäre die Referenz mit ins Tutorial mit
> >aufzunehmen, aber das wäre sehr viel Arbeit, was ja nicht so schlimm
> >wäre, nur das ich dazu auch keine Lust hätte :-(.
>
> Möglicherweise unterliegt so etwas auch rechtlichen Einschränkungen.
Ich hätte es natürlich nicht wortwörtlich übersetzt ;-)
> >> *g* nur wenn Du es so machst, wie ich es gewohnt bin (Ein Operator muss
> >> z.B. _rot_ sein ;-)
> >_rot_ hätte ich ihn niiieee gemacht ;-)
>
> Komisch - mein Syntax-Highlight Marke "Psychedelic" lässt eigentlich jeden
> aus den Schuhen kippen :-( Ich dachte immer, unter Windows muss _alles_
> *bunt* sein! ;-)
Mein Windows ist grau/blau und da bestehe ich drauf :-)
> > > > 7.)Was meint ihr, sollen die Tutorials benutzen? C oder C++.
> > >
> > > Keine Ahnung - konsequent wäre C für eine C-Schnittstelle (sonst
> könntest
> > > Du ja gleich ein MFC-Tutorial machen),
> > Bin ich mit beidem nicht einverstanden :-)
> > - Windows API ist keine C-Schnittstelle!
>
> "Die Header-Dateien, mit denen man unter C/ C++ auf die Windows-API
> zugreift, sind im C-Stil formuliert." Sagt es Dir so mehr zu?
Es gibt für die Windows API C Header Dateien ;-)
Aber sie sind auch für C++, denn dort steht ein:
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
> > - Und das man ja gleich die MFC benutzen kann, stimmt einfach nicht :-)!
> > Lies doch mal die Einleitung des Petzold. Oder, wenn meine draußen ist,
> > kannst du auch meine Lesen ;-).
>
> "Dieses Buch ist für alle jene gedacht, die sich mit der
> Programmiersprache C auskennen" "Eine sehr beliebte Option ist C++, das
> _im_allgemeinen_ mit Klassenbibliotheken wie den Microsoft Foundation
> Classes ... eingesetzt wird"
Petzold: 5. Ausgabe (von 2000, also brandneu!)
"Dieser Weg stellt zwar seit längerem nicht mehr den einzigen dar
(weshalb ich weiter hinten in diesem Kaptiel kurz auf eineige
Alternativen zu sprechen komme) - wer die grundlegenden
Funktionsprinzipien dieser Schnittstelle nicht verstanden hat, erreicht
als ProgrammiererIn aber auch mit der besten objektorientieren
Bibliothek über kurz oder lang den toten Punkt."
> Ähm - vielleicht hast Du eine neuere Ausgabe?
Scheint so...
> > Beispiel:
> > Ellipse(hDC, rect.right / 2 + (int)(cos(dGrad *pi/180) * 100) - 10,
> > rect.bottom / 2 + (int)(sin(dGrad *pi/180) * 100) - 10,
> > rect.right / 2 + (int)(cos(dGrad *pi/180) * 100) + 10,
> > rect.bottom / 2 + (int)(sin(dGrad *pi/180) * 100) + 10);
>
> Naja, früher habe ich auch so programmiert...
>
> enum
> { // Parameter für Zeichnung
> Abstand= 100, // Abstand des Kreises vom Mittelpunkt
> Radius= 10 // Radius des Kreises
> };
Ist dann aber auf C++ festgelegt, sonst:
const int Abstand = 100;
const int Radius = 10;
> // Ausgabe im Rechteck zentrieren:
> int OffsetX= rect.right/ 2;
> int OffsetY= rect.bottom/ 2;
Zwei extra Variablen. Dann kann ich ja gleich in Basic Programmieren ;-)
> double dWinkel= dGrad *pi/ 180;
> // Winkel werden in Bogenmaß gerechnet
und noch eine...
> Ellipse(
> hDC,
> OffsetX + cos(dWinkel)*Abstand - Radius,
> OffsetY + sin(dWinkel)*Abstand - Radius,
> OffsetX + cos(dWinkel)*Abstand + Radius,
> OffsetY + sin(dWinkel)*Abstand + Radius
> );
>
> Ich gebe in Programmen grundsätzlich nicht mehr Konstanten direkt an,
> sondern definiere sie irgendwo als Konstante.
Sehe ich auch als Sinnvoll an, werde ich in den neuen Versionen also
machen.
Und diese wieder so lokal wie möglich?
> So ein Wert wie "10" neigt
> dazu, sich im Quelltext zu verteilen und mehrfach in unterschiedlichen
> Zusammenhängen vorzukommen. Wenn man den Wert dann ändern will, stöbert
> man den ganzen Text durch, mit Suchen und Ersetzen wird garantiert eine
> "10" geändert, die mit dem Kreis nichts zu tun hat. Nebenbei ist man auf
> diese Art gezwungen, die Sache zu benennen und nächstes Jahr ist "Radius"
> irgenwie aussagekräftiger als "10".
Sehe ich auch so...
> Soweit möglich zerlege ich komplexere Ausdrücke immer und führe
> Zwischenwerte ein.
Ist sicher geschmacks Sache, denn man hat ja dann auch mehr Code, den
man überblicken muss. Aber du hast schon Recht, wenn man nicht so ein
Ass ist wie ich, dann wirds schwierig :-)
> Dadurch ist mir erst aufgefallen, dass Deine Ausgabe
> für Rechtecke, die links oben nicht auf 0,0 sitzen, ziemlich daneben gehen
> kann:
Wieso? Alle Rechtecke des gesamten Anwendungsbereiches haben doch links
oben 0|0, oder? static und globals werden doch immer mit Null vorbelegt,
falls du das meinst...
> int OffsetX= rect.left + (rect.right - rect.left)/ 2;
Ja, aber ist doch unnötig, oder?
> Kurz:
> Jeder Ausdruck, der so komplex ist, dass man ihn nicht auf einen Blick
> versteht, stellt einen potentiellen Programmierfehler dar!
>
> Und da ich mein Projekte sowieso nicht mehr ausdrucken kann (Tapete) und
> schnell schreibe, stört es mich auch nicht, wenn ich aus 4 Zeilen 16
> mache - so viel Platz ist noch auf der Festplatte. ;-)
Auf der Festplatte sicher, aber ob das für die Tutorials so gut ist, die
ja auch ausgedruckt werden?
Dann habe ich noch ein Problem mit dem Kommentieren von Code, denn das
mache ich noch nicht so lange ;-)
Beispiel:
MSG msg; // Struktur speichert Nachrichten
HWND hWnd; // Handle auf unser Hauptfenster
WNDCLASS wc; // Struktur zum Fensterklassen bescheiben
wc.style= CS_HREDRAW | CS_VREDRAW; // Repaint bei Fenstergößenänderung
wc.lpfnWndProc = WndProc; // Nachrichtenbearbeitungs Funktion
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance; // Programm ID aus WinMain
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
wc.lpszClassName = szAppName; // Klassenname (bei uns = Programmname)
wc.lpszMenuName = NULL;
RegisterClass(&wc); // Fensterklasse anmelden
hWnd = CreateWindow( szAppName,// Fenster erstellen
"Titelleiste",
WS_OVERLAPPEDWINDOW, // Fensterstil
CW_USEDEFAULT, // X-Position
CW_USEDEFAULT, // Y-Position
CW_USEDEFAULT, // Breite
CW_USEDEFAULT, // Höhe
NULL,
NULL,
hInstance, // Programm ID
NULL);
ShowWindow(hWnd, iCmdShow); // Fenster anzeigen
UpdateWindow(hWnd); // Und ein Repaint
while (GetMessage(&msg, NULL, 0, 0)) // Nachrichten abrufen...
{
TranslateMessage(&msg);
DispatchMessage(&msg); // ... und bearbeiten
}
return msg.wParam;// Rückgabewert nicht vergessen
}
(Sieht mit vernünftigen Tabs natürlich besser aus :-))
Einige Teile sind nicht Kommentiert, da diese in einem späteren Tutorial
erklärt werden sollen (TranslateMessage, die NULLs in CreateWindow und
die cbWndExtra, cbClsExtra usw.)
Was meint ihr? Völlig daneben, oder zu viel. Wenn es nun kein Tutorial
wäre, würde ich sagen: Viel zu viel, aber so...
Detlef Wilkening
> 1.) Ich möchte, wenn ich eine neue Funktion einführe,
> einen Link zum MSDN machen. ...
>
Ich finde es gut, wenn es den Link gibt. Aber da ich zu Hause seltenst
online bin, sollte er nicht zwingend benutzt werden muessen. Wenn du den
Zugriff auf die MSDN zwingend voraussetzt, um mit dem Tutorial zu
arbeiten, bekaeme es bei mir eine 6 und wuerde direkt im Papierkorb
verschwinden. Nicht jeder will dauernd ins Netz. Als Option oder Hinweis
ist das sicher gut - aber dann muss er auch mal vernuenftig erlaeutert
werden. Vielleicht auch noch bei ganz abgedrehten Sachen, aber selbst da
bin ich mir nicht sicher.
> Meine Seiten sind ja auf Deutsch.
>
:-))))))))
> Nun muss man aber für das MSDN Englisch können.
>
:-(((((((((
> Ich finde es aber dringend notwendig, dass man
> Englisch beherscht und sich im MSDN zurechtfindet.
>
Na ja. Fuer viele spezielle Dinge kommt man nciht darum herum - keine
Frage. Aber fuer ganz normale Dinge gibt es mittlerweile soviel deutsche
Literatur - auch dank Leuten wie dir - dass viele Leute auch gut mit dem
deutschen auskommen koennen. Und das finde ich auch gut. Denn ein
Tutorial wendet sich an Anfaenger, und man sollte denen das Leben so
leicht wie moeglich machen - deshalb ja auch dein bewundernswerter
didaktischer Anspruch - und eine fremde Sprache macht es den meisten
halt nicht einfacher, sondern schwerer. Und alle Ueberlegungen der Art:
"man muss das aber heute koennen", moegen zwar richtig sein, zielen aber
in die falsche Richtung, jedenfalls wenn es einem wirklich darum geht,
dass man die Schueler erreicht und ihnen den Stoff nahe bringt.
> - Muss das MSDN übersetzt werden?
>
Das waere natuerlich schoen, aber hast du soviel Zeit bzw.
Unterstuetzung?
> 2.) Ich bekam mal von jemandem eine Mail, ....
> ... ein Fenster aus einer Button Windows Klasse ...
> ... als zweites Tutorial ein Button?
>
Finde ICH nicht gut. Selbst wenn es Dinge erspart, so ist es doch eine
sehr ungewoehnliche Methode. Und es erspart die Dinge, die es zu lernen
gilt. Und es fuehrt in eine Richtung, die ICH nicht fuer richtig halte.
> 3.)Ist Syntax Highleighting auf der Homepage
> wichtig? ....
>
Wenn es personalisierbar waere, waere es toll. Ansonsten steck deine
Zeit in wichtigere Dinge, und lass meinem Editor auch noch etwas zu tun
;-)
> 4.) ...
> - const char szAppName lokal oder global?
>
Oh, das ist eine schwere Frage. Ich moechte sie mit Frage 7 zusammen
beantworten, siehe also unten.
> 5.) ... - Name der Hauptdatei?
>
Ich finde winmain gut. Mache das selber auch so.
> 6.) ... - Wie soll das 3. Tutorial heißen?
>
Keine Idee :-(
> 7.)Was meint ihr, sollen die Tutorials benutzen?
> C oder C++. ...
>
Selbst wenn ich im Rahmen der Frage C bzw. C++ ein ganz klarer
ueberzeugter C++ Anhaenger bin, bin ich hier fuer C. Denn worum geht es
in einem Tutorial? Etwas - in diesem Fall einen Windows-Api Bereich -
dem Lernenden beizubringen. Daher wuerde ich immer eine Loesung
bevorzugen, die sich auf das eigentlich Problem konzentriert. D.h. ein
einfaches C Programm. Das heisst dann fuer Frage 4, dass ich in diesem
Fall auch ruhig fuer globale Variablen bin, selbst wenn sie in meinen
Programmen nicht vorkommen. Was ich schon erwarte, ist dann ein Hinweis,
das dies oder jenes nicht optimal ist, sich anders (sauberer) loesen
laesst, usw. Vielleicht sogar ein Hinweis, wie ein OO Design aussehen
koennte, wie eine moegliche Loesung in C++ waere.
Ach, und ich bin ganz klar gegen die MFC. Denn von einem solchen
Tutorial haette ich nichts, da ich die MFC nicht benutze.
> Und wenn man sich für C++ entscheidet muss
> dann in jedes Projekt:
> typedef 0 NULL;
>
Was soll denn das sein? Welcher Compiler nimmt den Code an? Und was soll
daran C++ sein.
> oder #define STRICT
>
Ja.
> 8.)Ist es in fast allen Fällen davon abzuraten,
> festes Koordinatensystem zu benutzen?
>
Keine Meinung - da haben andere mehr Ahnung.
Ciao
Detlef
Detlef Wilkening
> > > - Windows API ist keine C-Schnittstelle!
> >
>
Aber natuerlich.
> > "Die Header-Dateien, mit denen man unter C/ C++ auf die Windows-API
> > zugreift, sind im C-Stil formuliert." Sagt es Dir so mehr zu?
> >
> Es gibt für die Windows API C Header Dateien ;-)
> Aber sie sind auch für C++, denn dort steht ein:
> #ifdef __cplusplus
> extern "C" {
> #endif /* __cplusplus */
>
Siehst du, selbst MS findet, dass das reine C Header sind. Denn sie
stellen fuer den Fall eines C++ Compilers das Name-Mangeling von C++
aus.
Und natuerlich sind alle ISO C 1990 Header auch C++ Header, immerhin
bezieht sich ISO C++ 1998 auf ISO C 1990. Aber fuer das neue ISO C 1999
gilt das nicht mehr.
Ciao
Detlef
Henno Buschmann
danke, dass du dich an der Diskussion beteiligst.
Detlef Wilkening schrieb:
> > > > - Windows API ist keine C-Schnittstelle!
> Aber natuerlich.
Ja? Mir wäre so, als könne man in Visual Basic, Delphi und was weiß ich
auch drauf zugreifen...
> > > "Die Header-Dateien, mit denen man unter C/ C++ auf die Windows-API
> > > zugreift, sind im C-Stil formuliert." Sagt es Dir so mehr zu?
> > >
> > Es gibt für die Windows API C Header Dateien ;-)
> > Aber sie sind auch für C++, denn dort steht ein:
> > #ifdef __cplusplus
> > extern "C" {
> > #endif /* __cplusplus */
> >
> Siehst du, selbst MS findet, dass das reine C Header sind. Denn sie
> stellen fuer den Fall eines C++ Compilers das Name-Mangeling von C++
> aus.
Ok, die Headerdatei <windows.h> ist eine C Headerdatei. Das heißt aber
noch lange nicht, dass die WinAPI eine C Schnittstelle ist.
Aber wir weichen vom Thema ab.
> Und natuerlich sind alle ISO C 1990 Header auch C++ Header, immerhin
> bezieht sich ISO C++ 1998 auf ISO C 1990. Aber fuer das neue ISO C 1999
> gilt das nicht mehr.
Mag sein...
Henno Buschmann
Detlef Wilkening schrieb:
> Hallo Henno,
>
> > 1.) Ich möchte, wenn ich eine neue Funktion einführe,
> > einen Link zum MSDN machen. ...
> >
> Ich finde es gut, wenn es den Link gibt. Aber da ich zu Hause seltenst
> online bin, sollte er nicht zwingend benutzt werden muessen. Wenn du den
> Zugriff auf die MSDN zwingend voraussetzt, um mit dem Tutorial zu
> arbeiten, bekaeme es bei mir eine 6 und wuerde direkt im Papierkorb
> verschwinden.
Siehe Beispiel an Edzard.
Der Link ist nicht notwendig, um das Tutorial zu verstehen, aber um mehr
zu lernen, als im Tutorial steht. z.B. wird die MessageBox Funktion
eingeführt. Dazu werden die Erläuterungen gemacht und die Icon Konstante
MB_ICONINFORMATION vorgestellt. Es werden jedoch nicht alle Konstanten
im Zusammenhang mit der MessageBox Funktion genannt (ist in einem
Tutorial auch nicht Sinnvoll), um die dann 'rauszufinden, muss man im
MSDN Nachschauen.
Mancheiner hat das MSDN auch auf CD (ich auch ;-)).
Ist doch so Ok, oder?
> Nicht jeder will dauernd ins Netz. Als Option oder Hinweis
> ist das sicher gut - aber dann muss er auch mal vernuenftig erlaeutert
> werden. Vielleicht auch noch bei ganz abgedrehten Sachen, aber selbst da
> bin ich mir nicht sicher.
Wie bei abgedrehten Sachen? Wenn ich es nicht selber erklären kann? :-)
> > Meine Seiten sind ja auf Deutsch.
> :-))))))))
Obwohl ich in Englisch im endeffekt sicher mehr Leuten helfen könnte...
> > Nun muss man aber für das MSDN Englisch können.
> :-(((((((((
Ja, aber dafür kann ich nichts, das ist MS fehler!
> > Ich finde es aber dringend notwendig, dass man
> > Englisch beherscht und sich im MSDN zurechtfindet.
> Na ja. Fuer viele spezielle Dinge kommt man nciht darum herum - keine
> Frage. Aber fuer ganz normale Dinge gibt es mittlerweile soviel deutsche
> Literatur - auch dank Leuten wie dir - dass viele Leute auch gut mit dem
> deutschen auskommen koennen. Und das finde ich auch gut. Denn ein
> Tutorial wendet sich an Anfaenger, und man sollte denen das Leben so
> leicht wie moeglich machen - deshalb ja auch dein bewundernswerter
> didaktischer Anspruch - und eine fremde Sprache macht es den meisten
> halt nicht einfacher, sondern schwerer. Und alle Ueberlegungen der Art:
> "man muss das aber heute koennen", moegen zwar richtig sein, zielen aber
> in die falsche Richtung, jedenfalls wenn es einem wirklich darum geht,
> dass man die Schueler erreicht und ihnen den Stoff nahe bringt.
Da hast du Recht. Aber wenn man z.B. die MessageBox Funktion verstanden
hat, wird man ja noch soweit schaffen, die anderen Konstanten auch noch
'rauszufinden.
Man kann übriegens auch in den Headers nachschauen, obwohl ich das
keinem Zumuten möchte...
> > - Muss das MSDN übersetzt werden?
> Das waere natuerlich schoen, aber hast du soviel Zeit bzw.
> Unterstuetzung?
Unterstützung habe ich keine :-( (außer die netten Leute, die mir immer
wieder sagen, wie toll meine Seite ist :-)
Nein, es ist mit steigender Zahl meiner Tutorials nicht mehr Möglich.
Und außerdem ist es, wie Edzard schon sagte nicht erlaubt.
Und außerdem macht Übersetzen (mir) keinen Spaß und das finde ich auch
sehr wichtig.
>
> > 2.) Ich bekam mal von jemandem eine Mail, ....
> > ... ein Fenster aus einer Button Windows Klasse ...
> > ... als zweites Tutorial ein Button?
> >
> Finde ICH nicht gut. Selbst wenn es Dinge erspart, so ist es doch eine
> sehr ungewoehnliche Methode. Und es erspart die Dinge, die es zu lernen
> gilt. Und es fuehrt in eine Richtung, die ICH nicht fuer richtig halte.
Dann teilst du meine Meinung.
> > 3.)Ist Syntax Highleighting auf der Homepage
> > wichtig? ....
> >
> Wenn es personalisierbar waere, waere es toll. Ansonsten steck deine
> Zeit in wichtigere Dinge, und lass meinem Editor auch noch etwas zu tun
> ;-)
Ok...
> > 5.) ... - Name der Hauptdatei?
> >
> Ich finde winmain gut. Mache das selber auch so.
Ok, bleibt so :-)
> > 7.)Was meint ihr, sollen die Tutorials benutzen?
> > C oder C++. ...
> >
> Selbst wenn ich im Rahmen der Frage C bzw. C++ ein ganz klarer
> ueberzeugter C++ Anhaenger bin, bin ich hier fuer C. Denn worum geht es
> in einem Tutorial? Etwas - in diesem Fall einen Windows-Api Bereich -
> dem Lernenden beizubringen. Daher wuerde ich immer eine Loesung
> bevorzugen, die sich auf das eigentlich Problem konzentriert. D.h. ein
> einfaches C Programm. Das heisst dann fuer Frage 4, dass ich in diesem
> Fall auch ruhig fuer globale Variablen bin, selbst wenn sie in meinen
> Programmen nicht vorkommen. Was ich schon erwarte, ist dann ein Hinweis,
> das dies oder jenes nicht optimal ist, sich anders (sauberer) loesen
> laesst, usw. Vielleicht sogar ein Hinweis, wie ein OO Design aussehen
> koennte, wie eine moegliche Loesung in C++ waere.
Mhmm, mitten im Tutorial würden die vielen Hinweise auf eine C++ Lösung
sicher nicht angebracht. Ich könnte dann zwei verschiedene Versionen zum
Download anbieten.
Aber das wären dann schon 14 Download Dateien pro Tutorial... (mit den
Lösungen für die Übungen)
> Ach, und ich bin ganz klar gegen die MFC. Denn von einem solchen
> Tutorial haette ich nichts, da ich die MFC nicht benutze.
Naja, das ist ja Subjektiv! Aber du hast Recht, ich werde die MFC erst
nach der "kompletten" API drannehmen (wenn überhaupt). Aber wenn ich es
weiter so ausführlich mache, bin ich in 2 Jahren noch dabei...
> > Und wenn man sich für C++ entscheidet muss
> > dann in jedes Projekt:
> > typedef 0 NULL;
> >
> Was soll denn das sein? Welcher Compiler nimmt den Code an? Und was soll
> daran C++ sein.
Sorry, da hatte ich etwas verwechselt. Ich meinte:
const int NULL = 0;
Stroustrup 4. Auflage:
"In C war es populär, ein Makro NULL zu definieren, um den Nullzeiger zu
repräsentieren. Durch die engere Typprüfung von C++ führt die Benutzung
der einfachen 0 anstelle des NULL-Makros zu weniger Problemen. Wenn Sie
meinen , NULL definieren zu müssen, dann benutzen Sie:
const int NULL = 0;
Der const-Qualifizierer (§5.4) verhindert die versehentlihce
Redefinition von NULL und stellt sicher, dass NULL dort benutzt werden
kann, wo eine Konstante benötigt wird."
> > oder #define STRICT
> Ja.
Ok, dann muss ich mich da nochmal dransetzen...
bis dann,
Henno Buschmann
Henno Buschmann schrieb:
> Detlef Wilkening schrieb:
> > > 7.)Was meint ihr, sollen die Tutorials benutzen?
> > > C oder C++. ...
> Mhmm, mitten im Tutorial würden die vielen Hinweise auf eine C++ Lösung
> sicher nicht angebracht. Ich könnte dann zwei verschiedene Versionen zum
> Download anbieten.
> Aber das wären dann schon 14 Download Dateien pro Tutorial... (mit den
> Lösungen für die Übungen)
Mir fällt gerade auf, dass dies viel zu viel wäre. Ich kann nur entweder
oder.
Aber ich wollte eigentlich auch kein OOP benutzen. Dass ich Variablen
immer am Anfang eines Blockes deklariere, wird auch nicht das Problem
sein. Und das const Schlüsselwort ist doch auch in C enthalten, oder
(ich habe nämlich nicht mal ein C Buch. Alles C++ ...)? Und das ich in C
dann einen cast vielleicht zuviel mache, sollte auch keinen Schaden. Nur
die Endung in *.c umzubenennen, irritiert mich schon :-)
Ach, mist, ich benutze ja C++ Kommentare..., aber das macht sogar
Charles Petzold, obwohl der ja reines C verwenden wollte...
Detlef Wilkening
> > > > > - Windows API ist keine C-Schnittstelle!
> > Aber natuerlich.
> Ja? Mir wäre so, als könne man in Visual Basic,
> Delphi und was weiß ich auch drauf zugreifen...
>
Oh, tut mir leid. Ich war vom Kontext C/C++ und dem dort vorhandenen
Header <windows.h> ausgegangen. Genau genommen ist sie ja auch ne Pascal
API, wenn man ihre Art schon einer Sprache zuordnen muss, denn die
Funktions-Uebergabe laeuft wie in Pascal ab. Natuerlich kann es fuer
jede Sprache einen Zugriff auf die API geben, und insofern ist sie
halbwegs sprachneutral.
Ciao
Detlef
Henno Buschmann
dann müsst ihr mir nochmal erklären, was an folgendem Code nicht plain C
ist:
/*
* Übung 1 zu Tutorial 1 "Das erste Windows Programm"
*
* http://www.Loggy.de.st/
*
* Henno Buschmann (Loggy...@gmx.de)
*
* Aufgabe:
* Schreibe ein Programm, welches viermal hintereinander einen
Systemfehler anzeigt und
* danach diesen zum Scherz erklärt. Benutze nur zweimal die MessageBox
* Funktion.
*/
#define STRICT /* Bessere Typsicherheit */
#include <windows.h>/* Windows Funktionen und Prototypen bekannt machen
*/
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR
szCmdLine, int iCmdShow)
{
for (int i = 0; i < 4; ++i)
{ /* Zeigt eine Nachricht auf dem Bildschirm an */
MessageBox(NULL, "Schwerer Systemfehler Nr.: 60153\n"
"Kernel32.dll kann nicht geladen werden.",
"Schwerer Ausnahmefehler",
MB_ICONERROR);
}
MessageBox(NULL,"Ach, jetzt konnte Kernel32.dll auf einmal doch geladen
werden.","Fehlalarm", MB_ICONINFORMATION);
return 0;
}
danke und bis dann,
Frank Ostrowski
<Loggy...@gmx.de> wrote:
BTW:
> MessageBox(NULL, "Schwerer Systemfehler Nr.: 60153\n"
> "Kernel32.dll kann nicht geladen werden.",
> "Schwerer Ausnahmefehler",
> MB_ICONERROR);
could be MB_ICONERROR | MB_OK);
>MessageBox(NULL,"Ach, jetzt konnte Kernel32.dll auf einmal doch geladen
>werden.","Fehlalarm", MB_ICONINFORMATION);
could be MB_ICONINFORMTION | MB_OK);
>
I do not think, you should remove this important parameter to
MesageBox, the buttons are important, just because you _KNOW_ that
MB_OK is 0.
This does not lead the way to easy readable Source code, if a ovice is
trained to leave out bitmask parameters, just because he knows them to
be zero.
Frank
Frank Ostrowski
wrote:
>On Mon, 11 Dec 2000 16:28:52 +0100, Henno Buschmann
><Loggy...@gmx.de> wrote:
>
>BTW:
>> MessageBox(NULL, "Schwerer Systemfehler Nr.: 60153\n"
>> "Kernel32.dll kann nicht geladen werden.",
>> "Schwerer Ausnahmefehler",
>> MB_ICONERROR);
sollte sein MB_ICONERROR | MB_OK);
>>MessageBox(NULL,"Ach, jetzt konnte Kernel32.dll auf einmal doch geladen
>>werden.","Fehlalarm", MB_ICONINFORMATION);
sollte sein MB_ICONINFORMTION | MB_OK);
>>
>
Ich glaube nicht, das man wesentliche (bitmask) Parameter weglassen
sollte, nur weil man _WEIS_ das diese den Wert 0 haben.
Insbesondere sollten Anfänger dies nicht lernen.
Frank
Tut mir leid wegen des ersten Postings in English, habe die Sprache
glatt übersehen. ;-)
Henno Buschmann
Frank Ostrowski schrieb:
> On Mon, 11 Dec 2000 16:36:12 GMT, fr-...@web.de (Frank Ostrowski)
> >BTW:
> >> MessageBox(NULL, "Schwerer Systemfehler Nr.: 60153\n"
> >> "Kernel32.dll kann nicht geladen werden.",
> >> "Schwerer Ausnahmefehler",
> >> MB_ICONERROR);
> sollte sein MB_ICONERROR | MB_OK);
wenn schon, dann:
MB_ICONERROR | MB_OK | MB_DEFBUTTON1);
> >>MessageBox(NULL,"Ach, jetzt konnte Kernel32.dll auf einmal doch geladen
> >>werden.","Fehlalarm", MB_ICONINFORMATION);
> sollte sein MB_ICONINFORMTION | MB_OK);
und MB_ICONINFORMATION | MB_OK | MB_DEFBUTTON1);
> Ich glaube nicht, das man wesentliche (bitmask) Parameter weglassen
> sollte, nur weil man _WEIS_ das diese den Wert 0 haben.
>
> Insbesondere sollten Anfänger dies nicht lernen.
Da hast du vielleicht Recht. Werde drüber nachdenken, Danke!
> Tut mir leid wegen des ersten Postings in English, habe die Sprache
> glatt übersehen. ;-)
Stimmt, manchmal merkt man garnicht, dass man Englisch liest. Bei dir
wars wohl das schreiben :-)
Henno Buschmann
Henno Buschmann schrieb:
> dann müsst ihr mir nochmal erklären, was an folgendem Code nicht plain C
> for (int i = 0; i < 4; ++i)
> {
> }
Hier liegt der Fehler, dass geht nur in C99, in C89 so:
int i = 0;
for (; i < 4; ++i)
{
}
was ich ganz schön sch* finde!
Edzard Egberts
> > // Ausgabe im Rechteck zentrieren:
> > int OffsetX= rect.right/ 2;
> > int OffsetY= rect.bottom/ 2;
> Zwei extra Variablen. Dann kann ich ja gleich in Basic Programmieren ;-)
> > double dWinkel= dGrad *pi/ 180;
> > // Winkel werden in Bogenmaß gerechnet
> und noch eine...
Sind drei - wo ist das Problem? Bei einer Rekursion würde mir das
vielleicht Sorgen machen, aber im allgemeinen hält ein Stack das aus.
Ausserdem spare ich mir mit diesen drei Variablen fünf Berechnungen - das
ist doch gigantisch! ;-)
> > Ich gebe in Programmen grundsätzlich nicht mehr Konstanten direkt an,
> > sondern definiere sie irgendwo als Konstante.
> Sehe ich auch als Sinnvoll an, werde ich in den neuen Versionen also
> machen.
> Und diese wieder so lokal wie möglich?
Vermisse ich da einen Smiley?
Jedenfalls habe ich noch einen ultimativen Lösungsvorschlag (natürlich
C++):
ZeichneKreis(RECT rect, double dWinkel, int Abstand= 100, int Radius= 10);
Froi - das ist doch genial! :o)
> > Soweit möglich zerlege ich komplexere Ausdrücke immer und führe
> > Zwischenwerte ein.
> Ist sicher geschmacks Sache, denn man hat ja dann auch mehr Code, den
> man überblicken muss. Aber du hast schon Recht, wenn man nicht so ein
> Ass ist wie ich, dann wirds schwierig :-)
_*ROTFL*_ *LOL*
Schlage doch 'mal "Ass" im Englisch-Lexikon nach, Du As! :o))
> > int OffsetX= rect.left + (rect.right - rect.left)/ 2;
> Ja, aber ist doch unnötig, oder?
Naja, auf jeden Fall ist es die Lösung, die bei jedem Rect das erwartete
Ergebniss liefert. Warum nimmst Du denn keinen Point, wenn das Rect
unnötig ist? Ich habe bei dem Codeschnippsel jedenfalls automatisch an
eine Funktion gedacht, der ich _irgendein_ Rect zum lospinseln übergebe...
> > Und da ich mein Projekte sowieso nicht mehr ausdrucken kann (Tapete)
und
> > schnell schreibe, stört es mich auch nicht, wenn ich aus 4 Zeilen 16
> > mache - so viel Platz ist noch auf der Festplatte. ;-)
> Auf der Festplatte sicher, aber ob das für die Tutorials so gut ist, die
> ja auch ausgedruckt werden?
Na gut - da unterscheiden sich einfach die Perspektiven:
Bei einem Tutorial kann man natürlich viel schlampiger programmieren, als
bei Programmen, die an Kunden ausgeliefert werden (wer möchte es schon
riskieren, von einem Mob gekreuzigt zu werden).
Allerdings richtet sich doch ein Tutorial gerade an Anfänger und Deine
Argumentation erinnert mich an einen Fahrlehrer, der auf der Landstrasse
sagt "Fahren Sie ruhig 180, die nächste Radarfalle kommt erst in 20 km".
> Dann habe ich noch ein Problem mit dem Kommentieren von Code, denn das
> mache ich noch nicht so lange ;-)
Beispiel aus Header eines aktuellen Projektes:
//////////////////////////////////////////////////////////////////////////
/////
//
// class t_bus_controller
//
//////////////////////////////////////////////////////////////////////////
/////
class t_bus_controller:
public abgleich_fen
//
// abstrakt virtuelle Basisklasse für Busobjekte
//
{
//////////////////////////////////////////////////////////////////////////
//
private:
bool
m_Antwort;
// Wird beim Busempfang gesetzt, so dass die nächste Ausgabe
// als Antwort an den ersten Platz der Warteschlange gestellt
wird
// dabei wird m_Antwort gelöscht
unsigned int
m_WartenAntwort;
// Time-Out-Zähler für Beantwortung einer Ausgabe durch das
Busgerät
// wird bei jeder Ausgabe auf den Standardwert der
Timer()-Aufrufe
// gesetzt, in denen heruntergezählt wird
// Erreicht der Time-Out Zähler den Wert Null,
// wird der m_Wiederholen-Zähler bearbeitet.
// Solange m_WartenAntwort == 0 ist, ist der Bus für Ausgaben
frei
<snip>
bool
WartenAusgabe()
{ // Neue Ausgabe wird angefordert, wenn eine Ausgabe vorhanden
ist,
// nicht noch auf die Beantwortung der aktuellen Ausgabe
gewartet
// wird und auch keine Sendeschleife vorliegt
return
!m_TabAusgaben.empty()
&& !m_WartenAntwort
&& !m_FehlerWiederholen;
}
bool
BusEmpfang(const bus_string &Eingabe);
// Bearbeitung eines Empfangs, ruft gerätespezifisch
// ProcessEmpfang(Eingabe) auf und verwaltet
// die Rückmeldung "Antwort vorhanden",
// das Warten und das Timeout
Entsprechendes Codebeispiel:
//------------------------------------------------------------------------
---
bool t_bus_controller::BusEmpfang(const bus_string &Eingabe)
{
m_BusTimeOut= false; // Empfang löscht Timeout
m_Antwort= true;
// Eine Ausgabe, die bei der Bearbeitung dieses Empfangs erzeugt wird,
// wird bei m_Antwort= true als erstes Element in die Warteschlange
// eingefügt und somit als Antwort direkt ausgegeben
if (!m_Wiederholen)
{ // Fehlerstatus muss aufgehoben werden, um eine Antwort zu
ermöglichen
m_Wiederholen= cn_N_Wiederholen;
}
switch (Eingabe[cpBefehl])
{ // Eingabe vorab allgemein auswerten:
//- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
case 0:
{ // Bestätigung an PC kann global bearbeitet werden
// Empfang war Bestätigung des Befehls im Parameter:
if (AntwortOK( uint8(Eingabe[cpParam1] >> 5 ))) // Ausgabe bereinigen
> (Sieht mit vernünftigen Tabs natürlich besser aus :-))
> Was meint ihr? Völlig daneben, oder zu viel.
Weder, noch...
>Wenn es nun kein Tutorial
> wäre, würde ich sagen: Viel zu viel, aber so...
könnte es meiner Meinung ruhig noch etwas mehr sein.
Ich bin der unerschütterlichen Überzeugung, dass es kein zuviel an
Kommentaren geben kann!
Ich schreibe auch recht häufig zuerst den "Kommentar", indem ich genau
schildere, wie ich mir die Funktion des Programmteils/ Objekts vorstelle.
Wenn das dann eine sinnvolle und vollständige Beschreibung darstellt,
codiere ich das eigentliche Programm 'rein.
Im Ergebniss habe ich die Kommentare eher abschnittsweise geordnet und
weniger zeilenweise Kommentare, wie in Deinem Beispiel.
Erfahrungsgemäss ist eine einzelne Zeile mit vernünftig benannten
Variablen meistens auch nach längerer Zeit verständlich und man fragt sich
eher, was denn der ganze Programmabschnitt nun macht und wie er in
Beziehung zum Rest steht.
Aber auch hier muss man wohl wieder zwischen Tutorial und Praxis
unterscheiden - die Objekthierarchie zur Beschreibung von "Busobjekten",
aus der das obige Beispiel stammt, hat 685 Zeilen Header, 1764 Zeilen Code
und stellt sozusagen den "Innenausbau"der Überarbeitung eines etwa drei
Jahre alten Programmteils dar.
Es gehören noch ein "Portobjekt" und eine kapselnde Klasse mit der
Schnittstelle zum restlichen Programm dazu - 186 Zeilen Header und 994
Zeilen Code.
Nach drei Jahren gibt es kein zuviel an Kommentaren - dieses ganze
"Bussystem" ist in ein wesentlich grösseres Programm eingebettet und bei
so einer Überarbeitung muss man jede einzelne Zeile nachvollziehen können,
weil es sonst zu unerwünschten Änderungen der gesamten Funktionalität
kommen kann - verstehe ich nicht, machen wir "einfach" neu, ist nicht!
In diese Sache habe ich etwa 100 Arbeitsstunden 'reingebuttert, es läuft
seit heute mittag störungsfrei auf einer Anlage im Beta-Test und ich
rechne auch nicht mit Störungen.
Allerdings nicht, weil ich mich für so genial halte, sondern weil ich eine
Unmenge an pedantischer Kleinarbeit 'reingesteckt habe und mich nicht
frage, ob etwas "nötig" ist (s.o.), sondern nur, ob es auch _sicher_ ist!
Gruss,
Ed
Henno Buschmann
Edzard Egberts schrieb:
> > > // Ausgabe im Rechteck zentrieren:
> > > int OffsetX= rect.right/ 2;
> > > int OffsetY= rect.bottom/ 2;
> > Zwei extra Variablen. Dann kann ich ja gleich in Basic Programmieren ;-)
> > > double dWinkel= dGrad *pi/ 180;
> > > // Winkel werden in Bogenmaß gerechnet
> > und noch eine...
>
> Sind drei - wo ist das Problem? Bei einer Rekursion würde mir das
> vielleicht Sorgen machen, aber im allgemeinen hält ein Stack das aus.
> Ausserdem spare ich mir mit diesen drei Variablen fünf Berechnungen - das
> ist doch gigantisch! ;-)
Ja, vielleicht hast du Recht. So häufig kommen solche Giganten in meinen
Tutorials ja auch nicht vor...
> > > Ich gebe in Programmen grundsätzlich nicht mehr Konstanten direkt an,
> > > sondern definiere sie irgendwo als Konstante.
> > Sehe ich auch als Sinnvoll an, werde ich in den neuen Versionen also
> > machen.
> > Und diese wieder so lokal wie möglich?
>
> Vermisse ich da einen Smiley?
> Jedenfalls habe ich noch einen ultimativen Lösungsvorschlag (natürlich
> C++):
>
> ZeichneKreis(RECT rect, double dWinkel, int Abstand= 100, int Radius= 10);
> Froi - das ist doch genial! :o)
Von zusätzlichen Funktionen wollte ich in meinen Tutorials immer abstand
nehmen. Denn ich finde in so kleinen Programmen muss man dann immer hin-
und herspringen. Außerdem würde das die Struktur eines Win API Programms
durcheinander bringen. Das führt natürlich dazu, dass die Lernenden dies
auch so machen, was in der realität nicht gerade Sinnvoll ist.
> > > Soweit möglich zerlege ich komplexere Ausdrücke immer und führe
> > > Zwischenwerte ein.
> > Ist sicher geschmacks Sache, denn man hat ja dann auch mehr Code, den
> > man überblicken muss. Aber du hast schon Recht, wenn man nicht so ein
> > Ass ist wie ich, dann wirds schwierig :-)
> Schlage doch 'mal "Ass" im Englisch-Lexikon nach, Du As! :o))
Wieso im Englischen? Nach der neuen Deutschen Rechtschreibung schreibt
man das mit ss (tschuldigung: doppel s :-)). Hey, dass stimmt sogar,
habe eben nachgeschaut :-) (ha, ha!)
> > > int OffsetX= rect.left + (rect.right - rect.left)/ 2;
> > Ja, aber ist doch unnötig, oder?
>
> Naja, auf jeden Fall ist es die Lösung, die bei jedem Rect das erwartete
> Ergebniss liefert. Warum nimmst Du denn keinen Point, wenn das Rect
> unnötig ist? Ich habe bei dem Codeschnippsel jedenfalls automatisch an
> eine Funktion gedacht, der ich _irgendein_ Rect zum lospinseln übergebe...
Nix Funktion! Muss ich nochmal sehen!
> > > Und da ich mein Projekte sowieso nicht mehr ausdrucken kann (Tapete)
> und
> > > schnell schreibe, stört es mich auch nicht, wenn ich aus 4 Zeilen 16
> > > mache - so viel Platz ist noch auf der Festplatte. ;-)
> > Auf der Festplatte sicher, aber ob das für die Tutorials so gut ist, die
> > ja auch ausgedruckt werden?
>
> Na gut - da unterscheiden sich einfach die Perspektiven:
> Bei einem Tutorial kann man natürlich viel schlampiger programmieren, als
> bei Programmen, die an Kunden ausgeliefert werden (wer möchte es schon
> riskieren, von einem Mob gekreuzigt zu werden).
> Allerdings richtet sich doch ein Tutorial gerade an Anfänger und Deine
> Argumentation erinnert mich an einen Fahrlehrer, der auf der Landstrasse
> sagt "Fahren Sie ruhig 180, die nächste Radarfalle kommt erst in 20 km".
Was? Wer programmiert hier schlampig? :-) Ich? Nie (naja, gut, seit
einem Halben Jahr nicht mehr :-)
Doch, ich finde der Zerstört das Code Bild. Und man kann keine Struktur
mehr im Code erkennen, dafür braucht man zu lange um den Kommentar vom
Code zu unterscheiden, auch wenn der leicht angegrünt ist :-)
Aber: Wieso benutzt ihr kein C Kommentare auf mehrere Zeilen?
> Ich schreibe auch recht häufig zuerst den "Kommentar", indem ich genau
> schildere, wie ich mir die Funktion des Programmteils/ Objekts vorstelle.
> Wenn das dann eine sinnvolle und vollständige Beschreibung darstellt,
> codiere ich das eigentliche Programm 'rein.
Das ist bei mir umgekehrt. Erst schreibe ich den Code und dann kommen
die Kommentare
> Im Ergebniss habe ich die Kommentare eher abschnittsweise geordnet und
> weniger zeilenweise Kommentare, wie in Deinem Beispiel.
Naja, es geht ja darum, dass man die neuen Funktionen der Windows API
dokumentiert!
> Erfahrungsgemäss ist eine einzelne Zeile mit vernünftig benannten
> Variablen meistens auch nach längerer Zeit verständlich und man fragt sich
> eher, was denn der ganze Programmabschnitt nun macht und wie er in
> Beziehung zum Rest steht.
Obwohl das nach längerer Zeit bei mir nicht zieht. Der Anfänger schaut
ja das erste mal drauf!
> Aber auch hier muss man wohl wieder zwischen Tutorial und Praxis
> unterscheiden - die Objekthierarchie zur Beschreibung von "Busobjekten",
> aus der das obige Beispiel stammt, hat 685 Zeilen Header, 1764 Zeilen Code
> und stellt sozusagen den "Innenausbau"der Überarbeitung eines etwa drei
> Jahre alten Programmteils dar.
> Es gehören noch ein "Portobjekt" und eine kapselnde Klasse mit der
> Schnittstelle zum restlichen Programm dazu - 186 Zeilen Header und 994
> Zeilen Code.
> Nach drei Jahren gibt es kein zuviel an Kommentaren - dieses ganze
> "Bussystem" ist in ein wesentlich grösseres Programm eingebettet und bei
> so einer Überarbeitung muss man jede einzelne Zeile nachvollziehen können,
> weil es sonst zu unerwünschten Änderungen der gesamten Funktionalität
> kommen kann - verstehe ich nicht, machen wir "einfach" neu, ist nicht!
Wieso? Das Prinzip des Informations hiding nicht bis zum Ende geführt?
> In diese Sache habe ich etwa 100 Arbeitsstunden 'reingebuttert, es läuft
> seit heute mittag störungsfrei auf einer Anlage im Beta-Test und ich
> rechne auch nicht mit Störungen.
> Allerdings nicht, weil ich mich für so genial halte, sondern weil ich eine
> Unmenge an pedantischer Kleinarbeit 'reingesteckt habe und mich nicht
> frage, ob etwas "nötig" ist (s.o.), sondern nur, ob es auch _sicher_ ist!
Naja, das ist ja bei meinen 200 Zeilen Tutorials nicht zu erwarten...
Edzard Egberts
> > Schlage doch 'mal "Ass" im Englisch-Lexikon nach, Du As! :o))
> Wieso im Englischen? Nach der neuen Deutschen Rechtschreibung schreibt
> man das mit ss (tschuldigung: doppel s :-)). Hey, dass stimmt sogar,
> habe eben nachgeschaut :-) (ha, ha!)
Grummel - das grenzt an Sabotage! Da hat man jahrelang unter grössten
Mühen Lesen und Schreiben gelernt, das dann noch Jahrzehnte fleissig geübt
und nun ist plötzlich alles falsch! :-(
> > Ich bin der unerschütterlichen Überzeugung, dass es kein zuviel an
> > Kommentaren geben kann!
> Doch, ich finde der Zerstört das Code Bild.
? Die Ästhetik von Quelltexten stellt nun wirklich eine meiner geringsten
Sorgen dar! ;-)
>Und man kann keine Struktur
> mehr im Code erkennen, dafür braucht man zu lange um den Kommentar vom
> Code zu unterscheiden, auch wenn der leicht angegrünt ist :-)
HAH - von wegen leicht angegrünt! :o)
> Aber: Wieso benutzt ihr kein C Kommentare auf mehrere Zeilen?
*g*, das stört das Code-Bild! Ausserdem muss man gelegentlich
Programmteile "ausblenden" und dann ist es vorteilhaft, wenn man nur
C++-Kommentare 'drin hat.
> > Ich schreibe auch recht häufig zuerst den "Kommentar", indem ich genau
> > schildere, wie ich mir die Funktion des Programmteils/ Objekts
vorstelle.
> > Wenn das dann eine sinnvolle und vollständige Beschreibung darstellt,
> > codiere ich das eigentliche Programm 'rein.
> Das ist bei mir umgekehrt. Erst schreibe ich den Code und dann kommen
> die Kommentare
Jaja, 'drauflos programmieren und irgendwann überlegt man sich 'mal, was
man überhaupt machen will, und warum das so nicht funktioniert ;-).
Macht ja mehr Spass, kann ich mir aber leider nicht mehr leisten...
> > Im Ergebniss habe ich die Kommentare eher abschnittsweise geordnet und
> > weniger zeilenweise Kommentare, wie in Deinem Beispiel.
> Naja, es geht ja darum, dass man die neuen Funktionen der Windows API
> dokumentiert!
> > Aber auch hier muss man wohl wieder zwischen Tutorial und Praxis
> > unterscheiden
Dem habe ich nichts zuzufügen.
> > Nach drei Jahren gibt es kein zuviel an Kommentaren - dieses ganze
> > "Bussystem" ist in ein wesentlich grösseres Programm eingebettet und
bei
> > so einer Überarbeitung muss man jede einzelne Zeile nachvollziehen
können,
> > weil es sonst zu unerwünschten Änderungen der gesamten Funktionalität
> > kommen kann - verstehe ich nicht, machen wir "einfach" neu, ist nicht!
> Wieso? Das Prinzip des Informations hiding nicht bis zum Ende geführt?
Prinzipien sind gut und schön, aber eben nicht immer allgemeingültig:
Programme werden weiter entwickelt, neue Anforderungen kommen hinzu und
irgendwann kann man nicht mehr einfach "anbauen", sondern muss ein
Redesign fahren - die Sache komplett zerpflücken und von Grund auf neu
anlegen.
Meistens merkt man es daran, dass es an allen Ecken und Enden hakt und
Neuerungen als Work-Around angelegt werden. Dann bekommt man auch
"Fehler", die sich einfach nicht korrigieren lassen, weil sie in der
Gesamtstruktur versteckt sind, bzw. wenn man an einer Stelle schraubt,
kracht es woanders wieder zusammen.
Gruss,
Ed
Henno Buschmann
Edzard Egberts schrieb:
> > > Ich bin der unerschütterlichen Überzeugung, dass es kein zuviel an
> > > Kommentaren geben kann!
> > Doch, ich finde der Zerstört das Code Bild.
>
> ? Die Ästhetik von Quelltexten stellt nun wirklich eine meiner geringsten
> Sorgen dar! ;-)
Naja, es soll ja Spaß machen den Code zu durchforsten, also muss er
übersichtlich sein und nicht nach soviel aussehen.
> >Und man kann keine Struktur
> > mehr im Code erkennen, dafür braucht man zu lange um den Kommentar vom
> > Code zu unterscheiden, auch wenn der leicht angegrünt ist :-)
>
> HAH - von wegen leicht angegrünt! :o)
Tja, alles hat seine Vor- und Nachteile :-)
> > Aber: Wieso benutzt ihr kein C Kommentare auf mehrere Zeilen?
>
> *g*, das stört das Code-Bild! Ausserdem muss man gelegentlich
> Programmteile "ausblenden" und dann ist es vorteilhaft, wenn man nur
> C++-Kommentare 'drin hat.
Ja, stimmt. Warscheinlich sieht dein Code in deinem Editor auch viel
besser aus, als in diesem scheiß Newsclienten.
Und ich habe mich jetzt entschieden, meine Tutorials in plain C zu
schreiben.
Wenn es C99 sein dürfte, wäre das ja garnicht so schlimm, aber C89...
> > > Ich schreibe auch recht häufig zuerst den "Kommentar", indem ich genau
> > > schildere, wie ich mir die Funktion des Programmteils/ Objekts
> vorstelle.
> > > Wenn das dann eine sinnvolle und vollständige Beschreibung darstellt,
> > > codiere ich das eigentliche Programm 'rein.
> > Das ist bei mir umgekehrt. Erst schreibe ich den Code und dann kommen
> > die Kommentare
>
> Jaja, 'drauflos programmieren und irgendwann überlegt man sich 'mal, was
> man überhaupt machen will, und warum das so nicht funktioniert ;-).
Ja, ein bisschen schon. Aber es gibt echt Situationen, da sitze ich eine
Stunde vor dem Computer und schreibe keine Zeile Code. Sondern ich mal
mir aus, wie das alles aussehen soll. Wenn ich dann anfange etwas zu
schreiben, weiß ich meistens schon genau, was daraus wird. Geht
natürlich manchmal auch daneben, aber eigentlich gehts :-)
> Macht ja mehr Spass, kann ich mir aber leider nicht mehr leisten...
Was Programmieren angeht, kann ich mir noch alles leisten :o)
> > Wieso? Das Prinzip des Informations hiding nicht bis zum Ende geführt?
>
> Prinzipien sind gut und schön, aber eben nicht immer allgemeingültig:
> Programme werden weiter entwickelt, neue Anforderungen kommen hinzu und
> irgendwann kann man nicht mehr einfach "anbauen", sondern muss ein
> Redesign fahren - die Sache komplett zerpflücken und von Grund auf neu
> anlegen.
> Meistens merkt man es daran, dass es an allen Ecken und Enden hakt und
> Neuerungen als Work-Around angelegt werden. Dann bekommt man auch
> "Fehler", die sich einfach nicht korrigieren lassen, weil sie in der
> Gesamtstruktur versteckt sind, bzw. wenn man an einer Stelle schraubt,
> kracht es woanders wieder zusammen.
Ich würde dann das ganze Programm neu schreiben, aber ab einer
bestimmten Größe geht das wohl nicht mehr :-). Oh, es ist so toll nix
leisten zu *müssen*