Unterstütze Auflösung von euren Programmen

[CodeFinder]

Ynnus schrieb:

Warum sollte man das denn "immer" so machen? Ich erstelle meine komplette GUI bevor ich in die Message-Abhandlung einsteige.

D.h. dann wo ? In der WinMain ?

[Ynnus]

CodeFinder schrieb:

Ynnus schrieb:

Warum sollte man das denn "immer" so machen? Ich erstelle meine komplette GUI bevor ich in die Message-Abhandlung einsteige.

D.h. dann wo ? In der WinMain ?

Klar. Kannst du mir einen Grund nennen, wieso ich es anders machen sollte?
Am Ende der WinMain kommt dann die Message-Abhandlung und bis dahin habe ich die GUI komplett erstellt. Am Ende wird das Hauptfenster sichtbar gestellt und alles ist perfekt eingerichtet. Die Messages dienen dann zur Abhandlung der Eingabebefehle.

[KILLSMAKER]

Normerweise positioniert man seine Child-Window immer unter WM_SIZE und passt die Fensteraufteilung
dem Parent-Window so immer dynamisch an.

Sry, dass ich jetzt nochmals nachfragen muss, aber was verstehst du jetzt genau unter einer dynamischen Positionierung unter WM_SIZE. Meine Theorie mit %-Angaben habe ich nun aufgegeben!

mfg killsmaker

PS: Wahrscheinlich denk ich mal wieder zu kompliziert

[CodeFinder]

Ynnus schrieb:

Klar. Kannst du mir einen Grund nennen, wieso ich es anders machen sollte?[...]

Mal davon abgesehen das es unüblich schreibt die MSDN:

MSDN zu WM_CREATE schrieb:

The WM_CREATE message is sent when an application requests that a window be created by calling the CreateWindowEx or CreateWindow function. (The message is sent before the function returns.) The window procedure of the new window receives this message after the window is created, but before the window becomes visible.

Daher geht also hervor das Microsoft diese Nachricht aus genau diesen Zweck implementiert hat.

Du kannst es zwar (hoffe ich mal) auch anders machen, aber es ist unüblich...außerdem brauchst du doch i.d.R. in deiner
WndProc die Handle der Child-Fenster...Wie lößt du das ? Globale Variablen ?

[CodeFinder]

KILLSMAKER schrieb:

[...]
Sry, dass ich jetzt nochmals nachfragen muss, aber was verstehst du jetzt genau unter einer dynamischen Positionierung unter WM_SIZE. Meine Theorie mit %-Angaben habe ich nun aufgegeben!

mfg killsmaker

PS: Wahrscheinlich denk ich mal wieder zu kompliziert

Naja immer wenn dein Fenster verkleinert oder vergrößert wird bekommt es eine WM_SIZE-Nachricht.
Aufgrund der Nachricht passt du dann deine Child-Fenster-Positionen dynamisch, also in der R-T
an.

[Ynnus]

CodeFinder schrieb:

Ynnus schrieb:

Klar. Kannst du mir einen Grund nennen, wieso ich es anders machen sollte?[...]

Mal davon abgesehen das es unüblich schreibt die MSDN:

MSDN zu WM_CREATE schrieb:

The WM_CREATE message is sent when an application requests that a window be created by calling the CreateWindowEx or CreateWindow function. (The message is sent before the function returns.) The window procedure of the new window receives this message after the window is created, but before the window becomes visible.

Daher geht also hervor das Microsoft diese Nachricht aus genau diesen Zweck implementiert hat.

Du kannst es zwar (hoffe ich mal) auch anders machen, aber es ist unüblich...außerdem brauchst du doch i.d.R. in deiner
WndProc die Handle der Child-Fenster...Wie lößt du das ? Globale Variablen ?

Okay, die WM_CREATE ist dafür da, aber es gibt auch zahlreiche andere Messages, die einem Sachen leichter machen, die man aber nicht verwendet. Ist eben eine Möglichkeit zu machen, es geht aber wohl auch anders, wie man sieht.
Jedenfalls erstelle ich meine Fenster nicht mit globalen Variablen sondern sondern mit private-Variablen in eigenen Fensterklassen. Ich habe also eine Klasse welch mit einer Create-Methode ein Fenster erstellt. Von dieser Klasse erben andere Elemente wie ein Button, das Editfeld usw. Das Object merkt sich das Handle des erstellten Fensters und noch ein paar andere Dinge. Für Childfenster, die auf dem Parent erstellt werden sollen, kann man mittels objectname.get_hwnd() das Handle zum werdenden Parent erfahren. Wie gesagt, alles OOP, demnach ist auch das Childfenster ein Object der Fensterklasse welches sich das eigene Handle zum Fenster speichert UND in dem Fall, da es ein Child ist, noch das Handle zum Parent-Fenster.
Um nochmal zum WM_SIZE zu kommen, mit meiner Methode kann man dann die Fenster in der WM_SIZE mittels eigener Methode "objectname.move(x, z)" verschieben. In der Methode der Klasse wird dann dort SetWindowPos() aufgerufen und das interne Handle zum Fenster verwendet. Damit muss ich es nicht immer selbst wissen sondern nur den Namen des OOP-Fenster-Objects, was alles erheblich erleichtert.

BTW: Meine GUI-Erstellung umfasst 800 Zeilen Code (nur der Aufruf der Methoden zur Erstellung der Fenster, insgesammt wären es sonst über 4000 Zeilen)
Soll ich das wirklich alles in die WM_CREATE packen?
Oder die Move- und Resize-Methoden der Fenster, auch noch gut 200 GUI-Objecte, soll ich die jedesmal in der WM_SIZE verschieben und Größenanpassen? Meiner Meinung nach zu viel Rechenaufwand.

[KILLSMAKER]

So langsam wirds peinlich, aber ich bin hier um zu fragen:
Was macht ihr nun genau mit den neuen Daten (Auflösung)!

Machen wir ein einfaches Beispiel:

Der User ändert die Auflösung von 1024*768 auf 800*600:

Was passiert jetzt mit einem Button, der sich bei 820 * 650 befand und eine Größe hatte von 100*40.
Man kann ihn ja nun nicht einfach verschieben, damit er wieder sichtbar ist, denn dann würde er sich eventuell mit einem anderen Button überlagern, der nicht verschoben werden musste.

mfg killsmaker

PS: Ich bin heute ein harter Fall. Es tut mit Leid. Was ist mit R-T gemeint

[Ynnus]

KILLSMAKER schrieb:

So langsam wirds peinlich, aber ich bin hier um zu fragen:
Was macht ihr nun genau mit den neuen Daten (Auflösung)!

Machen wir ein einfaches Beispiel:

Der User ändert die Auflösung von 1024*768 auf 800*600:

Was passiert jetzt mit einem Button, der sich bei 820 * 650 befand und eine Größe hatte von 100*40.
Man kann ihn ja nun nicht einfach verschieben, damit er wieder sichtbar ist, denn dann würde er sich eventuell mit einem anderen Button überlagern, der nicht verschoben werden musste.

mfg killsmaker

PS: Ich bin heute ein harter Fall. Es tut mit Leid. Was ist mit R-T gemeint

Wenn du einen Button dort hast, ist die Frage, ob oben Platz ist, um ihn weiter hoch zu verschieben. Wenn alles "zugebaut" ist mit anderen Buttons, deren Größe du nicht ändern kannst, ist die GUI einfach zu groß für 600 Pixel Vertikal. Aber wenn darüber beispielsweise eine List-Box kommt, welche Z.B. 200 Pixel hoch ist, dann kannst du diese Listbox verkleinern und den Button um die Gleiche Länge Hochschieben.

Du solltest die Sache aber von Anfang an anders bedenken und dich Anhand der rechten unteren Ecke des Fensters orientieren. Also beispielsweise hast du die besagte List-Box von 200 Pixeln Höhe und darunter in Abstand von 10 Pixeln ein Button in der Höhe von 20 Pixeln. Dein Fenster hat eine solche Höhe, dass es genau unter dem Button nach 10 Pixeln endet.
Speichere diese Größe des Fensters in einer Variablen, etwa fenster_size_y oder so. (nur ein Beispiel, wie genau du das machst, ist jetzt wurscht)
Nehmen wir an, das Fenster ist nun 240 Pixel hoch, die Listbox ist also oben total am Rand des Fensters angeordnet, dann 10 Pixel, dann der Button, dann 10 Pixel, dann Ende des Fensters.
Wenn du jetzt dein Fenster verkleinerst in der Höhe, würde der Button nach 10 Pixeln durch den Rand abgeschnitten werden. In der WM_SIZE fragst du also die neue Größe des Hauptfenster ab und vergleichst sie mit der Größe aus der Variable fenster_size_y. Angenommen du hast das Fenster um 50 Pixel verkleinert, dann würde deine Rechnung so aussehen: 400 Pixel (alte Größe) - 350 Pixel (neue Größe) = 50 Pixel Differenz. Also musst du nun deinen Button, welcher 10 Pixel über dem Fensterrand erscheinen soll, um 50 Pixel hochschieben, damit er an dieser Position weiterhin bleibt. Deine Listbox, welche über dem Button angeordnet ist, muss ebenfalls um 50 Pixel hoch. Da die Box oben an den Rand des Fensters stößt (in unserem Beispiel hier, in deinem programm kann es auch so sein, dass oben Elemente sind, die man nicht verschieben kann, weil es zu dicht angeordnet ist.), kannst du sie nur kleiner machen. Bei einer Listbox kein Problem, da diese ja nicht so an ihre Größe Gebunden ist wie ein Button. Also bleibt die Listbox an Ort und Stelle, wird aber in der Höhe um die 50 Pixel Differenz verkleinert. Damit sieht es dann genauso aus wie vor der Fensterverkleinerung, erst Listbox, dann 10 Pixel, dann Button, dann 10 Pixel, dann Fensterende. Nur diesmal ist die Listbox etwas kleiner und dient uns als Puffer für Größenänderungen.
Mit dieser Methode kannst du das Fenster nun auch größer ziehen, die Listbox wird damit auch größer, der Button wandert mit runter und bleibt immer in 10 Pixel Abstand von Fenster und Listbox.

Natürlich gibt es Probleme, wenn du das Fenster so mini machst, dass die Listbox nur noch wenige Pixel hoch ist, da sie dann ihren Sinn als Liste verfehlt.
Man muss also schon ein bisschen intelligent planen, wie man was anordnet.

Hoffe du hast verstanden, wie ich das jetzt meinte. ist nicht ganz so einfach zu beschreiben, so theoretisch. ^^

[KILLSMAKER]

So danke. Hat mir doch mal sehr geholfen. Ich war wahrscheinlich nur durch den 2. Post verwirrt

Nutzt du etwa Pixel-Angaben?

mfg killsmaker

PS: Danke an alle für die schnelle Hilfe!

[CodeFinder]

Ynnus schrieb:

[...]
Okay, die WM_CREATE ist dafür da, aber es gibt auch zahlreiche andere Messages, die einem Sachen leichter machen, die man aber nicht verwendet. Ist eben eine Möglichkeit zu machen, es geht aber wohl auch anders, wie man sieht.
[...]

Welche andern Messages ?

Ynnus schrieb:

Jedenfalls erstelle ich meine Fenster nicht mit globalen Variablen sondern sondern mit private-Variablen in eigenen Fensterklassen. Ich habe also eine Klasse welch mit einer Create-Methode ein Fenster erstellt. Von dieser Klasse erben andere Elemente wie ein Button, das Editfeld usw. Das Object merkt sich das Handle des erstellten Fensters und noch ein paar andere Dinge. Für Childfenster, die auf dem Parent erstellt werden sollen, kann man mittels objectname.get_hwnd() das Handle zum werdenden Parent erfahren. Wie gesagt, alles OOP, demnach ist auch das Childfenster ein Object der Fensterklasse welches sich das eigene Handle zum Fenster speichert UND in dem Fall, da es ein Child ist, noch das Handle zum Parent-Fenster.

Hmm und wo erstellst du deine Objekte (in welchen Gültigkeitsbereich?)?
Jo verstehe. Das heißt du arbeitest mit einer gekapselten WinAPI . Damit wird KILLSMAKER aber sicherlich nichts anfangen können, da er ja in C codet.

Ynnus schrieb:

Um nochmal zum WM_SIZE zu kommen, mit meiner Methode kann man dann die Fenster in der WM_SIZE mittels eigener Methode "objectname.move(x, z)" verschieben. In der Methode der Klasse wird dann dort SetWindowPos() aufgerufen und das interne Handle zum Fenster verwendet. Damit muss ich es nicht immer selbst wissen sondern nur den Namen des OOP-Fenster-Objects, was alles erheblich erleichtert.

Jojo, schon klar...aber siehe oben...KILLSMAKER hat keine OPP-WinAPI .

Ynnus schrieb:

BTW: Meine GUI-Erstellung umfasst 800 Zeilen Code (nur der Aufruf der Methoden zur Erstellung der Fenster, insgesammt wären es sonst über 4000 Zeilen)
Soll ich das wirklich alles in die WM_CREATE packen?

Jo, mal BTW. Kennst du Schleifen ?

Ynnus schrieb:

Oder die Move- und Resize-Methoden der Fenster, auch noch gut 200 GUI-Objecte, soll ich die jedesmal in der WM_SIZE verschieben und Größenanpassen? Meiner Meinung nach zu viel Rechenaufwand.

Hm wie machst dus denn sonst...der Rechenaufwand bleibt zwangsläufig der selbe. Da kann sich doch logischerweise nichts ändern.

@KILLSMAKER: R-T = Run-Time .

[CodeFinder]

Ynnus schrieb:

Natürlich gibt es Probleme, wenn du das Fenster so mini machst, dass die Listbox nur noch wenige Pixel hoch ist, da sie dann ihren Sinn als Liste verfehlt.
Man muss also schon ein bisschen intelligent planen, wie man was anordnet.

Jo dazu vllt. noch WM_GETMINMAXINFO

[Ynnus]

CodeFinder schrieb:

Ynnus schrieb:

[...]
Okay, die WM_CREATE ist dafür da, aber es gibt auch zahlreiche andere Messages, die einem Sachen leichter machen, die man aber nicht verwendet. Ist eben eine Möglichkeit zu machen, es geht aber wohl auch anders, wie man sieht.
[...]

Welche andern Messages ?

Das war nur ein unausgeführtes Beispiel für allerlei Messages die man verwenden KANN, aber nicht muss. Jedenfalls habe ich etliche Steuerelemente, wo ich nicht jede Message, die sie erzeugen, auswerte. Könnte man machen, für gewisse Dinge, geht aber auch anders. Ich wollte damit nur sagen, dass WM_CREATE vielleicht für gewisse Dinge praktisch ist, für mich aber hier unnötig erscheint.

CodeFinder schrieb:

Ynnus schrieb:

Jedenfalls erstelle ich meine Fenster nicht mit globalen Variablen sondern sondern mit private-Variablen in eigenen Fensterklassen. Ich habe also eine Klasse welch mit einer Create-Methode ein Fenster erstellt. Von dieser Klasse erben andere Elemente wie ein Button, das Editfeld usw. Das Object merkt sich das Handle des erstellten Fensters und noch ein paar andere Dinge. Für Childfenster, die auf dem Parent erstellt werden sollen, kann man mittels objectname.get_hwnd() das Handle zum werdenden Parent erfahren. Wie gesagt, alles OOP, demnach ist auch das Childfenster ein Object der Fensterklasse welches sich das eigene Handle zum Fenster speichert UND in dem Fall, da es ein Child ist, noch das Handle zum Parent-Fenster.

Hmm und wo erstellst du deine Objekte (in welchen Gültigkeitsbereich?)?
Jo verstehe. Das heißt du arbeitest mit einer gekapselten WinAPI . Damit wird KILLSMAKER aber sicherlich nichts anfangen können, da er ja in C codet.

Die Objekte sind global gültig, damit ich sie von überall her ändern kann. Ich habe ein relativ umfangreiches Programm (im Vergleich zu einem Texteditor o.Ä.) mit zusätzlich noch einem OpenGL-Bereich usw, da habe ich zahlreiche Funktionen außerhalb des Callbacks, die einen globalen Gültigkeitsbereich der Fenster erfordern, da ich von dort aus auf sie zugreifen muss.

CodeFinder schrieb:

Ynnus schrieb:

BTW: Meine GUI-Erstellung umfasst 800 Zeilen Code (nur der Aufruf der Methoden zur Erstellung der Fenster, insgesammt wären es sonst über 4000 Zeilen)
Soll ich das wirklich alles in die WM_CREATE packen?

Jo, mal BTW. Kennst du Schleifen ?

Es geht mir dabei nicht um die Menge an Zeilen sondern um den Rechenaufwand, jede der 200 GUI-Elemente in der WM_SIZE abzuarbeiten. Ich kann hier keine Schleifen verwenden, da ich den Objekten eigenständige Namen gebe und dazu noch etliche Informationen über die Position, die genutzte Callback-Funktion, Titel und der WM_COMMAND-identifikation usw. Alles eben in einer objectname.create()-Funktion. Das ist mit Schleifen und Variablen schwer zu realisieren. Ich schreibe somit jedes Objekt aus, etwa so:
mainwindow.create(...,...,... usw);
openglwindow.create(...,.. usw);
frm_framebox.create(...);
btn_objwnd_size_x.create(...);
btn_objwnd_size_y.create(...);

Sicher kann ich die Objekte in einem Array per Schleife anlegen aber der Aufwand, das automatisch mit Schleife zu realisieren ist größer, als per Hand die Elemente hinzuzufügen. Und wie schon erwähnt muss ich aus vielen Funktionen auf die Fenster zurückgreifen, da ist es leichter, sie beim Namen zu nennen. Also wnd_mainwindow.move() anstatt fensterarray[293].move, wo ich am Ende nicht mehr weiß, welches Fenster sich nun bewegen soll.

Ich drücke mich gerade sehr wirr aus, ich weiß, aber in der Theorie ist das ziemlich blöd zu erklären. Es sind auch jeden Fall eine Hand voll unterschiedlicher Klassen die Objekte haben und auf unterschiedliche Weise mit verschiedensten Parametern erstellt werden, für eine automatische Schleife zu umständlich zu realisieren. So. ^^

CodeFinder schrieb:

Ynnus schrieb:

Oder die Move- und Resize-Methoden der Fenster, auch noch gut 200 GUI-Objecte, soll ich die jedesmal in der WM_SIZE verschieben und Größenanpassen? Meiner Meinung nach zu viel Rechenaufwand.

Hm wie machst dus denn sonst...der Rechenaufwand bleibt zwangsläufig der selbe. Da kann sich doch logischerweise nichts ändern.

Nein, wie gesagt, ich sehe keinen Sinn darin, jedes Element in der WM_SIZE Größenanzupassen. Das mache ich mit den wichtigen Elementen, wie Listen und Frames, die sich bei Vergrößerung oder Verkleinerung an die neue Fenstergröße anpassen und ihre Größe Ändern. Ein Button hat immer die Größe (z.B.) 80, 20 und wird da nicht geändert. Deshalb steht er auch nicht in der WM_SIZE und damit umfasst die WM_SIZE bei mir auch nur etwa 40 Zeilen der wichtigsten Dinge, die geändert werden.

[CodeFinder]

Hi nochmal,

Ynnus schrieb:

Die Objekte sind global gültig[...]

LOL ...Na also...und das soll man ja bekanntlich vermeiden...

Ynnus schrieb:

Ich kann hier keine Schleifen verwenden, da ich den Objekten eigenständige Namen gebe und dazu noch etliche Informationen über die Position, die genutzte Callback-Funktion, Titel und der WM_COMMAND-identifikation usw. Alles eben in einer objectname.create()-Funktion. Das ist mit Schleifen und Variablen schwer zu realisieren. Ich schreibe somit jedes Objekt aus

Doch! Ok 'können' hängt hier ja noch von anderen Faktoren ab . Aber du kennst doch Arrays oder ? ...
Du kannst da, für 'genutzte Callback-Funktion' Funktionstabs erstellen und 'Titel' in ein 1-dimensionales std::string-Array schreiben...das gleiche gilt für Positions und Control-Id's ... .
Ich verstehe zwar, dass du gerne mit korrekt 'benannten' Objekten arbeitest....aber auch da gibt Wege...zum Beispiel dieser:

CExampleClass cObjects[100];
enum EObjectIndex
{
   main_window = 0,
   open_gl_window = 1,
  // usw...
};

// Benutzung dann so:
cObjects[main_window].Method(params);

Ynnus schrieb:

[...]aber in der Theorie ist das ziemlich blöd zu erklären. Es sind auch jeden Fall eine Hand voll unterschiedlicher Klassen die Objekte haben und auf unterschiedliche Weise mit verschiedensten Parametern erstellt werden, für eine automatische Schleife zu umständlich zu realisieren. So. ^^

Jo stimmt!^^ Ich glaub wir reiten hier auch auf Kleinigkeiten herum...aber die Idee mit der Enum als Index ist schon raffiniert^^

Ynnus schrieb:

[...]Ein Button hat immer die Größe (z.B.) 80, 20 und wird da nicht geändert. Deshalb steht er auch nicht in der WM_SIZE und damit umfasst die WM_SIZE bei mir auch nur etwa 40 Zeilen der wichtigsten Dinge, die geändert werden.

lol, jo genau so hatte ich das auch gemeint...alle die Controls die angepasst werden müssen kommen unter WM_SIZE, alle fixierten werden bei der Erstellung auf die richtige Pos./Größe gesetzt...wir meinten also das gleiche .