Windows-Programmierung vs. vorgefertigte Fenster

Juri

Moin moin,

ich hatte letztens ein Gespräch mit einem Kollegen und ich konnte ihn einfach nicht überzeugen, dass vorgefertigte Fenster...hm....sagen wir es freundlich...Müll sind

Meiner Meinung nach hat klassische Windows-Programmierung, wo man noch sein Fenster "selber" erstellt viele Vorteile, besonders in Sachen wie Spieleprogrammierung (OpenGL, DirectX, Allegro, usw.). Desweiteren hab ich viele Möglichkeiten mit Messages umzugehen, wie zum Beispiel ein Tastendruck oder das verändern der Fenstergröße.

Vorgefertigte Fenster sind eigentlich recht pratisch....wenn man Businessanwendungen schreibt oder ähnliches, aber ansonsten seh ich nicht viel sind darin, sich seine Anwendung zusammenzuklicken und dann noch ein bisschen code zu schreiben.

Ich möchte erwähnen, dass ich ihm ein Buch in die Hand gedrückt hab (auf Bitte von ihm, dass er Spieleprogrammierung lernen will) und hat sich schon bei mir "beschwert", dass er es doof findet, dass das Fenster nicht schon existiert.

Was hält ihr davon? klassisch oder "modern" programmieren?
Nennt mir bitte auch weitere Anwendungsbereiche. Z.B. kann ich mir nicht vorstellen ein fertiges Fenster dann auf Vollbild umzuschalten...geht das überhaupt?

Krux

Vorgefertigt heißt doch nicht statisch unveränderbar. Sag mir wenn ich mich irre, aber für gewisse dinge sind vorgefertigte Fenster doch auch für den nutzer sehr von vorteil, beispielsweise wenn es darum geht eine Datei zu öffen. Anstatt mir das ganze teil selbst zu bauen, kann ich doch viel leichter den von Windows schon vorbereiteten Dialog zugreifen.

Wenn etwas immer wieder gebraucht wird, warum soll man dann immer wieder das Rad neu erfinden? Man kann doch auch eine Library zugreifen, die einem alles das bietet, was man brauct (Bsp GLFW), und man kann jetzt nicht behaupten das das kein vorgefertigtes Fenster ist.

Aber wenn du spaß daran hast, dir immer alles 100% zurechtzufriemeln, dann tu dir kein zwang an.

.filmor

Also ich hab für Spiele bisher immer etwas benutzt, was mir mit einem openWindow mein Fenster geholt hat. Ich brauche ja letztlich nichts anderes als einen OpenGL-Kontext und etwas, was mir die Tasten oder Mauseingaben holt. Das kann mir alles ein Framework liefern.

/edit: yay, glfw meinte ich auch

Juri

@Krux

Ich benutze ja für Dialogsachen auch die vorgefertigte Geschichte, es geht mir aber nicht um Dialoge zum öffnen einer Datei, sondern eher um dieses leerer, meist graue Fenster, was man selber mit Buttons, ListBoxen, CheckBoxen und weiteren füllen kann.

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

akari

Hallo

Juri schrieb:

@Krux

Ich benutze ja für Dialogsachen auch die vorgefertigte Geschichte, es geht mir aber nicht um Dialoge zum öffnen einer Datei, sondern eher um dieses leerer, meist graue Fenster, was man selber mit Buttons, ListBoxen, CheckBoxen und weiteren füllen kann.

Und was ist daran "vorgefertigt"? Das was du meinst ist doch nur ein Designer. Zum Beispiel hat der Builder auch so was. Aber hinter den Komponenten stehen (wenn möglich) die WinAPI-Objekte. Alles was nicht in der (sehr umfangreichen) VCL ist kann einfach über WinAPI zusätzlich angesprochen werden.

Desweiteren hab ich viele Möglichkeiten mit Messages umzugehen, wie zum Beispiel ein Tastendruck oder das verändern der Fenstergröße.

Und? Vernünftige Frameworks haben für alle Gebräuchlichen Messages entsprechende Verarbeitungen. Messages die nicht bereits abgefangen werden können zusätzlich manuell abgefangen werden.

Deshalb ist es Unsinn das du "vorgefertigte" Fenster und WinAPI gegenüberstellst. Sondern Frameworks erweitern und kapseln die WinAPI, bestenfalls ohne die Möglichkeiten einzuschränken.
Die Frage ob eine manuelle WinAPI-Ansprechung verwendet werden soll entscheidet sich eher an der Frage ob das Windows-Layout und Design verwendet werden soll. Schreibe ich eine Büroanwendung sind Frameworks als GUI genau das richtige.
Würde ich ein Spiel schreiben würde ich auch zwecks Styling eigene Controls schreiben. Was natürlich nicht heißt das ich auf Frameworks verzichten muß.

bis bald
akari

akari schrieb:

Hallo
Schreibe ich eine Büroanwendung sind Frameworks als GUI genau das richtige.
Würde ich ein Spiel schreiben würde ich auch zwecks Styling eigene Controls schreiben. Was natürlich nicht heißt das ich auf Frameworks verzichten muß.

Zur Ergänzung:

Da es in Spielen so gebräuchlich ist sich seine eigenen Controls zu erstellen gibt es viele fertige Libraries/Frameworks die man benutzen kann und sie alle arbeiten mit Skins.

Das größte und bekannteste Framework dürfte CEGUI sein.

Hab im Link einen Teil vergessen, hier gehts zur CEGUI Website.

skreutzer

Prinzipiell leuchtet es mir durchaus ein, dass Frameworks und Designer (bzw. RAD allgemein) ziemlich beliebt sind (zwei bisher noch unangesprochene Vorteile sind sicherlich auch, dass es deutlich schneller geht und dass die Fehleranfälligkeit herabgesetzt wird, weil Controls etc. alle getestet wurden und man eine gewisse Garantie für "Fehlerfreiheit" hat, wo beim eigenen Code schon viel öfter Fehler auftauchen dürften).

Auf der anderen Seite sehe ich die Gefahr bei RAD darin, dass man sich mit der Zeit zu sehr an das eine oder andere Framework gewöhnt, sodass es nachher ungeheuer schwierig werden kann, wenn man dann doch mal ein Feature implementieren muss, was nicht von Haus aus mitgeliefert wird (vorausgesetzt, das Framework/der Designer lässt das überhaupt zu). Ebenso ist z.B. das "direkte" Programmieren mit der WinAPI (oder welcher API auch immer, das ist natürlich auch nur eine weitere Abstraktionsschicht) deshalb interessant, weil man dabei mehr über die Interna lernt. Auch stört mich ein wenig die Abhängigkeit, die man sich mit solchen RAD-Tools einhandelt. Wenn es ein Framework für eine Plattform einfach nicht gibt, kann man die entsprechenden User dort nicht erreichen. Aber dieses Problem hat man ja generell, u.a auch speziell bei der Spieleprogrammierung. Ich für meinen Teil bevorzuge Konsolenprogramme, damit kann man nicht viel falsch machen.

thordk

solange etwas "fertiges" den anforderungen genügt, ziehe ich es jederzeit selbstgestrickten sachen vor. warum das rad zweimal erfinden? wenn ich jetzt irgendeine funktionalität benötige, die kein framework direkt unterstützt, dann bleibt mir wohl nichts anderes übrig, als das zeug selbst zu basteln, aber nach meiner erfahrung ist das recht selten. frameworks ersparen einem viel arbeit und zeit.

auch in sachen 3D spieleprogrammierung nehm ich als basis lieber ne engine, die solch sachen wie eingabe events schon abhandelt. wenn die engine bereits alles nötige bietet, um beispielsweise das "anklicken" von objekten zu unterstützen, warum sollte ich mir dann noch selbst ne lösung ausdenken?

marco.b

@Juri:

Hast du schonmal in deinem Berufsleben unter Zeitdruck eine Windowsanwendung geschrieben, welche gewisse Anforderungen erfüllen muss? Ich denke, spätestens dann ist nämlich jeder um stabile Frameworks welche als Abstraktionsschicht dienen, dankbar.

Natürlich ist es auch schön, mit der puren WinAPI umgehen zu können, aber in Zeiten von .NET / Java Swing und dergleichen ist die reine API-Programmierung für die typischen Enterpriseanwendungen recht unpraktisch. Was Spiele etc. betrifft, gebe ich dir natürlich recht.

lolz

proggaholic schrieb:

Hallo.

Prinzipiell leuchtet es mir durchaus ein, dass Frameworks und Designer
(bzw. RAD allgemein) ziemlich beliebt sind (zwei bisher noch unangesprochene
Vorteile sind sicherlich auch, dass es deutlich schneller geht und dass die
Fehleranfälligkeit herabgesetzt wird, weil Controls etc. alle getestet wurden
und man eine gewisse Garantie für "Fehlerfreiheit" hat, wo beim eigenen Code
schon bei beinahe trivialen Sachen gravierende Fehler auftauchen können).

Gut argumentiert.

proggaholic schrieb:

Auf der anderen Seite sehe ich die Gefahr bei RAD darin, dass man sich
mit der Zeit zu sehr an das eine oder andere Framework gewöhnt, sodass es
nachher ungeheuer schwierig werden kann, wenn man dann doch mal ein Feature
implementieren muss, was nicht von Haus aus mitgeliefert wird (vorausgesetzt,
das Framework/der Designer lässt das überhaupt zu).

Die "Gefahr" hast du auch wenn du dein Leben lang mit der Winapi arbeitest und plötzlich eine Anwendung für ein Linux System schreiben sollst. Derjenige der RAD benutzt hat höchstwahrscheinlich sowieso ein plattformunabhängiges Framework und muss sich da nicht erst neu einarbeiten.
Dazu kommt, dass man Zeit spart mit RAD bzw. einem Framework, wenn du dann einmal alle paar Jahre solch ein Feature brauchst kann man sich entweder einarbeiten hast du unterm Strich trotzdem sehr viel Zeit gespart.

proggaholic schrieb:

Ebenso ist z.B. das
"direkte" Programmieren mit der WinAPI (oder welcher API auch immer, das ist
natürlich auch nur eine weitere Abstraktionsschicht) deshalb interessant, weil
man dabei mehr über die Interna lernt.

Wen das interressiert, der kann sich da auch so darüber Informieren. Gibt ja ettliche Bücher die den Aufbau von Windows(NT) beschreiben. Und sogar Vorlesungen über die Architektur von Windows, z.B. hier.

proggaholic schrieb:

Auch stört mich ein wenig die
Abhängigkeit, die man sich mit solchen RAD-Tools einhandelt. Wenn es ein
Framework für eine Plattform einfach nicht gibt, kann man die entsprechenden
User dort nicht erreichen.

Die wahrscheinlichkeit, dass du mit der Winapi bzw. einer nativen API (man beachte, dass POSIX ein Standard ist) auf einer anderen Plattform arbeiten kannst ist geringer, als die Wahrscheinlichkeit, dass es ein Framework für eine andere Plattform gibt.

proggaholic schrieb:

Aber dieses Problem hat man ja generell, u.a auch
speziell bei der Spieleprogrammierung.

Man müsste dieses Problem nicht bei der Spieleprogrammierung haben, aber viele machen es sich zu einem Problem. Gibt auch große Spiele die inzwischen standardmäßig für Windows und Linux herausgegeben werden.
Oder für den Computer und für eine Konsole (das Framework machts möglich).

proggaholic schrieb:

Ich für meinen Teil bevorzuge
Konsolenprogramme, damit kann man nicht viel falsch machen

Bei den Konsolenprogramme benutzt du aber auch ein Framework, auch wenn es nur ein kleines ist.

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Rund um die Programmierung in das Forum Andere GUIs - Qt, GTK+, wxWidgets verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Ja also die WinAPI ist ja am wenigsten Plattformunabhängig. SIcher sinnvolll wenn man sehr kleine Anwendungen schreiben muss oder will, wenn man auch möchte dass das Programm auf eine Diskette passt etc. aber wie gesagt, es passieren zu schnell Fehler oder auf eine Message wird nicht reagiert etc. aber da beides seine Daseinsberechtigung hat möchte ich mich nebst wx auch in WinAPI mehr einarbeiten (stehe zu MASM32 dafür), nach Erfahrungen mit VB5, VB, .NET C# um sowohl mit wx als auch mit reinen, kleinen API-Programmen Laufzeitumgebungs-unabhängige Programme (das ist auch was, auf meinem 133 MHz Laptop möchte und kann ich nicht .NET installieren) zu erstellen. Glaube jedoch nicht dass ich solche Dinge wie bisher mit VB5 auf die Art erstellen werde, mit wx eher.

skreutzer

lolz schrieb:

Die "Gefahr" hast du auch wenn du dein Leben lang mit der Winapi arbeitest und plötzlich eine Anwendung für ein Linux System schreiben sollst. Derjenige der RAD benutzt hat höchstwahrscheinlich sowieso ein plattformunabhängiges Framework und muss sich da nicht erst neu einarbeiten.
Dazu kommt, dass man Zeit spart mit RAD bzw. einem Framework, wenn du dann einmal alle paar Jahre solch ein Feature brauchst kann man sich entweder einarbeiten hast du unterm Strich trotzdem sehr viel Zeit gespart.

Ja, das stimmt allerdings. Ich persönlich halte plattformunabhängige Frameworks oder portable Konsolenprogramme (letzteres vor allem dann, wenn die Art der Anwendung es zulässt) in fast allen Fällen für die "bessere Wahl". Aber wenn es um WinAPI vs. RAD geht, denke ich, kann es nicht Schaden, sich nicht nur auf die "vorgefertigten Fenster" zu verlassen, sondern sich auch mal anzuschauen, warum und wie das ganze überhaupt funktioniert. Dies hilft im Zweifelsfall sogar dabei, das Framework/RAD-Komponenten "richtig" zu benutzen. Was den Zeitfaktor angeht...naja, wofür steht denn das 'R' in "RAD"? Ich denke, das dürfte sowieso jedem klar sein, der zwischen WinAPI und RAD/Frameworks wählen muss.

lolz schrieb:

Die wahrscheinlichkeit, dass du mit der Winapi bzw. einer nativen API (man beachte, dass POSIX ein Standard ist) auf einer anderen Plattform arbeiten kannst ist geringer, als die Wahrscheinlichkeit, dass es ein Framework für eine andere Plattform gibt.

Das eine (API nicht auf anderer Plattform) schliesst das andere (Framework plattformübergreifend) nicht aus.

lolz schrieb:

Man müsste dieses Problem nicht bei der Spieleprogrammierung haben, aber viele machen es sich zu einem Problem. Gibt auch große Spiele die inzwischen standardmäßig für Windows und Linux herausgegeben werden.
Oder für den Computer und für eine Konsole (das Framework machts möglich).

Auch das ist korrekt. Als ich als Beispiel die Spieleprogrammierung herangezogen habe, wollte ich damit nicht den Eindruck erwecken, es gäbe keine guten Alternativen zu den dort bestehenden Abhängigkeiten. Leider werden diese Alternativen noch viel zu wenig genutzt.

lolz schrieb:

Bei den Konsolenprogramme benutzt du aber auch ein Framework, auch wenn es nur ein kleines ist.

Wie meinen? VT100, printf() , Umgebungsvariablen, conio/ncurses, Batch und/oder Shell Scripts?

phlox81

Naja, es ist ja eigentlich nicht nötig WinAPI mit RAD zu vergleichen, weil da vergleicht man imho Äpfel mit Birnen.
Denn alles was ein RAD Editor macht, ist für das jeweilige Framework Code zu erzeugen, nichts weiter.
Diesen Code könnte man genausogut von Hand schreiben, oder einen RAD Editor für WinAPI entwicklen.

phlox81 schrieb:

[...]Denn alles was ein RAD Editor macht, ist für das jeweilige Framework Code zu erzeugen, nichts weiter. [...]

Das muss nichtmal so sein. Es gibt ja durchaus auch GUI-Editoren, die Projektdateien anlegen, die zur Laufzeit geladen werden. Anderes Beispiel sind Windows-Resourcedateien-Dialoge.