Windows-Programmierung, QUICK & DIRTY == QUICK&EASY

Man kommt mit der ZU-FUSS-PROGRAMMIERUNG der WIndows Api einigermaßen in die Füße.

ZU FUSS heißt, alles per Texteditor eingeben. Also die ganz harte Tour.

Je komplexer die Anwendung allerdings wird, umso zahlreicher und undurchschaubarer werden die Fußangeln.

Mal ein Beispiel:

Wir beginnen mit einem Fenster, und als erstes müssen wir uns um eine MenüStruktur bekümmern, damit der Anwender mit dem Fenster überhaupt irgendwas anfangen kann.

Dazu legen wir 20 Buttons an. Jeder der Buttons ist eine Menü-Auswahl.

Die Buttons legen wir an als eigenständige Fenster mit CreateWindow der Klasse "button"


b[i] = CreateWindowEx (
0, /* Extended possibilites for variation */
"button", /* Classname */



Das machen wir nicht so, daß wir sagen: button1, button2, button3 und so weiter, sondern als Array, damit wir die Fenster anschließend in einer Schleife ansprechen können:

HWND b[20]; // Deklaration für 20 Handler für 20 Fenster b[0],b[1] usf.

Da die Namen der buttons auf dem Bildschirm als Menü-Optionen erscheinen, müssen wir sie zuvor definieren, z. B. so:


void init()
{

sprintf(btext[1],"Kontur zeichnen");
sprintf(btext[2],"Kkontur entfernen");
sprintf(btext[3],"Fräskontur 1 einblenden");
sprintf(btext[4],"Fräskontur 2 einblenden");
sprintf(btext[5],"Fräskontur bearbeiten");
sprintf(btext[6],"Hilfsradius ändern");
sprintf(btext[7],"Fräskontur speichern");
sprintf(btext[8],"Abbrechen ohne zu speichern");

}

... für die ersten 8 Buttons.

Nun deklarieren wir die mit CreateWindow und initialisieren mit der bezeichneten Zeile :


for (i=1;i<MAXBUTTON;i++)
{

b[i] = CreateWindowEx (
0, /* Extended possibilites for variation */
"button", /* Classname */
btext[i], /* Title Text <----------------------------------- da ist die Button-Aufschrift wie oben definiert */
WS_CHILD|WS_THICKFRAME, /* default window */
0, /* Windows decides the position */
(i-1)*by+nfy, /* where the window ends up on the screen */
bx, /* The programs width <-------------------------------------- die aus der Schleife errechneten Koordinaten */
by, /* and height in pixels */
hwnd, /* The window is a child-window to desktop */
(HMENU)i, /* <----------------------------------------------------- Nr. des Buttons ist i, also fortlaufend 1..n */
hThisInstance, /* Program Instance handler */
NULL /* No Window Creation data */
);


}



Die Platzierung der Buttons ergibt sich in der Schleife wie oben zu sehen abhängig von ihrer Größe, nämlich untereinandergestapelt wäre das:


Button_hoehe=30;

Macht für die Vertikale Position by=Button_hoehe*i-30, ergibt dann 0,30,60,90 usf.

Das Ergebnis ist dann ein Fenster mit den definierten Buttons, die man nach Bedarf angeordnet und beschriftet hat.

Nun gehen wir in die WndProc, also die Ereignisschleife, und fragen ab, welcher Button gedrückt wurde. Das liefert uns Windows gratis, mit der Message WM_COMMAND. WM_COMMAND liefert den Wert für (HMENU), den wir mit i in der Schleife fortlaufend numeriert haben.

Also erhalten wir dann für 1 dasjenige, was unter text[1] auf dem Button steht.

Da wir nicht jedesmal nachschlagen wollen, was wir mit 1 , 5, oder 8 durchnummeriert haben, machen wir uns eine ENUM-Liste für die Optionen, Z. B:

enum auswahl {GK_ZEICHNEN=1,GK_ENTFERNEN,FK1_ZEICHNEN,FK2_ZEICHNEN,FK_BEARBEITEN,RADIUS_AENDE
RN,
FK_SPEICHERN,ABBRECHEN};

Die beginnt mit 1 für GK_ZEICHNEN, und endet mit ABBRECHEN, wir können nun statt 1,2,5,... diese Bezeichner verwenden, nämlich:



case WM_COMMAND: // Menuvorgaben der Buttons durchprüfen
switch(LOWORD(wParam)) // == liefert den angeklickten Button
{


case GK_ZEICHNEN: // die Menüoption Zeichnen
ausgabe_Grundkoerper(ZEICHNEN);
SetFocus(hwnd); // Focus zurückholen
return(0);
case GK_ENTFERNEN:
ausgabe_Grundkoerper(LOESCHEN); // löschen
SetFocus(hwnd);
return 0;
case FK1_ZEICHNEN:
modus=GERADE;
ausgabe_fraeskontur(modus,LOESCHEN); // erst löschen
modus=UNGERADE;
ausgabe_fraeskontur(modus,ZEICHNEN); // dann ausgeben
SetFocus(hwnd);
return 0;

... und so weiter, wie das Menü eben aussehen soll,

Der Default ist dann sehr wichtig:

default:
return DefWindowProc (hwnd, message, wParam, lParam);

Das heißt, was hier nicht abgefangen wird, wird an die WndProc zurückgegeben, damit es nicht im Nirwana versinkt.

Bei dieser DIRECT SIMPLE Programmierung tut sich ein Problem auf, was man im Programmauszug schon erahnen kann:

Wir haben plötzlich keine Tastaturkommandos mehr. Solche Anweisungen, wie sie auch in der SWITCH-Anweisung der Wnd Proc stehen, wie:


case WM_KEYDOWN: // TASTE GEDRÜCKT?????
switch (LOWORD(wParam))
{
case VK_LEFT: // PFEILTASTE LINKS ...
case VK_RIGHT:
case VK_UP:
case VK_DOWN: // PFEILTASTE UNTEN ...
aendere_fraeskontur(modus,EDIT,LOWORD(wParam));
SetFocus(hwnd);
return 0;
default: /* for messages that we don't deal with */
return DefWindowProc (hwnd, message, wParam, lParam);

(Man sieht, auch hier in dieser Unter-Verzweigung von switch-case-switch ist der Default wieder sorgfältig reingesetzt, macht man das nicht, wird das Programm auf die Dauer oder auch schon sofort sehr merkwürdig reagieren).

laufen dann ins Leere.

Die Tastatur ist tot.

Das liegt daran, daß bei Verwendung mehrere Fenster zwar die Maus alle Fenster erreichen kann, aber die Tastatur natürlich nicht wissen kann, was auf dem Bildschirm geschieht. Daher erhält irgendein Fenster, nämlich das aktuelle, die Ereignisschleife für WM_KEYDOWN, wenn aber das Fenster die Klasse

"button"

hat, gibt dieses die Info nicht weiter, sondern verschluckt die Tastaturkommandos, bis auf das Leerzeichen.

Das ganze nennt sich "Focus".

Um wieder Herr über die Tastatur zu werden, sieht man oben, wie ich das gemacht habe:

case FK1_ZEICHNEN:
modus=GERADE;
ausgabe_fraeskontur(modus,LOESCHEN); // erst löschen
modus=UNGERADE;
ausgabe_fraeskontur(modus,ZEICHNEN); // dann ausgeben
SetFocus(hwnd); <===================== setzt den Focus, also die Tastaturabfrage, wieder auf das Hauptfenster zurück
// ist aber nicht sauber, weil diese Anweisung ohne weitere Prüfung auch in Fremdprogramme reinpfuscht, die dann dasselbe
// Problem haben wie wir hier mit den Buttons. Soll nur als Beispiel dienen, wie man das abfangen kann.



Die ganze Chose sieht dann so aus wie in der Abbildung zu sehen.

Und sie funktioniert!

Denn nun können wir zwischen den Switch-Case Verzweigern die gewünschten Funktionen reinsetzen, alles was wir wollen, rechnen, Texteditieren, Grafikfunktionen etc. , wie im Programmschnipsel zu sehen.

Damit hätten wir den Rahmen für ein Windows-Programm, welches mit Menü-Optionen arbeitet, wobei alles Zu Fuß programmiert ist.

Die Sache mit dem Focus findet man bei Petzold irgendwo jenseits von S. 500- S1000, man muß gezielt danach suchen, sonst findet man sie niemals.

Und an dieser Stelle hatte ich den Entschluß gefaßt: Es muß noch was anderes geben als zu Fuß. Und das gibt es auch.

Das Stichwort h eißt:

R A D

Rapid

Application

Developement

= QUICK AND DIRTY

Das Werkzeug dazu ist keinesfalls der MSVC++, sondern ein wirklich geniales Werkzeug, um in Minutenschnelle Windows-Applikationen zu erstellen, der


Borland C++ Builder.

Ich hab ihn mir gebraucht gekauft in der Version 5.0, so für 250 Euro ist der dann zu haben, neueste Version ist sonstwas, aber der 5.0 reicht für meine Zwecke vollkommen aus.

Zu dem, wie man damit arbeitet, gleich noch ein kleiner Anschlußbeitrag und dann die Tage gelegentlich mehr davon.

Das ganze ist als TIPP zu verstehen für Leute, die man schnell eine GRAFISCHE Windows-Oberfläche brauchen, einigermaßen fit sind in C/C++,

sich aber in die Niederungen der Windows-Programmierung einzuarbeiten keinen Bock haben.

Für solche Leute (zu denen ich auch gehöre) ist der Borland C++BUilder eine (die) optimale Lösung.




Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 17.03.2011, 19:11 Uhr

Thema:

Ein Menü in Window erstellen.

Das ist zu Fuß mit allerlei Aufwand verbunden. Man muß (der mainstream):

1. Eine .h datei erstellen

2. eine .rs datei erstellen

Diese .rs datei mit einem Res.exe Compiler vorkompilieren

3. Dem Programm sagen, daß es diese Dateien in das Projekt einbinden soll.

Bei diesem technischen Problem bin ich sowohl mit dem devcpp-Compiler als auch mit dem mir wenig bekannten msvc++ Compiler völlig gescheitert. devcpp hat keine Dokumentation, und vc++ESPRESS2010 steigt aus mit dem Hinweis, daß es .res Dateien nicht bearbeitet (na Express ist ja auch die kostenlose Version).

Also nix mit Menü.

Borland Compiler beim Ebay gebraucht ersteigert und los gehts:

Menü ist als Windows-Menü in der Titelleiste in exakt 1 Minute fix und fertig untergebracht.

Siehe Abbildung.

Daß man das nicht ausgeklappt sehen kann, liegt an der Alt-Taste. Wenn ich Alt-Druck für Hardcopy mache, klappt es ein, weil es mit Alt eben einklappt.

Man kann aber erkennen, was gemeint ist.

Wie gesagt, in EINER MINUTE ERLEDIGT.

Nun können wir für unser Menü bestimmen, was geschehen soll.

Durch Anklicken der rechten Spalte, wenn z. B. jemand im Menü: Datei öffnen auswählt, müssen wir im dazugehörigen Feld

OnCLick sagen, was geschehen soll.

Der Compiler setzt dann in den Quelltext den Code:

//---------------------------------------------------------------------------
void __fastcall TForm1::Dateiffnen1Click(TObject *Sender)
{

}
//---------------------------------------------------------------------------


Das heißt, vom T-Formular 1 (Hauptfenster) Menü wurde Datei öffnen geklickt. Was hier wg. Umlauf zu TForm1::Dateiffnen1Click gerät.

Man kann den automatisch vergebenen Namen: Datei öffnen -> macht der compiler Dateiffnen draus, auch explizit etwas freundlicher benennen, benennen, dann sieht es so aus:

//---------------------------------------------------------------------------

void __fastcall TForm1::Datei_oeffnenClick(TObject *Sender)
{

}
//



Wir sehen, der void_fastcall ist der Funktionsaufruf. Das ist die Funktion, die aufgerufen werden soll, wenn der Anwender aus dem Menü Datei öffnen wählt.

Da noch nichts drinsteht in der Funktion, geschieht auch noch nichts.

Für den Fall bereiten wir jetzt ein neues Fenster vor, nämlich Form(ular) 2.

Dazu klicken wir uns aus dem Werkzeugkasten 4 Elemente zusammen:

DirectoryListBox
FileListBox
FilterComboBox
DriveComboBox

Was das bedeutet, sieht man gleich.

Und zum Spaß noch den Kalender von Windows mit rein.

Sieht dann so aus wie in der Abb.

Benötigte Zeit bis hier: ca. 3 Minuten (!):

Der Beitrag wurde von sharky bearbeitet: 17.03.2011, 19:49 Uhr

Das ganze läuft auch schon.

Mit F9 startet der Compiler und der Linker und das Ergebnis ist eine ausführbare .exe-Datei.

Es läuft, aber es tut sich noch nichts.

Im Prinzip funktioniert es so wie an diesem einen Beispiel beschrieben:

Schritt 1.) Wir machen die ganzen Formulare, die wir brauchen, also den Rahmen des Windows-Programms, wie man ihn sehen soll.

Schritt 2.) Wir verknüpfen diese "leeren" Anweisungen so, daß der gewünschte Schuh draus wird.

Z. B. das Formular 2 müssen wir erstmal aufrufen. Wenn Datei öffnen gedrückt wird, soll das Programm Fenster 2 mit dem Dateimenü aufrufen, damit der Anwender seine zu öffnende Datei aussuchen kann. Wir fügen dazu der Funktion:

//---------------------------------------------------------------------------

void __fastcall TForm1::Datei_oeffnenClick(TObject *Sender)
{

}
//---------------------------------------------------------------------------

Die Anweisung ein:

//---------------------------------------------------------------------------

void __fastcall TForm1::Datei_oeffnenClick(TObject *Sender)
{

Form2->Show();

}
//---------------------------------------------------------------------------


Da heißt, es soll das zweite Fenster erscheinen. Die seltsame Formulierung ergibt sich daraus, daß wir aus der

KLASSE TFORM1

die EIGENSCHAFT Show()

aktivieren.

Das hängt also mit der objektorientierten Programmierung zusammen. Im Grunde ist es aber nichts anderes, als wie das Feld einer Struktur angesprochen wird, auf die ein Zeiger zeigt:

p->element

Also eigentlich schönstes c, nur anders gemeint und etwas schärfer formalisiert.

Wir können uns damit schnell anfreunden.

Rufen wir nun das Programm auf, erscheint eine Fehlermeldung a la: unbekannter Bezeichner Form2.

Das kommt daher, daß Form1 von Form2, also Fenster 1 von Fenster 2 noch nichts weiß. Der Code, der hinter den Fenstern (sichtbare Oberfläche) steht, ist

Unit.cpp, also ein c++-Code mit dem Namen der Unit, Unit1.cpp, Unit2.cpp usf.

Wir müssen der Unit1 sagen, daß sie

#include Unit2.cpp

die Unit erkennt. Das können wir aber auch einfacher, indem wir Form1 anklicken, dann die Option Datei->UnitHeadereinschließen anklicken und der Borland-Compiler macht es automatisch.

Sehenn wir mal nach:

//---------------------------------------------------------------------------

#include <vcl.h>
#pragma hdrstop

#include "Unit1.h"
#include "Unit2.h"
//---------------------------------------------------------------------------
#pragma package(smart_init)
#pragma resource "*.dfm"

Na also.

Rufen wir nun das Programm auf, wählen im Menü Dateien den Menüpunkt "Datei laden (oder öffen)", erscheint folgende Ausgabe (siehe Abb).

Ahja, gut zu wissen.. dann können wir ja bald zum Mars fliegen damit, wa?

Es gibt Leute, die schaffen es ihr Leben lang nicht, einen KONSTRUKTIVEN Beitrag zu schreiben, haben aber immer was zu meckern. Nun , so ist die Welt.

Der Flug zum Mars:

Das muß man berechnen können. Eine mathematisch-physikalische Anwendung, die man grafisch sichtbar machen muß.

Für solche komplexen Berechnungen eignet sich C bzw. C++ hervorragend. Schneller als in C kann man nur in Assembler noch rechnen, und auch das nur knapp.

Nun haben wir die ganze Berechnung fertig als Konsolenprogramm (mehr kann C nicht).

Nur mit der Konsole kann der Windows-Anwender ja nicht kommunizieren.

Die Frage wäre also:

Wie kriegt man den Dialog mit dem Anwender hin, nachdem die ganzen Berechnungunsroutinen fertig programmiert sind?

Diese eigentlich eher formale Schnittstelle liefert Windows, und da das zu Fuß recht anstrengend ist,

liefert es die

RAD = der Borland C++ Builder einfacher und schneller.

Der C++ Builder nimmt einem nicht das Programmieren ab, aber er ermöglicht es, eine Konsolen-Programmierung mit Drag & Drop ohne großen Aufwand in eine grafische Windows-Umgebung zu portieren und den Dialog mit dem Anwender in einer Windows-Umgebung herzustellen.



Soviel zu dem ewigen Gemeckere hier.

Der Beitrag wurde von sharky bearbeitet: 17.03.2011, 20:44 Uhr

Ich möchte hier keinen Einführungslehrgang für den C++Builder schreiben.

Das Buch wurde schon geschrieben, es ist wie der Petzold für Windows Api der Richard Kaiser, C++ mit dem Borland C++ Builder.

Das ist DAS Standardwerk, wie alle solche viel zu dick (1200) Seiten zum Durchlesen, aber UNENTBEHRLICH zum Nachschlagen, besonders im Anfang. Kostet 50 Euro, lohnt sich, muß sein.

Was der Kaiser beantworten kann, sind Fragen zu Borland C++ Builder.

Was der nicht beantworten kann, ist die Programmiertechnik in C++, in der Umgebung, daß man Konsole programmiert und das Ganze dann nachträglich in eine Windows-Umgebung portieren will.

Zu dem Problem, wie man sowas strukturiert, möchte ich mal ein paar Anmerkungen machen.

Zum zweiten einige Anmerkungen, worin sich ein Windows-Dialog von einem Konsolen-Dialog unterscheidet.

Das sind ganz grundlegende Programmierlogiken, die man nachträglich nur sehr schräg zusammenführen kann, man sollte sie bei der Programmierung direkt berücksichtigen. Wenn also klar ist, man programmiert in C und hat den Borland Compiler zur Verfügung, dann kann man ungefähr so vorgehen:

Es wird ganz wie gewohnt programmiert, angefangen mit

#include
#define

der ganze Rest besteht nur aus Funktionsaufrufen, ebenfalls wie gewohnt,

void f()
int f()

etc. etc.,

Aber: Nachdem der Konsolen-Code eingehend geprüft und als brauchbar eingestuft wurde, löscht man aus der Konsolenanwendung die Funktion main (argc, arv) komplett raus.


Das Ergebnis ist dann eine Datei, die selbst nicht mehr eigenständig lauffähigen Code erzeugt, daher wird die zur Bibliotheksumfunktion umdeklariert und als Header gespeichert, also statt

datei.cpp

als

datei.h.


In diesem ganzen Code sollte man alle Befehle, welche eine Anweisung auf der Konsole zur Folge haben, wie printf(), unbedingt von vornherein vermeiden.

Fehler-Management läuft mit dem Rückgabewert der Funktionen:

int function(..) return ERRORCODE

Dann kann man das von der aufrufenden Routine her schön eingrenzen, wo es brennt.

Dieses eigentliche Hauptprogramm mit 95 Prozent der Funktionen wird dann als

#include hauptprogramm.h

in die Windows-Programmierung eingebunden, und damit stehen alle Funktionen RECHNERISCH sofort verfügbar.

Alle AUSGABEN macht nur das Windows-Programm.

So kann man das sehr schön sauber hinstellen.

Als nächstes einige BEmerkungen zu den strukturellen Unterschieden zwischen einer Konsolen- und Windows-Programmierung generell.

Als Konsolen-Programmierer muß man sich einiges abgewöhnen,

z. B. die Vorstellung, den Anwender in einer Abfrageschleife gefangenzuhalten, bis das gewünschte Resultat feststeht.

Der Anwender kann nämlich selbst entscheiden, ob er hier weitermacht oder ganz woanders was macht. Der Grund ist, daß alle Eingaben über die wndproc laufen, zweitens daß Windows eine Multitask-Umgebung ist, wo man das unbedingt vermeiden sollte. Natürlich, man kriegt das Gefangenenmodell hin, aber es ist unschöne Programmierung und führt dazu, daß sich die Anwendung aufhängt.

Wir müssen also jederzeit dem Anwender die Möglichkeit geben, woanders weiterzu machen.

Wir quetschen nicht alles in die wndproc(=die Ereignisschleife), sondern bleiben strukturiert und lassen die wndproc aufrufen, was sie möchte (nicht wahr, nicht ganz einfach die Vorstellung?).

Das bedeutet, daß man die Funktion so aufbaut, daß sie bei einem späteren Einsprung aus dem Programm ihre parameter nicht so verändert hat, daß Unsinn herauskommt, oder in ihrem Aufbau Dinge voraussetzt, die beim zweiten Einsprung nicht mehr als gegeben vorausgesetzt werden dürfen. . Das könnte passieren, wenn wir mit globalen Parametern arbeiten oder uns unglücklich unterverzweigen. Kommt der Anwender damit aus einer ganz anderen Funktion zurück, könnte es krachen oder Blödsinn wäre das Resultat.

Als Beipiel Tastatureingabe:

Ein Konsolenprogramm wird die Tastatur mit Unterverzweigungen abfragen, z. B. wenn F1 gedrückt ist in eine Unterverzweigung gehen, wo man mit Pfeiltasten weiter arbeitet. Eben bis zum Ende, bis die Verzweigung abgearbeitet ist. Da wir aber nicht wissen, ob der Anwender rausspringt zu einer anderen Funktion, wo auch mit Pfeiltasten gearbeitet wird, kann man so nicht arbeiten.

Der Unterschied ist:

auf der Konsole wird unterverzweigt, und man kann die tasten aus der Unterverzweigung zuordnen.

Aus der wndproc ist nicht klar, welche Funktion derzeit angesprochen wird, die Tasten gelten für alle Funktionen gleichermaßen.

Daher fragt man die Eingaben (Tastatur und Maus) auf der Konsole in der Funktion ab (wir halten den Anwender da fest, bis das Ergebnis fest steht)..

Bei der Windows Programmierung fragen wir die Eingaben NIEMALS in der Funktion ab, wir halten ihn nicht fest, sondern rechnen mit gelegentlichen Kontakten. Die Ereignisse werden IMMER NUR in wndproc abgefragt(=in der Ereignisschleife).


Das ist eine gedankliche Hürde, die man nehmen muß.

Die ist nicht ganz einfach.

Wenn man das von der PROGRAMMIERLOGIK her einmal VERINNERLICHT hat (dauert bei eingefleischten Konsolenprogrammierern einige Zeit), ist das technisch kein Problem mehr. Wir können über globale Schalter (welche Funktion gerade aktiv ist) oder über Funktionsvariablen aus wndproc heraus mit LOKALEN SCHALTERN jede noch so komplexe Anwendung steuern.

So wächst dann nach einiger Zeit die Konsole mit Windows zusammen, was zusammengehört.

Damit genug der Philosophie.

Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 17.03.2011, 21:25 Uhr

Um nochmal auf den Unterschied Konsole-Windows-Programmierung zu kommen:

Auf der Konsole wird eine Funktion EINMAL aufgerufen und arbeitet die gesamte Eingabe ab, indem sie den Focus der EIngabe erst herausrückt, wenn sie fertig ist.

Unter Windows behält die Funktion den Focus nicht, sondern muß damit rechnen, daß der Anwender woanders hinläuft.

Der WESENTLICHE Unterschied ist:

Bei Konsolenprogrammierung wird eine Funktion EINMAL aufgerufen und fertig abgearbeitet,

unter Windows wird sie beliebig oft aufgerufen, ohne daß es klar ist, ob sie jemals fertig abgearbeitet wird.


Über diesen ZAUN muß man bei der Programmierung springen.

für eingefleischte Konsolenprogrammierer heißt das:

PARADIGMENWECHSEL.


Mit dem Borland C++ Builder wird es relativ einfach: Man kann die fertige Konsole mit DRAG&&DROP in eine Windows-Umgebung portieren.

Es geht wirklich sauschnell.

Nur die logische Struktur der Programmierung muß natürlich drauf abgestellt sein.


Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 17.03.2011, 21:39 Uhr

zu den leuten gehör ich auch


was ist los scharky hast du Langweile ?
oder warum schreibst du hier ein tutorial für so einen alten zopf
wie C++ 5.0
wenn dann schreib doch was für .net
die meisten entwicklungs umgebungen sind kostenlos
jeder der möchte könnte deine ergüsse nach voll ziehen




warum ist RAD QUICK AND DIRTY ???



aber einfach zu alt .

Ja, wie es aussieht, gehörst du zu der Sorte.

Ich könnte jetzt wirklich ein Tutorial schreiben, haber aber nach solchen Kommentaren echt keine Böcke dazu.

Insofern hast du dein Ziel erreicht, denn ich reiß mir hier nicht den Ar... auf, um mir sowas anzuhören.

Was alte Zöpfe angeht: die Bibel ist ca. 2000 Jahre alt, und C wurde von K&R in den 80er Jahren geschrieben. Wir schreiben jetzt 2011.

Wer ein .NET Tutorial sucht, dem steht das ganze Internet offen. Allein bei MS sind darüber tausende von Seiten zu finden.

Ich war gestern bei einem deutschen Maschinenbauer, der die Software selbst programmiert. Natürlich in .NET, natürlich 64 Bit, und die Umstellung von 32 auf 64 Bit hat nach seinen Angaben lediglich "ein halbes Mannjahr" gekostet, auch weil nämlich die von Microsoft großspurig verkündeten Umsetzungen von VB auf C#.NET in der Praxis so nicht funktioniert haben wie angekündigt. Der hat einige Programmierer da sitzen. Da heißt für ihn, daß einer damit beschäftigt ist, die Umstellung zu schreiben, und 6 Monate blockiert ist.

Für denjenigen, der sich selbst helfen will, heißt das: 6 Monate Zeitverschwendung.

Denn was soll für einen normalen Endanwender, der seine Software schreibt, so eine Umstellung bringen?

.NET ist Microsoft-Zwangsstandard, bzw. hoffen die das, daß die den mit Gewalt durchsetzen können, und bringt überhaupt nichts, es sei denn, jemand wolle ein Programm schreiben, was sowohl in Australien als auch in Japan läuft und auf MS-Standards aufsitzt.

Gegenüber der guten alten C++ Umgebung, und was sage ich, C ist vom ästhetischen und der Programmierlogik her viel schöner und zu 90 Prozent auch ausreichend,

BRINGT DIE UMSTELLUNG AUF .NET und möglicherweise C# überhaupt keinen Vorteil.

Solche Überlegungen bewegen sich in Dimensionen, in denen sich Programmierer für Profi-Anwendungen im 3D Bereich bewegen.

Und die werden hier ganz sicher keinen Tipp für ihre Programmierung suchen.

Für Leute, die nicht zu den Profis gehören und eigene Anwendungen schreiben, ist der C/C++ Standard plus eine RAD

MEHR ALS AUSREICHEND, ja geradezu ein LUXUS-Ambiente.

Denn am Ende der Programmierung steht ISO-Code in jedem gewünschten Dialekt und der hat sich im Prinzip in 20 Jahren kein bißchen verändert.

Mehr fällt mir zu deinem GEHÄSSIGEN und VÖLLIG SINNFREIEN Kommentar nicht ein, aber muß es auch nicht.

Ich werde hier sicherlich nicht nachfragen, wie ich meine Anwendungen programmiere. Die laufen nämlich einwandfrei und tun ihren Zweck. Um mehr kann es ja gar nicht gehen. Ich setze jetzt jede Konsole problemlos in Windows-Programmierung um, mit allem grafischen Schnickschnack. Das war das Ziel und wurde mittlerweile erreicht.

Ich habe aber keine Lust, mich hier beschimpfen zu lassen.

Und stelle daher den Thread ein.


Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 19.03.2011, 14:00 Uhr

wolte dich nur auf deine antiquarischen Entwicklungsumgebung aufmeksam machen
wie Stephan77 vor gut einem jahr

aber bitte jeder wie er kann ich würde das beratungsresistent nennen .