Inverse Darstellung erzwingen

[Volkmar]

Zitat von ts-soft

Ich meinte so Sachen, wie Button, wenn selektiert, mit Tastatur drücken,
das geht heutzutage eben mit der Leertaste und nicht mit Enter, wie früher ,
von Edit zu Edit mit Tab und nicht mit Enter, usw.
Soll nicht heißen, früher war alles schlechter, sondern standards ändern sich
und da muss man eben mit, ob man will oder nicht.
Ich sehe zwar ein, das DBase auf dem ersten Blick manchen leichter
erscheint, aber dem ist gar nicht so, SQL ist wesentlich einfacher und
flexibler, man muss es einfach mal ausprobieren.

Von Control zu Control (nicht nur Edit) macht ja der Dialogstil. Und die Buttons mit der Leertaste auch. Enter ist dann nur für den Def-Button relevant. Den Dialogstil verwende ich doch nicht, weil er ein veraltetes Bedienschema ist. Ganz im Gegenteil ist der schon auf der Höhe der Zeit.
DBase war eines der Dinge, was ich in einem einfachen Pascal erst mal nicht habe.

Gruß Volkmar

[Volkmar]

Einen hab ich noch vergessen:

Zitat von ts-soft

Erstmal wäre die Frage zu klären, was ist Stil 512?
Auf jedenfall ist es kein Fensterstil der API sondern irgendetwas
Profanspezifisches. ...
~WS_DLGFRAME usw. ist es anscheinend nicht

Ne stimmt. Ist kein Fensterstil. ist die Funktion, die sich hinter Windows-Dialogen verbirgt. Also durchaus eine windowstypische Funktion, die MS auch ausgiebig nutzt. Wird bei gesetztem Dialogstil anstelle der DefWindowProc gerufen. Deshalb auch &WinProc und &WinDProc. Ist in XProfan eben nur als Fensterstil dargestellt und sollte die Anwendung für den Einsteiger vereinfachen. Wenn anders, also windowsgerechter, dann brauchte es eben zwei Möglichkeiten, ein Hauptfenster zu erstellen. Und CLS wäre nur einer Möglichkeit zuzuordnen. XProfan ist eben nicht nur für API-Virtuosen gemacht .

Gruß Volkmar

[ts-soft]

Für mich vereinfacht sich dadurch nichts, ich bin nur verwirrt. Hab früher
immer von 26 bis über 1000 alles mögliche rumprobiert, bis es so ging, wie
ich es wollte oder hab es einfach sein gelassen.
Inzwischen nutze ich XProfan überwiegend als Batchsprache, wo diese
komischen Stile nicht mehr interessieren.

Da es auch viele Menschen gibt, die irgendwelche Hexzahlen in Messages
schreiben und der Meinung sind, sie Wissen am nächsten Tag noch was das
bedeutet und auf dem Vorzug auch mal in der MSDN nachzuschlagen ver-
zichten, stehe ich vielleicht in dieser Beziehung alleine da , worüber ich
dann aber auch nicht verärgert wäre.

[Frabbing]

Wenn anders, also windowsgerechter, dann brauchte es eben zwei Möglichkeiten, ein Hauptfenster zu erstellen.

Ehrlich gesagt, ein "Hauptfenster" ist doch schon untypisch. Ist auch nichts anderes als ein Parent der Dialogfenster. Und genaugenommen selber auch nur ein Child des Desktop. Ich finde es seltsam, das das unbedingt anders reagieren sollte.

[Volkmar]

Zitat von Frabbing

Ehrlich gesagt, ein "Hauptfenster" ist doch schon untypisch. Ist auch nichts anderes als ein Parent der Dialogfenster. Und genaugenommen selber auch nur ein Child des Desktop. Ich finde es seltsam, das das unbedingt anders reagieren sollte.

Ist aber das Top-Level-Window der Anwendung. Heißt nur in XProfan Hauptfenster. Und wenn ich in Pascal ein generisches Fenster für ein Programm erstelle, dann reagiert das auch bezüglich von Controls wie das Hauptfenster von XProfan. Das Warten auf Loslassen der Maustaste über einem Control, bevor es ein Clickereignis gibt und die besondere Verwendung der Tab-Taste zum Beispiel sind da erst mal nicht drin. Dieses anfängliche "Haupt-"Fenster überläßt es dem Anwender (Programmierer) erst mal, alles selbst zu machen. MS-Paint hat eben zum Beispiel keine Buttons, dafür aber mehr Freiheiten. Jede Botschaft, die das System nicht unbedingt braucht, kommt unverändert durch.
Ich denke mal, das dachte sich MS dabei, zwei verschiedene Fensterfunktionen anzubieten. Einmal maximale Freiheit und einmal erhöhten Komfort, also das ganze Benutzerinterface schon eingebaut. Das oberste Fenster einer Anwendung eben mit maximaler Freiheit und die untergeordneten Fenster mit dem entsprechenden Komfort in der Bedienung.
Im alten Profan gabe es den Dialogstil anfänglich auch nicht. Unschön, wenn man da ein paar Controls auf dem Fenster hatte, die nicht so reagierten, wie in jedem anderen Programm. Also Deine Idee, Dialogstil immer drin könnte mir gefallen. Ob es dabei aber nicht doch irgendwas gibt, was dann wieder nicht geht?

Gruß Volkmar

[RGH]

Volkmar hat das schon sehr korrekt analysiert.
Es war eben wohl die ursprüngliche Programm-Philosphie von Windows, dass es ein Hauptfenster mit Menü gibt und über die Menüpunkte die einzelnen Dialogfenster aufgerufen werden. Im Hauptfenster ist dann eben das Bild (z.B. bei Paint) oder der mit DrawText gemalte Text im WYSIWYG-Stil (z.B. Write), aber außer vielleicht einem MultiEdit (z.B. bei Notepad) keine weiteren Dialogelemente. Dafür reagiert dieses Hauptfenster aber auch auf Mausklicks in den Clientbereicht mit Übergabe der Position an die Message, was bei einem normalen Dialogfenster nicht der Fall ist. So hat Microsoft eben diese zwei grundsätzlichen Fensterstile geschaffen, die auch zwei unterschiedliche Default-Fensterroutinen verwenden und daher sehr unterschiedlich reagieren. Das hat Profan auch von Anfang an so genutzt. Als dann (auch bei mir) immer häufiger der Wunsch aufkam, auch Dialogelemente auf dem Hauptfenster (mit Menü) zu plazieren, habe ich eben den Fensterstil 512 eingeführt, der dann eben die Dialog-Fensterroutine nutzt. Und seither gibt es in Profan halt die vier grundlegenden Fenster: Hauptfenster normal, Hauptfenster mit Dialogstil, Dialoge mit create("Dialog", ...) und Fenster mit create("Window", ...).

Gruß
Roland

[Frabbing]

Danke für die Erklärung.
Ist wohl schwierig, den Style von jetzt an voreingestellt zu setzen, z.B. wenn kein WindowStyle im Code vorkommt? Könnte dann verwirren.

[_Joerg_]

Könnte man vielleicht mit einer Voreinstellung machen. Gibt's die profan.ini eigentlich noch? Sonst könnte ein Parameter, der von der IDE an den Compiler übergeben wird das evtl. regeln.

[Frabbing]

Sonst könnte ein Parameter, der von der IDE an den Compiler übergeben wird das evtl. regeln.

Dann reagiert der Code aber interpretiert anders.

[_Joerg_]

Der Interpreter muß das natürlich auch auswerten.