Entwickler-Ecke
Grafische Benutzeroberflächen (VCL & FireMonkey) - MessageDLG selbst gebaut
Jakane - Fr 25.05.12 15:45
Titel: MessageDLG selbst gebaut
Hallo liebe Delphi-Helfer :)
Viele reden davon, aber keiner erklärt wie das gehen soll.
Ich habe ein Formular was schon das macht was ich will.
Mein Problem ist das Result.
Beim MessageDLG kann man auf MRYes, MRNo ect prüfen.
Dafür muss man per Schalter einen Result übertragen.
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:
| procedure TfmHaupt.BBtn1Click(Sender: TObject); begin ShowMessage(FuP_S._Abfragefenster); end;
function TFuP_S._Abfragefenster(): String; begin Application.CreateForm(TFuP_S, FuP_S); end; |
Das Fenster baut sich wie gewünscht auf und ich habe mehrere Schalter auf dem Formular.
Aber wie übergebe ich jetzt das Resultat, welcher Schalter gedrückt wurde, an das ShowMessage?
Hoffe jemand hat eine Idee :)
Danke im Vorraus
Moderiert von
Narses: Delphi-Tags hinzugefügtModeriert von
Narses: Topic aus Dateizugriff verschoben am Fr 25.05.2012 um 15:55
DonManfred - Fr 25.05.12 15:58
Meinst du vielleicht das?
Delphi-Quelltext
1:
| form1.ModalResult := mrOk |
jaenicke - Fr 25.05.12 17:39
Du kannst auch einfach bei den Buttons deren Eigenschaft ModalResult setzen.
Nebenbei gehören Unterstriche in Bezeichnern nicht gerade zu einem guten Programmierstil. ;-)
Ein Beispiel findest du im Anhang.
dummzeuch - So 27.05.12 13:21
jaenicke hat folgendes geschrieben : |
Nebenbei gehören Unterstriche in Bezeichnern nicht gerade zu einem guten Programmierstil. ;-)
|
Sagt wer?
jaenicke - So 27.05.12 17:13
dummzeuch hat folgendes geschrieben : |
jaenicke hat folgendes geschrieben : |
Nebenbei gehören Unterstriche in Bezeichnern nicht gerade zu einem guten Programmierstil. ;-)
|
Sagt wer? |
Für die Schreibweise von Delphi-Quelltext gibt es hier einen Styleguide:
Ich zumindest brauche auch deutlich länger, wenn ein Text oder Quelltext statt ganzen Wörtern und Groß- und Kleinschreibung nur einzelne Buchstaben und Unterstriche enthält, um zu verstehen was gemeint ist (und FuP_S versteht man z.B. ohnehin nur in dem Moment, in dem man es schreibt).
(Und zudem finde ich es einfach hässlich und unaufgeräumt in Quelltexten, aber das ist natürlich rein subjektiv.)
Ich zumindest halte mich an die Konventionen und kann die Quelltexte so auch nach Jahren noch sehr gut und schnell lesen. (Und dank Codeformatter auch fremde, aber der entfernt leider Unterstriche und andere Schweinereien :mrgreen: nicht.)
Aber die Diskussion auszuweiten, passt wohl nicht ganz hierher. Dass Unterstriche schlechter Stil sind, hielt ich aber aus vergangenen ähnlichen Diskussionen für allgemein akzeptiert... (im Gegensatz zu anderen Sachen)
Jakane - Di 29.05.12 10:05
jaenicke hat folgendes geschrieben : |
Du kannst auch einfach bei den Buttons deren Eigenschaft ModalResult setzen. |
Das ist schonmal nicht schlecht, zum lernen, aber eigendlich wollte ich die Results quasi komplett selbst gestalten, so da ich auch anderes übergeben kann als Result. zB Zahlen oder Namen. Je nachdem was ich vordefiniere.
jaenicke hat folgendes geschrieben : |
Nebenbei gehören Unterstriche in Bezeichnern nicht gerade zu einem guten Programmierstil. ;-) |
Leider muss ich mich dem Programmierstil meiner Firma anpassen ^^ und da ist der _ die Abgrenzung zwischen Standardfunktionen oder eigenen Funktionen.
FuP_S zB sind Funktionen und Prozeduren Standard. Habe auch noch ein FuP der Firma ;)
So am Rande :P
Jakane - Di 29.05.12 11:01
Dank der kleinen Exe von Jänicke hab ichs raus bekommen :)
Mit einer Globalen Variablen kann ich beim Schalter drücken den String übergeben:
Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24:
| function TFuP_S._Abfragefenster(...): String; var ... begin // Varriable initialisieren ... // Formular zusammen bauen ... // Schalter setzen ... FuP_S.ShowModal; Result:= AbfrageErgebnis; end;
procedure TFuP_S.SchalterClick(Sender: TObject); var Schalter : String; begin Schalter:= Copy(TButton(Sender).Name, 4, 2); if Schalter = 'OK' then begin AbfrageErgebnis:= 'Bestätige'; end; end; |
Danke für die Hilfe
Jakane - Do 29.08.13 14:20
Hallo liebe Delphi-Helfer :)
bin mal wieder an meinem eigenen MessageDLG dran und versuch den nun zu optimieren:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34:
| function TFuP.Abfragefenster(Caption, Ausgangswert : String; Schreibart : TSchreibrecht = SRAlles): String; var FForm : TForm; Text : TJEdit;
procedure FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState); begin Case Key of VK_Escape: Text.Text:= ''; VK_Return: FForm.Close; end; end; begin FForm:= TForm.Create(Application); Text:= TJEdit.Create(FForm); Text.Parent:= FForm; Text.JSchreibrecht:= Schreibart; Text.Left:= 10; Text.Height:= 20; Text.Top:= 10; Text.Width:= 170; Text.Text:= Ausgangswert; FForm.Caption:= 'Abfrageformular: ' + Caption; FForm.BorderStyle:= bsSingle; FForm.BorderIcons:= [biSystemMenu]; FForm.Position:= poMainFormCenter; FForm.Height:= 70; FForm.Width:= 200; FForm.OnKeyUp:= FormKeyUp; FForm.ShowModal; Result:= Text.Text; end; |
Bei der Bauweise wollte ich von globalen Variablen weg :-/
Bis auf FForm.OnKeyUp funktioniert auch alles: "Fehlermeldung: Inkompatible Typen: Methodenzeiger und reguläre Prozedur"
Weiss einer wie ich das umschreiben muss, damit das so funktioniert?
Danke für Antworten.
WasWeißDennIch - Do 29.08.13 14:27
In der Deklaration von TFuP:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| type TFuP= class ... private procedure FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState); ... end; |
Und dann als "ganz normale" Methode implementieren:
Delphi-Quelltext
1: 2: 3: 4:
| procedure TFuP.FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState); begin ... end; |
Jakane - Do 29.08.13 14:29
Wenn ich das so mache, kennt er FForm nicht, da diese keine globale mehr sein soll :-/
WasWeißDennIch - Do 29.08.13 14:33
Dann mach doch einfach ein privates Feld draus oder werte den Sender-Parameter aus.
Jakane - Do 29.08.13 14:40
Ich will nicht das die Variablen die ich für den Fensteraufruf brauche die Funktion verlassen.
So wie das Formular definiert ist, ist es für das was ich will richtig.
Nur FormKeyUp macht Probleme.
WasWeißDennIch - Do 29.08.13 14:46
Dann verlege das Form doch in eine eigene Klasse, am besten in einer eigenen Unit.
Jakane - Do 29.08.13 14:50
Danke...
Ich warte mal noch ob vielleicht jemand anderes eine optimalere Lösung weiss.
WasWeißDennIch - Do 29.08.13 15:01
Optimaler als ein bequem in der IDE konfigurierbares Formular, dessen Unit man nur einbinden muss? Ich bin gespannt.
baumina - Do 29.08.13 15:28
Jakane hat folgendes geschrieben : |
Wenn ich das so mache, kennt er FForm nicht, da diese keine globale mehr sein soll :-/ |
Statt
FForm.Close;
TForm(Sender).Close;
das geht nicht?
WasWeißDennIch - Do 29.08.13 15:32
Nützt aber nichts, da auch Text in dem Kontext nicht bekannt ist.
baumina - Do 29.08.13 15:45
Eine Variable "Text" zu nennen, ist eh nicht die allerbeste Idee, aber das nur am Rande erwähnt.
Jakane - Mi 11.09.13 15:40
ist warscheinlich mal wieder was ganz kleines, aber ich krieg immer Zugriffsverletzungen beim "FFenster:= TForm.Create(Application);"
Delphi-Quelltext
1: 2: 3: 4:
| procedure TFHaupt.Button1Click(Sender: TObject); begin JTyps.JFenster.JHinweis('Titel', 'Text' + #10 + 'Text2'); end; |
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70:
| unit JTyps;
interface
uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, Funktionen_und_Prozeduren, StdCtrls, JEdit;
type TJFenster = class(TPersistent) private JEdit01 : TJEdit; FFenster : TForm; procedure FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState); public constructor Create; destructor Destroy; override; published procedure JHinweis(Caption, Nachricht : String; Weite : Integer = 200; Hoehe : Integer = 70); end;
var JFenster : TJFenster;
implementation
constructor TJFenster.Create; begin inherited;
end;
destructor TJFenster.Destroy; begin
inherited; end;
procedure TJFenster.FormKeyUp(Sender: TObject; var Key: Word; Shift: TShiftState); begin Case Key of VK_Escape: JEdit01.Text:= ''; VK_Return: FFenster.Close; end; end;
procedure TJFenster.JHinweis(Caption, Nachricht : String; Weite : Integer = 200; Hoehe : Integer = 70); var cMemo : TMemo; begin FFenster:= TForm.Create(Application); cMemo:= TMemo.Create(FFenster); cMemo.Parent:= FFenster; cMemo.Align:= alClient; cMemo.Lines.Text:= #10 + Nachricht; FFenster.Caption:= 'Hinweis: ' + Caption; FFenster.BorderStyle:= bsSingle; FFenster.BorderIcons:= [biSystemMenu]; FFenster.Position:= poMainFormCenter; FFenster.Height:= Hoehe; FFenster.Width:= Weite; FFenster.OnKeyUp:= FormKeyUp; FFenster.ShowModal; FFenster.Free; FFenster:= nil; end;
end. |
Kann mir jemand erklären wie ich das weg bekomme? Danke :)
WasWeißDennIch - Mi 11.09.13 15:56
Wo wird denn JFenster erzeugt?
Jakane - Mi 11.09.13 16:00
WasWeißDennIch hat folgendes geschrieben : |
Wo wird denn JFenster erzeugt? |
Wenn ich das so mache, bekomme ich den Fehler trotzdem
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7:
| procedure TJFenster.JHinweis(Caption, Nachricht : String; Weite : Integer = 200; Hoehe : Integer = 70); var cMemo : TMemo; begin JFenster := TJFenster.Create; FFenster:= TForm.Create(Application); |
Oder was meinst du?
WasWeißDennIch - Mi 11.09.13 16:11
Du hast eine globale Variable JFenster, auf die Du zugreifst. Bevor Du eine Methode davon aufrufen kannst, muss es ja erst einmal eine Instanz davon geben, daher bringt es nix, diese innerhalb der Methode anlegen zu wollen.
[edit] Schreib doch mal testhalber vor das letzte "end"
Delphi-Quelltext
1: 2: 3: 4: 5:
| initialization JFenster := TJFenster.Create;
finalization JFenster.Free; |
[/edit]
Jakane - Mo 16.09.13 12:17
Es funktioniert und ich habe es verstanden :) danke
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!