Messagecomposer

[danny61]

Hallo,
ist euch eigentlich aufgefallen das es seit kurzem ein neues Feature im svn gibt ?
Den Messagecomposer findet ihr unter components.
Mit ihm kann man mit STRG+M Messages (ShowMessage, MessageDlg, Inputbox etc) über eine Maske anlegen und auch schon entsprechenden Code erzeugen lassen, wie if then else oder case ...
Ein sehr praktisches Tool, wie ich finde.
Da es wohl noch Probleme mit der Darstellung unter GTK2 gibt, wird er noch nicht standartmäßig in die IDE integriert.
bis dann Daniel

[pluto]

Interessant ! Leider habe ich keine svn Version von Lazarus mit components meinst du bestimmt das Verzeichnis von Lazarus oder ? Da ist das aufjedenfall bei mir nicht dabei.

[knight]

Da es wohl noch Probleme mit der Darstellung unter GTK2 gibt,

Ich habe mit GTK2 keine Probleme feststellen können.

knight

[pluto]

Ich hatte aber in meinen letzten versuchen auch einige Probleme mit GTK2 z.b. meine ich die Paintbox hat sich anders verhalten.(Wie genau weiß ich nicht mehr) und auch noch andere kleine Probleme. Darum nutzte ich auch nur GTK1. Würde aber wenn es laufen würde auch QT nehmen weil es dort einfach mehr Komponenten gibt z.b. im QT-Desinger. Dann könnte dort noch mehr Komponenten erstellt werden die dann halt auf QT Basieren und somit leider nicht mehr Plattformunhabnig sind/währen. Allerdings weiß ich nicht ob man das rechtlich darf und in wie weit das überhaupt geht. Aber es währe Interessant.

[ErnstVolker]

Hallo,

ich bin auf der Suche nach einer Möglichkeit die Größe einer InputBox zu beeinflussen. Ich finde sie für die Eingabe einer Zahl von 5 bis 7 Stellen einschl. Komma und Nachkomma auf meinem Schirm zu breit.

Da bin ich auf den Messagecomposer gestoßen. Aber leider gelingt hier die Größenvorgabe nicht mit.

Geht das überhaupt?

Danke und viele Grüße

Volker

[theo]

Da es wohl noch Probleme mit der Darstellung unter GTK2 gibt,

Ich habe mit GTK2 keine Probleme feststellen können.

Doch, aber ich glaube nicht, dass man das auf GTK2 schieben kann.
Der Dialog ist im Ggs. zu anderen nicht in der Grösse verstellbar und skaliert schlecht (bzw. nicht) z.B. bei größeren Fonts/Themes.

[wp_xyz]

Ich habe das Layout überarbeitet, der MessageComposer in Trunk sollte nun besser skalieren und kann auch in der Breite verändert werden.

[theo]

Ich habe das Layout überarbeitet, der MessageComposer in Trunk sollte nun besser skalieren und kann auch in der Breite verändert werden.

Danke!
Aber eben nur in der Breite.
Die Überlappungen bei "Source Wrapper" bleiben (siehe Bild oben).

[wp_xyz]

Oh, ich hatte die "begin...end" Checkbox gar nicht gesehen, weil sie offenbar völlig überdeckt war. Müsste jetzt stimmen. Ich habe auch sämtliche Constraints rausgenommen: wenn es auf Windows passt, dann aber nicht mehr auf Linux.

[wp_xyz]

ich bin auf der Suche nach einer Möglichkeit die Größe einer InputBox zu beeinflussen. Ich finde sie für die Eingabe einer Zahl von 5 bis 7 Stellen einschl. Komma und Nachkomma auf meinem Schirm zu breit.

Da bin ich auf den Messagecomposer gestoßen. Aber leider gelingt hier die Größenvorgabe nicht mit.

Geht das überhaupt?

Mit dem MessageComposer kann man das nicht machen, das ist ein Tool, wenn man die Parameter für die diversen Eingabedialoge interaktiv ausprobieren möchte, ohne jeweils das Programm neu kompilieren zu müssen.

In der Unit Dialogs bin ich aber auf die Funktion

Code: Alles auswählen

function DefaultInputDialog(const InputCaption, InputPrompt : String; MaskInput : Boolean; var Value : String) : Boolean;

gestoßen. Während die "normalen" InputQuery und "InputBox" vom Widgetset zur Verfügung gestellt werden und daher nicht verändert werden können, ist DefaultInputDialog in Pascal programmiert und man kann sich den Quelltext anschauen. Für die Formularbreite gibt es zwar keinen direkten Parameter, es geht alles per AutoSize, aber die Breite des Edit-Control wird über einen Minimal-Wert kontrolliert:

Code: Alles auswählen

      MinEditWidth := Min(AMonitor.Width - 20,  Max(Scale96ToScreen(cInputQueryEditSizePixels), AMonitor.Width * cInputQueryEditSizePercents div 100)); 

je nachdem was größer ist, bestimmen cInputQueryEditSizePixels oder cInputQueryEditSizePercents die Breite des Edit und damit des Fensters. Die Werte sind als initialisierte "Konstanten" öffentlich deklariert und können somit vom Programm angepasst werden:

Code: Alles auswählen

const
  cInputQueryEditSizePixels: integer = 260; // Edit size in pixels
  cInputQueryEditSizePercents: integer = 25; // Edit size in % of monitor width

Wenn du also eine Formularbreite von (etwa) 300 Pixeln willst, dann kannst du das folgende ausprobieren:

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var
  s: String = '';
begin
  cInputQueryEditSizePercents := 0;
  cInputQueryEditSizePixels := 300;
  if DefaultInputDialog('Caption', 'Prompt', false, s) then
    ShowMessage('Eingabe: ' + s);
end;  

[theo]

Oh, ich hatte die "begin...end" Checkbox gar nicht gesehen, weil sie offenbar völlig überdeckt war. Müsste jetzt stimmen. Ich habe auch sämtliche Constraints rausgenommen: wenn es auf Windows passt, dann aber nicht mehr auf Linux.

Ja, jetzt läuft das Ding tip-top, auch auf GTK2.

Danke!

[pluto]

Die Werte sind als initialisierte "Konstanten" öffentlich deklariert und können somit vom Programm angepasst werden:

Wie können Konstanten angepasst werden und quasi als Variablen verwendet werden? Das verstehe ich jetzt nicht so ganz...

[wp_xyz]

Das gedanklich widersprüchliche Konzept mit den "typisierten Konstanten" (ich hatte oben "initialisierte" geschrieben - sorry), die eigentlich initialiserte Variable sind, gibt es seit Urzeiten in der Sprache Pascal (https://www.freepascal.org/docs-html/ref/refse10.html).

Ob man die "Konstante" wirklich ändern kann, wird durch die Direktive $WriteableConst (oder $J) bestimmt (https://wiki.freepascal.org/sWritableconst/de), die aber standardmäßig aktiv ist. Mein Tipp funktioniert also nur in diesem Standard-Modus!

Es wäre zu überlegen, ob man nicht die Deklaration der beiden Werte auf "var" ändern sollte, um von der Compilereinstellung (und dem gedanklichen Widerspruch) wegzukommen.

[pluto]

Das gedanklich widersprüchliche Konzept mit den "typisierten Konstanten" (ich hatte oben "initialisierte" geschrieben - sorry), die eigentlich initialiserte Variable sind, gibt es seit Urzeiten in der Sprache Pascal (https://www.freepascal.org/docs-html/ref/refse10.html).

Aus meiner Sicht, ist das keine "Saubere" Programmierung...

Ob man die "Konstante" wirklich ändern kann, wird durch die Direktive $WriteableConst (oder $J) bestimmt (https://wiki.freepascal.org/sWritableconst/de), die aber standardmäßig aktiv ist. Mein Tipp funktioniert also nur in diesem Standard-Modus!

Aber gut zu wissen, dass es so ein Verhalten überhaupt gibt, ich dachte Konstanten heißen Konstanten weil man sie eben NICHT verändern kann.

Du hast aber schon oben geschrieben, dass es ein "widersprüchliche Konzept" ist.

Die Unterstützung für die Zuweisung von Werten an typisierte Konstanten wird durch die Direktive {$J} gesteuert: Sie kann ausgeschaltet werden, ist aber standardmäßig eingeschaltet (für Turbo Pascal-Kompatibilität). Initialisierte Variablen sind immer erlaubt.

Ist schon lustig(oder eher traurig? ), dass man an so alte Sachen fest hält...