Property "Objects" im Stringgrid

[Hansa]

Zitat von Robert_G:

...Sowas hat einfach rein gar nichts in einem Formular zu suchen, das kann man doch sonst nie wiederverwenden, geschweige denn lesen.

Wieso kann man das nicht wieder verwenden ? Natürlich kann man das. OOP ist schwer, ich weiß.

[plautzer]

Morgen,

das alles ist nun leicht verwirrend für mich. Ich will das so einfach wie möglich lösen und wenns geht auf ne elegantere Art und Weise als wie ich das am Anfang hatte.

Ich finde das mit den Objects nicht schlecht, wenn die aber nicht das richtige sein sollten was dann?

Seitweit hat das doch alles funktioniert jetzt gehst halt nur noch ums auslesen, ob editiert oder nicht.

Plautzer

[Hansa]

Dann lasse dich eben nicht verwirren. 8) Wieso soll man so was nicht weiterverwenden können ? Das einzige was verwirrend ist, das ist die Tatsache, daß du plötzlich für ein Grid (also ein Array) ein zweites Array brauchst. Ich brauche für solche Sachen nur noch 3 Prozeduren anzupassen. Das sind ca. 50 Zeilen Code. Die Stringgrid.Objects spielen eine wichtige Rolle. Damit erschlage ich jedes Grid. Trotz unterschiedlicher Spaltenanzahl, unterschiedlicher Datasets, unterschiedlicher Darstellung, unterschiedlicher Zahlenformate usw.

Stop, es sind sogar nur 2 Prozeduren : ErmittleDaten und ZeigeDetailPositionen. Die erste enthält ein teilweise komplexes Select-Statement, um die Daten anzufordern. Die zweite muß ich an das jeweilige Grid anpassen, also was genau in welcher Zelle steht. Und da kommen nun die Stringgrid.Objects ins Spiel. Z.B. halte ich damit fest, ob der Mindestbesatnad unterschritten ist. Ist das der Fall, so werte ich es im OnDrawCell aus und färbe die Zelle, so daß man es sofort sieht. Das betrifft jetzt mehr die Ausgabe.

Bei der Eingabe gibt es folgenden Fall : ich will die Zellen wissen, bei denen etwas gescannt wurde. Sie sollen sich von denen, die von Hand eingegeben wurden unterscheiden. Wurde gescannt, so setze ich das Objects-Feld SCAN auf true. Im OnDrawCell gucke ich dann da nach und schreibe noch klein "scan" in die entsprechende Zelle. Gleichzeitig wird editable (oder wie es bei mir heißt MouseSelect) auf false gesetzt. Im OnSelectCell wird das nun abgefragt. Bei Ergebnis = false, geht es eben nicht. Das dient um bereits eingegebene Werte nicht mehr ändern zu können.

Wer jetzt kommt und sagt, das würde so nicht gehen oder das wäre zu kompliziert, der muß eben noch lernen wie das geht. Kiar und Sharky benutzen die Dinger übrigens auch. Zumindest wurde das gesagt. Sharky hält damit die IDs seiner Daten fest. Und Kiar muß irgendwelche Zellen "halbieren" und die Hälften auch färben. All das läßt sich genial einfach mit diesen Objects realisieren.

Wer sich das nicht mal angesehen hat, der sollte es sich dringend mal anschauen ! Nur über Delphi motzen zählt nicht.

[plautzer]

HI,

das mit dem zweiten Array kapiere ich immernoch nicht ganz

Im Grunde genommen habe ich doch auch bloß zweite Methode um die Daten zu füllen und um sie auszulesen.
Jedoch ist ein für mich wichtig zu wissen wie viele Grids erstellt wurden um später beim speichern eine einwandfreie Schleife zu erstellen. Wie sollte ich das sonst machen?

Ich nehme an du hast in deinem Programm keine Methode um alle veränderten Zelle auszulesen, die machst sie bloß sichtbar. Ich brauche ihre Position um zuwissen was ich speichern muss.

Das wäre dann das:

Delphi-Quellcode:

k:=1;
while k < grd+1 do
  begin
  for i :=grid[k].FixedCols to grid[k].ColCount-1  do
    for j := grid[k].FixedRows to grid[k].RowCount-1  do
       if zelle.editiert = true then
          begin    // wenn die zelle editiert wurde, dann mache was z.b. speichere
          zelle.editiert:=false; 
          showmessage(inttostr(zelle.reihe));
          end;
    k:=k+1;
    enD;

Für mich macht das ganze Sinn. Der ort der Zelle wird perfekt deklariert, und so kann es nicht zu Missverständnissen kommen und keine zelle wird ausgelassen.

Hier ist noch das ganze Problem, es kommt zu fehlermeldung wenn er die schleife das zweite Mal durchläuft.

[Keldorn]

@plautzer

Warum Du jetzt eine while Schleife hast, weiß ich nicht. Es ist aber dasselbe wie For i:=1 to grd do Wenn du schreibst, das du eine Fehlermeldung beim 2. Durchlauf bekommst. Wo setzt du überhaupt Zelle? Und wo genau und welche Fehlermeldung erhälst du?

@Robert G

Zitat von Robert_G:

Objects ist, genau wie Tag, nur eine Art Hilfe für Quick'nDirty-Lösungen. Wenn es mal husch-husch gehen muss.
…
Doch selbst mit wenig Erfahrung in objektorientierter Programmierung solltet ihr in wenigen Stunden eine eigene Grid-Ableitung hinbekommen können.

Das verwirrt mich auch wieder. Die Object-Eigenschaft verwende ich auch oft. Zwar nicht im Stringgrid, mehr bei Listviews und Listboxen. Ok, wenn ich eine Objectlist verwende, leite ich die auch ab und überschreibe die Items-eigenschaft, um mir im eigentlichen Code den Typecast zu sparen und es dort übersichtlicher zu machen. Aber bei den Komponenten lasse ich das immer. Ich erstell mir nur eigene Komponenten, die ich wirklich über mehrere Forms verwende bzw wo ich auch viele Ereignisse verwende.
Wenn ich jedes Mal eine eigene Komponente ableite, sehe ich die Gefahr, das ich mich dann überhaupt nicht mehr in der Komponentenleiste zurechtfinde. Da sind so schon genug Einträge drin. Und nach einem Jahr weiß ich dann auch nicht mehr, für welches Projekt ich welche Komponente benötigt habe und für was die da eigentlich gedacht war. Das nächste ist die Weitergabe eines Projektes, da muß man ja höllisch aufpassen, das man auch ja alle erforderlichen Komponenten mitgibt und muß sie auch noch extra auf dem anderen Rechner installieren. Selbst mit 2 Benutzern auf einem Rechner hat man da schon seine Problemchen. Da laß ich die geänderten Eigenschaften lieber im Code selbst.
Wie organisierst du das?

Mfg Frank

[plautzer]

Die While-schleife ist mir einfach lieber, hast recht es ist das gleich, aber egal.. ändert ja nichts am problem. Die fehlermeldung ist wie häufig ne Zugriffsverletzung und kommt an dieser Stelle:

Delphi-Quellcode:

k:=1;
while k < grd+1 do
  begin
   for i :=grid[k].FixedCols to grid[k].ColCount-1  do  //<--- Fehlermeldung
    for j := grid[k].FixedRows to grid[k].RowCount-1  do
       if zelle.editiert = true then
          begin    // wenn die zelle editiert wurde, dann mache was z.b. speichere
          zelle.editiert:=false;
          showmessage(inttostr(zelle.reihe));
          end;
    k:=k+1;
    enD;

Das objekt 'Zelle' setzt ich bei erstellen und einlesen der Grids:

Delphi-Quellcode:

  k:=0;
  While K < ibDataset2.RecordCount do
  Begin
   grid[grd].RowCount := grid[grd].RowCount +1;
   grid[grd].Cells[1,k+1]:=ibdataset2.fieldbyname('ablese_nr').AsString;
   grid[grd].Cells[2,k+1]:=ibdataset2.fieldbyname('ablesedatum').AsString;
   AddObjectToGrid(1, k+1, ibdataset2.fieldbyname('ablese_nr').AsInteger, grid[grd]);
   AddObjectToGrid(2, k+1, ibdataset2.fieldbyname('ablese_nr').AsInteger, grid[grd]);
   ibdataset2.Next;
   k:=k+1
  end;

Und bei keypress wird Zelle.editiert von auf true gesetzt (false ist defaukt)

[Robert_G]

Zitat von Keldorn:

Wie organisierst du das?

Man kann Delphi mit mehreren Profilen auf einem System verwenden.
Probier's selbst: [WindowsTaste+R] und ...

Code:

delphi32 -rTest

... eintippen.
Jetzt startet Delphi mit den Standardeinstellungen. So hast du eine "eigene" IDE für jedes größere Projekt.
Einfach eine Verknüpfung mit delphi32 -r[Profilname] benutzen.
Außerdem habe ich meine Klassen in Packages gepackt. Somit konnte ich projektbezogene von projektübergreifenden Packages ganz gut unterscheiden.