Post by Joe GalinkeDas ist kein Denglish. Die Property heißt nun einmal DataSource und
kann ja nicht an dieser Stelle anders benannt werden. "Die Proptery
DataSource eines DataSets gibt die Datenquelle....".
Denglish ist fuer mich, wenn jemand mit seltsamen Vokalbeln herumlallt,
etwa "schoppen geht" (hat der eine Ente zum Fuettern?). Und dann, wenn
jemand termini technici eindeutscht. Etwa "Eigenschaft" statt
"property" sagt. Fuer mich ist das nur ein Vokabel zusaetzlich.
Wobei ein Usenet-Beitrag sicher etwas anderes ist, als eine
Hilfefunktion.
Wie ungluecklich die Uebersetzung per se und dann noch mit dem Wort
"Eigenschaft" ist, wird klar, wenn man sich vorstellt, man will nach
dem Wort suchen, nachdem man etwa "property read" gefunden hat.
Post by Joe GalinkePost by Nicole WagnerIch bin mir da nicht so sicher.
Ich verknuepfe in meinem Formular Informationen aus verschiedenen
Tabellen miteinander und schreibe sie dann in eine andere Tabelle
meiner DB zurueck.
Tu Dir und mir einen Gefallen und beachte diese Property vorläufig
nicht. Wenn hier jemand kommt und Dir konkret zeigt wie Du sie für
genau Dein aktuelles Problem einsetzen kannst, von mir aus. Bis dahin
werde ich mich nicht mehr um die Eigenschaft DataSource eines
DataSets kümmern. Ich bin mir zu sicher, dass Du Dich verzetteln
wirst. So viel Zeit und Muße habe ich nicht.
Danke, dass Du Dir die Zeit nimmst, die Du Dir nimmst!
Post by Joe GalinkePost by Nicole WagnerPost by Joe GalinkeDie übliche Verbindung zwischen TDateSource und eine TDataSet (oder
halt einem der Nachfahren)
... dieser Satz hat mich gerade 2 Stunden beschaeftigt.
Ich habe wieder einen mir verstaendlichen Teil in der Hilfe gefunden.
Und einige Links, die nicht ins Leere zeigten, sondern auf Romane.
sieht so aus, dass man der Eigenschaft
Post by Joe GalinkePost by Nicole WagnerPost by Joe GalinkeDataSet der DataSource eben ein TDataSet oder einen Nachkommen
davon >> zuweist.
Post by Nicole WagnerPost by Joe GalinkeDataSource := MyIBQuery; (oder MyDataSet oder MyIBDataSet oder MyIBTable)
Was bedeutet TDataSource?
Ich uebersetze es mit Datenquelle und stelle mir jetzt die Quelle vor,
Hier kommen wir nun wieder zu der anders gelagerten Verbindung. Eine
DataSource der ein DataSet zugewiesen wird.
Ja, die Datenquelle für ein Control wie ein TDbGrid der TDbEdit etc..
Ich habe früher bei dem Begriff Quelle auch eher an die Datenmenge
gedacht, d.h., ich habe mich verwirren lassen.
Stelle Dir es eher wie eine Verbindung oder Datenleitung vor. Du hast
die Datenmenge (TDataSet, TIBQuery, etc) und datensensitive Controls
wie die bereits genannten TDbGrid oder TDbEdit. Die Controls kommen
über die Dataquelle an die Datenmenge heran.
Ich probiere mit den neuen Woertern einmal, ob der Nebel im Kopf sich
lichtet.
Angenommen, ich habe Wasser, das sich in einem Berg sammelt.
Es fliesst aus dem Felsen ueber ein kleines Rohr in ein Becken.
Aus dem Becken kann Wasser geschoepft werden.
Dann waere:
TDataBase: Das Wasser im Berg
TConnection: die Oeffnung im Felsen
TDataSource: das kleine Rohr? Und nicht das Becken?
TDataSet / TIBQuery:
Wasserschoepfen im Primaerbecken inkl. Wasserteilmenge und
Schoepfvorgang
Die Controls sind die Nutzniesser der Einrichtungen?
Und was ist die Gesamtheit des Beckens?
Post by Joe GalinkePost by Nicole WagnerKlar will ich das!
Ich habe es nur bis jetzt nicht implementiert.
Ich wollte das urspruenglich ueber meinen SQL-Werkzeugkasten machen.
Ist das via UpdateSQL probater?
Das kommt darauf an. :-)
Wenn Du direkt in Deiner Datenmenge mit IBQuery.FieldByName().As.. :=
... ändern und dann mit IBQuery.Post arbeiten möchtest, dann wirst Du
UpdateObject brauchen.
Willst Du stattdessen mit irgendeiner anderen IBQuery (SchreibQuery)
und 'UPDATE TABLE Y SET Y=Z WHERE ID=N' (oder so) etwas direkt in die
Tabelle schreiben möchtest, dann geht es ohne UpdateObject. Deine
ursprüngliche IBQuery sieht diese Daten aber erst nach einem Refresh.
Was hälst Du davon, diesen Teil zu verschieben, bis der Rest klappt?
Ja, ich befürchte auch hier die Gefahr des Verzettelns.
ja und nein.
Ich meinem DBGrid-testen komme ich auf viel hundert Klicks pro Tag.
Und neu Starten der Anwendung, weil sich meine DBGrids wieder mal
ungewollt geleert haben. So gehen die Stunden auch dahin.
Ich weiss nur noch immer nicht, was ich "Refresh" muss.
Post by Joe GalinkePost by Nicole WagnerDer Benutzer hat eine Checklistbox. Je nachdem, was er dort
anklickt, wird in verschiedene Tabellen geschrieben. Ich habe das
bis jetzt geloest, indem ich im OnClick-Event *.SQL.Active auf
false gesetzt habe, die *.SQL.text-Zuweisung neu geschrieben und
danach die Query wieder auf true.
Warum hast Du das Statement neu zugewiesen? Oder meinst Du die
Zuweisung verschiedener schreibender Statements für die verschiedenen
Tabellen?
Post by Nicole WagnerIst das de lege artis?
Bei mehreren Tabellen ja.
ja, es sind mehrere Tabelle.
Der Benutzer kann seine Geschaefte verschiedenen Konten zuweisen.
Post by Joe GalinkePost by Nicole WagnerEin ganz schlechtes Gefuehl habe ich dabei, dass ich im Feldeditor
die IBQuery bearbeite, aufgrund der SQL-Formulierung Felder und
Spalten anlege und danach locker vom Hocker SQL.Text zur Laufzeit
neu zuweise. Sowas "macht man nicht". So grundsaetzlich.
Nun, es ist zumindest seltsam. Ich selbst schreibe niemals nie die
Felder in die DataSet-Komponente, d.h., ich lege diese persistenten
Felder nicht zur Designzeit an, nur zur Laufzeit. Enthält die
Datenmenge nämlich irgendwann ein weiteres Feld (egal ob durch
Erweiterung der zugrunde liegenden Tabelle oder durch Erweiterung der
Abfrage), dann darf ich nicht vergessen eben auch den Feldeditor zu
verwenden um jenes Feld hinzuzufügen. Mir fehlt es sonst in der
Datenmenge. Trotzdem kannst Du natürlich so verfahren.
Was spricht dagegen, anstatt die SQL-Statements neu zuzuweisen, für
jeden Zweck eine eigene Komponente zu nehmen? Oder sind es so viele,
evtl. dynamisch erzeugte Statements?
Ich habe Mischformen davon.
Wenn ich etwa nur das Konto austausche, dann sind alle Tabellen gleich
aufgebaut und ich brauche nur einen einzigen Buchstaben aendern.
also etwas so:
procedure sql_Abfrage(Buchstabe: string);
SQL.Text:='select ... from Konto_' + Buchstabe + ';';
Wenn die Aufgabe ganz verschieden ist, dann flog mir die Sache ohnehin
um die Ohren mit dem Feldeditor.
Unter dem Strich habe ich zur Zeit drei eigene Komponenten. Also
ueberschaubar.
Mit denen hakt es aber auf jeden Fall. Ich kann leider nicht mal die
Frage formulieren, wo es hakt. Rufe ich sie einzeln nach Programmstart
auf, dann klappt alles wunderbar. Klicke ich schnell zwischen ihnen hin
und her, dann warte ich bis zu einer Minute. Auch hier denke ich, dass
es etwas mit dem Refresh-Thema haben muss. Eine Pruefung der
OnCalc-Events ergab ein Mitverschulden, doch es kann es nicht alleine
sein.
Post by Joe GalinkePost by Nicole WagnerDoch, sie gehoert zum Formular.
Ich habe das nie so ganz durchschaut, wann ich Form explizit angeben
muss und wann ich es nicht darf.
Das ist wirklich nicht so kompliziert. In einer Methode einer Klasse,
und ein Formular ist ja nur die Instanz einer Klasse, hast Du ein
implizites with Self, wobei Self auf eben diese Klasse verweist.
procedure TMyForm.TuWas;
begin
with Self do begin //das siehst Du nicht, musst es Dir denken
Caption := 'Ein Text'; //Durch das WITH SELF wird die Property
Caption //Deines Formulars angesprochen.
end; //das siehst Du nicht, musst es Dir denken
end;
procedure TMyForm.TuWas(Caption: string);
begin
with Self do begin //das siehst Du nicht, musst es Dir denken
//Mist, Du willst Caption an Caption zuweisen.
//Welches Caption ist denn nun gemeint?
//Durch Self wird nun klar, dass Du links der Zuweisung die
Property //Caption des Formulars meinst. Rechts davon ist es der
Parameter. Self.Caption := Caption;
end; //das siehst Du nicht, musst es Dir denken
end;
Wenn Self auf das Formular zeigt und ich mir das Wort dazudenken
kann,... kann ich dann nicht auch den Formularnamen explizit anweisen?
also:
procedure TMyForm.TuWas;
MyForm.Caption := 'Ein Text';
?
Post by Joe GalinkeSolche Sachen können besonders gut auftreten wenn Du selbst mit with
arbeitest.
with MyObject do begin
Caption := //hier ist nun Caption des Objekts gemeint, auch wenn
sich //sich dieser Code in der Methode eines Formulars
befindet. end;
Marian sagte
"with verheisst Unheil".
Da sich diese Prophezeiung bewahrheitet hat (man hat ja auch bei
Var-Namen seine Lieblingsausdruecke und Gleichheiten bringen VIEL
Unheil) vermeide ich with, solange ich die Zeile noch irgendwie
handlich tippen kann.
With habe ich nur noch bei Owner-Draw Teilen, wo man den Codeteil
bequem unter jedes "With Formularnamen" kopieren kann.
Post by Joe GalinkeDu siehst, dass ich nirgends meine Formularvariable verwendet habe?
Das tue ich auch niemals. NIEMALS.
interessant
Post by Joe GalinkeSehr viele Formulare benötigen gar
keine Variable, da niemand von außen darauf zugreift. Auf jeden Fall
hat die Variable für ein Objekt nichts im Code der Klasse dieses
Objekts zu suchen.
ui, das habe ich nicht vestanden.
Was ist "die Variable fuer ein Objekt"?
Post by Joe GalinkePost by Nicole WagnerIn 90 Prozent aller Faelle, wenn vom Compiler eine Syntax ohne Form
akzeptiert wurde, hatte ich in Wahrheit einen Pointer nach nil, der
zur Laufzeit eine Schutzverletzung ausloeste.
Hast Du mal passende Beispiele, gerne auch in Form eines überschau-
und übersetzbaren Projekts (siehe Emailadresse, bitte nicht alles hier
reinposten), dann wird man anhand diese Codes sicherlich so manches
erklären können.
es wird mir sicher wieder unterkommen.
Ich hatte es damals an der mir heute nicht mehr gelaeufigen Stelle
sogar kommentiert, dass ich die E gesehen hatte aus diesem Grund.
Post by Joe GalinkePost by Nicole WagnerDas passierte etwa haeufig in Zusammenhang mit TChart. Ich habe mir
daher angewoehnt, im Zweifel Form explizit hinzuschreiben. Zudem ich
mit meine hunderte Variablennamen nicht merken kann und die
Programmierhilfe quasi verwenden muss.
Ok, da habe ich nur die mitgelieferte Version.
Probiere einmal Pro.
Ich bin von der schlichtweg begeistert.
Sie hat nur eine Nag-Screen als Demo und ist uneingeschraenkt
funktionsfaehig.
Post by Joe GalinkePost by Nicole WagnerDoch Methoden, die nicht zum Formular gehoeren: Wie loest man das?
Legt man dafuer eine eigene Klasse an?
Wenn es nur eine kleine Hilfsfunktion ist, kommt sie einfach in die
Firmularunit. Spo benötigt man als Fallback-Funktion für
Sortieraufgaben eine einfache Funktion und eben keine Methode.
huch?
Ich habe mein Leben lang gedacht, Methode waere der Oberbegriff von
Funktionen und Prozeduren?
Post by Joe GalinkeSchlichte Funktionen bleiben bei mir auch meist einfache Funktionen,
werden halt in einer Unit ausgelagert.
Post by Nicole WagnerWenn ja, wie bezeichnet man die
Klasse am besten, damit man die Methode wiederfindet?
Das ist ein ganz anderes Thema. Ich kann nur sagen, dass man sich
durchaus Zeit zur Namensfindung nehmen sollte. Eben um solche
Unterstrichsuffixe wie Du sie gerne verwendest zu vermeiden.
Aber ich werde nur sehr langsam schlau und nehme mir auch heute noch
zu selten genug Zeit dafür. Oder ich bin einfach zu phantasielos.
Ich habe mir Bibliotheken angelegt.
Etwa eine namens Zeit.
Dort sammelt sich im Laufe der Jahre der Schrott.
Wie ich vor 5 Jahren ein Datum formatiert habe, das mache ich heute
nicht mehr. Ebenso wie ich verschiedene Formatumwandlungen nicht mehr
brauchem weil ich das Format wahrscheinlich(!) nicht mehr verwende.
Wenn ich aber etwas loesche, ist es notorisch jenes, das ich noch
gebraucht haette.
Keine Unterstrichsuffixe?
Ohne die bin ich verloren. Ich kann nur mit Woertern.
Ich ueberlege zur Zeit, ob ich Unix nicht links liegen lasse mit all
den Kuerzeln.
Post by Joe GalinkePost by Nicole WagnerBitte frage mich jetzt nicht wie, merken kann ich mir das nicht. Ich
weiss nur, dass ich manche lokale Vars nur deshalb fuehre, weil ich
mit den Zuweisungsmonstern nicht arbeiten kann.
Das ist oft auch besser, als zur Vermeidung fröhlich mit WITH zu
arbeiten, vielleicht sogar noch geschachtelten WITHs. Nicht, dass ich
sie gar nicht verwende, aber eher sparsam udn ganz bestimmt nicht
über vile Zeilen. Wenn ich Anfang und Ende des Blockes nicht mehr
gleichzeitig sehen kann, dann ist sowas auf jeden Fall zu vermeiden.
ich vermeide es auch, wo geht.
Doch je laenger ein Block, desto mehr erspart das with
Zu Blockanfang und Ende habe ich einen Trick:
D 2010 hat recht gute Autofunktionen:
Schreibe ich ein begin und die Eingabetaste, dann schreibt mir Delphi
ein end; genau drunter.
D.h. ich habe meine begin-end-Block formatiert, bevor ich die erste
Zeile schreibe. Und bevor ich die Zeile schreibe, kopiere ich die
Befehlszeile als Kommentar hinter das end.
Also for i:=0 to 100 do
begin
end; // zu for i:=0 to 100
Dann erst beginne ich meinen Code zu tippen.
Natuerlich nur fuer laengere und ineinandergeschachtelte Schleifen.
Etwa fuer Boolean-bedingte while-Schleifen, die ineinanderzahnen, ist
mir das nach einiger Zeit eine Arbeitsersparnis beim Wiederbearbeiten,
zu sehen, welches end welche Schleife begrenzt.
Post by Joe GalinkeEigentlich schon früher. Dann sind kurze Variablennamen sehr
hilfreich. Geschachtelte WITHs kommen mir nicht in meinen Code, die
schafft mein Hirn nicht ausreichend gut.
und das Ueberwachungsfenster im Compiler noch weniger
Leider habe ich geschachtelte withs als Fremdcode. Grauslich ist das,
mit denen zu arbeiten.
Post by Joe GalinkeWo ich gerne WITH verwende ist bei manchen modalen Dialogen.
fcuntion TMyForm.GetDialogValue: TModalResult;
begin
with TMyDialogForm.Create(Application) do begin
try
Result := ShowModal;
finally
Free; //Das Free des erzeugten Formulars
end;
end;
end;
Dieses TMyDialogForm kommt ganz sicher ohne jegliche Formularvariable
aus, die automatisch erzeugte wird sowieso, wenn ich es nicht
vergesse, gleich beseitigt.
Was ist denn DAS?
Das sieht viel griffiger aus als meine Dialoge mit der Message Box.
* kopier *
Abgesehen davon, dass ich modale Dialoge vermeide. Zu oft kam ich an
ein Fenster nicht mehr ran und musste das Programm abschiessen. Nicht
in einenen Anwendungen. Ich vermeide modal ja wo geht, ;-)
Post by Joe GalinkePost by Nicole WagnerMeine augenblickliche Idee waere, in Zukunft stets "IBQuery." zu
verwenden, weil es das kuerzeste ist.
Warum gibst Du dem Kind nicht gleich einen passenden Namen? Ebenso
hoffe ich, dass IBTransaction1 nur der Name aus einem Testcode ist.
Meine Queries heissen alle so, wie ihre DBGrid-PageContolTab-Eltern.
Meine Transaction hingegen heisst wirklich nur 1.
Diese Transaction1 ist in irgendeinem Zusammenhang als "default"
gelistet (weiss nicht mehr wo, im OI?). Sobald ich eine andere
Transaction verwenden wollte, fand ich den Eintrag nicht mehr in der
DB. Bzw. sprang dieser default-Eintrag im OI hin und her und es
passierten seltsame Dinge.
Ich ging dann den Weg des geringsten Widerstandes und verwendete stets
nur die eine Transaction1, die funktionierte.
Liebe Gruesse,
Nicole