TObjectList sehr anfällig?

[EWeiss]

Versuche die TObjectList anstelle von Collection(VB) zu verwedenden.

Beim start der Anwendung wird ein Button erstellt der aber nicht in die TObjectList aufgenommen wird.
Das ergebis ist dann ListIndex überschreitet das Maximum(1)

Lasse ich den ersten Button weg und fange bei 0 an kommt die Meldung ListIndex überschreitet das Maximum(0)
Langsam bekomme ich einen Anfall und frage mich ob es nicht besser wäre einfach ein normales Array zu verwenden.
Ich dachte das es sinnvoll wäre da die Button während der Laufzeit auch wieder entfernt
bzw.. ReOrganisiert werden müssen.

FColButtons: TObjectList;

Delphi-Quellcode:

function TClsProgBar.Button(Btn: Integer): TClsButtonInfo;
var
  FSelButton: TObject;
begin
  FSelButton := nil;
  try
    try
      // auch ein FColButtons.Items[Btn- 1]) führt zu einem EListError
      FSelButton := (FColButtons.Items[Btn]) as TClsButtonInfo;
    except
      //
    end;
  finally
     Result := TClsButtonInfo(FSelButton);
  end;

end;

Delphi-Quellcode:

function TClsProgBar.ReOrgDisplay(Ctrl: TClsControls; oInit: Bool): Bool;
var
  Width: Integer;
  Height: Integer;
  Btn: Integer;
  oButton: TClsButtonInfo;

begin

  NewNumButtons := ButtonWidth * ButtonHeight;
  oButton := nil;

  // Lösche nicht benötigte Controls
  if NewNumButtons < FNumButtons then
  begin
     // lösche nichtverwendete Tasten, ausgenommen die erste
     for Btn := NewNumButtons + 1 to FNumButtons do
       Ctrl.RemoveButton(Btn);
  end;

  // lösche nichtverwendete einträge in der TObjectList
  if NewNumButtons < FColButtons.Count then
    // Lösche nicht benötigte Tasten, ausgenommen die erste
    for Btn := NewNumButtons + 1 to FNumButtons do
      RemoveButton(Btn);

  // erstelle neue Tasten wenn vorhanden
  Btn := 0;
  for Height := 1 to ButtonHeight do
  begin
    for Width := 1 to ButtonWidth do
    begin
      inc(Btn);
      if Btn > FNumButtons then
        Ctrl.AddButton(frmButtonHandle, Btn);

      Ctrl.PositionButton(Btn, Width, Height);

      if Btn > FColButtons.Count then
      begin
        try
          oButton := TClsButtonInfo.Create(nil);
          oButton.Num := Btn;
          AddButton(oButton);
        finally
          oButton := nil;
        end;
      end;
    end; // Width
  end; // Height

  // ButtonForm adjustieren
  Ctrl.Adjust(ButtonWidth, ButtonHeight);

  if oInit then
  begin
    // lösche die  1. Taste
    oButton := Button(1);
    if Assigned(oButton) then
    begin
      try
        oButton.BmpFile := '';
        oButton.ButtonKey := '';
        oButton.ToolTip := '';
        oButton.ButtonCmd := '';
      finally
        oButton := nil;
      end;
    end;
    // ProgBar-Properties zurücksetzen
    ClassNamen := '';
    ProgPath := '';
    ArbVerz := '';
    ProgTitle := '';
    ProgToolTips := '';
    ProgTrayMenu := '';
    Name := '';

    FNumButtons := 1;
  end else
  FNumButtons := NewNumButtons;

  if Assigned(SelButton) then
    SelButton.Free;

  result := True;
end;

Bedingt durch den Fehler fehlen mir immer irgendwelche Button
hier zum beispiel 2 .. sollten 8 sichtbar sein.

gruss

[Sir Rufo]

Also eine TObjectList ist genauso anfällig wie ein Array, vor allem weil eine TObjectList ein gekapseltes Array ist. Und ein Griff neben die Kiste ( Index < 0 or Index >= Count ) würde auch bei einem Array Probleme geben.

Allerdings findet es eine TObjectList doof, wenn man eine Instanz in der Liste aus dem Speicher wirft, solange diese noch in selbiger verweilt.

Aus deinem Code entnehme ich, dass du da die Buttons entfernst und erst dann die Liste bereinigst. Diese Organisation sehe ich als den kritischen Teil an. Denn in der TObjectList sind ja die Verweise auf die Instanzen noch enthalten und wenn OwnsObjects auf true, dann versucht die TObjectList beim Entfernen aus der Liste ein Free auf diese (vermeintlich noch existierende) Instanz.

Evtl. ist da die Verantwortlichkeit (wer macht was wann) im Code nicht klar geregelt. Aber zur Beurteilung fehlt da der CodeTeil, der für den Eintrag und das Entfernen der Buttons.

[EWeiss]

Zitat:

Aus deinem Code entnehme ich, dass du da die Buttons entfernst und erst dann die Liste bereinigst.

Das sehe ich nicht so zumindest nicht beim ersten start und da kracht es ja schon.
Denn..

Delphi-Quellcode:

NewNumButtons := ButtonWidth * ButtonHeight;

"ButtonWidth * ButtonHeight" = 1 * 1

Da NewNumButtons in dem Fall 1 ist, also nicht weniger wie FColButtons.Count wird hier auch nichts gelöscht.

Nachher mag das zutreffend sein dafür muss ich einfach nur die beiden abfragen vertauschen.
Obwohl Ctrl.RemoveButton(Btn) nichts mit RemoveButton(Btn) zu tun hat.

Zitat:

der für den Eintrag und das Entfernen der Buttons.

Das dürften die fehlenden Funktionen sein.

Delphi-Quellcode:

function TClsProgBar.AddButton(var oButton: TClsButtonInfo): Bool;
begin
  if ButtonExists(oButton.Num) then
    RemoveButton(oButton.Num);

  FColButtons.Add(oButton);
  FColButtons.Insert(oButton.Num, oButton);

  Result := True;

end;

Delphi-Quellcode:

function TClsProgBar.ButtonExists(Btn: Integer): Bool;
begin
  FOButton := Button(Btn);
  Result := Assigned(FOButton);

end;

Beim ersten start kracht es schon (also EListError)
Notfalls kann ich den Source mal hochladen.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1179906)

FColButtons.Add(oButton);
FColButtons.Insert(oButton.Num, oButton);

Ich vermute mal, daß FColButtons die TObjectList ist. Dann wird mit

Delphi-Quellcode:

FColButtons.Add(oButton);

der Button an die Liste angehängt und mit

Delphi-Quellcode:

FColButtons.Insert(oButton.Num, oButton);

nochmal an der Stelle oButton.Num eingefügt. Er befindet sich jetzt also zweimal in der Liste. Das bringt zumindest die Bedeutung von FColButtons.Count durcheinander.

[Sir Rufo]

Das ButtonExists würde ich umschreiben oder das Button( Btn : Integer ).

Delphi-Quellcode:

function TClsProgBar.ButtonExists( Btn : Integer ) : Bool;
begin
  Result := ( Btn >= 0 ) and ( Btn < FButtonList.Count );
end;

Die genaue Codierung hängt allerdings davon ab, ob du 0 basierend indizierst (so wie die Liste) oder 1 basierend.

[EWeiss]

Zitat:

Zitat von Sir Rufo (Beitrag 1179911)

Das ButtonExists würde ich umschreiben oder das Button( Btn : Integer ).

Delphi-Quellcode:

function TClsProgBar.ButtonExists( Btn : Integer ) : Bool;
begin
  Result := ( Btn >= 0 ) and ( Btn < FButtonList.Count );
end;

Die genaue Codierung hängt allerdings davon ab, ob du 0 basierend indizierst (so wie die Liste) oder 1 basierend.

Danke euch werde die Infos mal durchgehen und sehen ob ich dann auf einen nenner komme.

gruss

[EWeiss]

Das umschreiben der ButtonExists sorgt zumindest dafür das es zu keinen ElistError mehr kommt.

Wenn ich hingegen irgendeine Zeile von AddButton entferne dann kracht es wieder.

Delphi-Quellcode:

function TClsProgBar.AddButton(var oButton: TClsButtonInfo): Bool;
begin
  if ButtonExists(oButton.Num) then
    RemoveButton(oButton.Num);

  FColButtons.Add(oButton); // kann nicht entfernt werden
  FColButtons.Insert(oButton.Num, oButton); // Das auch nicht

  Result := True;

end;

Wirklich kompiliziert die Collection von VB nach Delphi zu portieren.
Hier sind mal die VB Teile dazu..
mcolButtons = Collection und in Delphi halt die TObjectList.

Code:

Public Function AddButton(ByRef roButton As clsButtonInfo) As Boolean

    If ButtonExists(roButton.Num) Then RemoveButton roButton.Num

    mcolButtons.Add roButton, CStr(roButton.Num)

End Function

Code:

Public Property Get Button(ByVal vlBtn As Long) As clsButtonInfo

    On Error Resume Next

        Set moSelButton = mcolButtons.Item(CStr(vlBtn))

        Set Button = moSelButton
        Err.Clear

End Property

Code:

Private Function ButtonExists(ByVal vlBtn As Long) As Boolean

Dim oButton As clsButtonInfo

    Set oButton = Button(vlBtn)
    ButtonExists = CBool(Not oButton Is Nothing)

End Function

Nur das ihr den Unterschied sehen könnt.
Sorry habe mich noch nie mit der ObjectList beschäftigt.

Nebenbei:
Es geht hier nicht um Copy/Paste
Es ist ein Programm das ich 1999 in VB geschrieben habe was da auf der VB seite abgeht weiss ich und stellt kein problem dar.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1179917)

Wenn ich hingegen irgendeine Zeile von AddButton entferne dann kracht es wieder.

Delphi-Quellcode:

function TClsProgBar.AddButton(var oButton: TClsButtonInfo): Bool;
begin
  if ButtonExists(oButton.Num) then
    RemoveButton(oButton.Num);

  FColButtons.Add(oButton); // kann nicht entfernt werden
  FColButtons.Insert(oButton.Num, oButton); // Das auch nicht

  Result := True;

end;

Dann solltest du herausfinden, warum es dann kracht, denn die beiden Zeilen machen zweimal das fast gleiche. Beim Add wird der Button an die TObjectList angehängt und beim Insert nochmal an der übergebenen Stelle eingefügt. Nach dem ersten Aufruf von AddButton enthält die TObjectList somit zwei Elemente (Buttons), wobei es sich aber um dieselbe Instanz eines Buttons handelt. Leider konnte ich nocht nicht erkennen, ob die TObjectList mit OwnsValues kreiert wurde. Dann gibt es nämlich spätestens beim Entfernen der Buttons ganz massive Probleme. Außerdem gibt TObjectList.Count die Anzahl der Elemente zurück, die immer das doppelte der Anzahl der Buttons entspricht.

Der Code mit Add und Insert ist in jedem Fall falsch.

Gib doch bitte mal den kompletten Code mitsamt ButtonExists uhnd RemoveButton, damit man mal den Überblick bekommt.

[EWeiss]

Zitat:

Gib doch bitte mal den kompletten Code mitsamt ButtonExists uhnd RemoveButton, damit man mal den Überblick bekommt.

Dann wäre es einfacher den Quelltext anzuhängen.
Da hier zu viele dinge zugehörig sind.

Ich habe ihn so klein wie möglich gehalten zwei Skins müssen sein zum gegenprüfen.
Die aktuell relevanten teile befinden sich in uProgBar
Das ist eine Common Classe die später auch für ProgStart verwendet wird.

gruss

[Uwe Raabe]

Ein paar Dinge gleich nach dem ersten Duchsehen:

1. Der Index in TObjectList ist 0-basiert, TClsButtonInfo.Num fängt aber bei 1 an.
2. Das Löchen von Elementen aus einer Liste funktioniert nur dann richtig, wenn man
   Delphi-Quellcode:

   for I:=<ende> downto <start> do

   verwendet.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1179937)

1. Das Löchen von Elementen aus einer Liste funktioniert nur dann richtig, wenn man
   Delphi-Quellcode:

   for I:=<ende> downto <start> do

   verwendet.

Oder von <start> bis <ende> und dabei immer nur auf den kleinsten Index zugreift.

Tja, die Collection in Delphi registriert sich bei ihren enthaltenen TComponents und auch andersrum.
Sobald einer er Beteiligten freigegeben wird, wird die aufgebaute Verknüpfung aufgelöst und die Komponenten aus der Liste ausgetragen.

Siehe meine Firemonkey-Hints. Da hab ich dieses auch endlich selber mal verwendet. Dort speichere ich mir ja in Variablen Zeiger auf die beteiligten Objekte. Um diese Variablen "sauber" zu halten und keine "tote" Verlinktungen zu erhalten, hab ich meine Ojekte ebenfalls entsprechend registriert und räume bei Benachrichtigung dann entsprechend meine Variablen auf.


Wer es nicht schafft seine Verlinkungen sauberzuhalten und eindeutige Besitzverhältnisse sichzustellen (nur Einer darf etwas freigeben ... halt das Highlander-Prinzip "Es kann nur Einen geben") oder es so zu regeln, daß sich alle beteiligten Verantwortlichen untereinander informieren, der sollte besser auf Interfaces umsteigen oder auf andere Managed-Systeme.

[mkinzler]

Zitat:

Oder von <start> bis <ende> und dabei immer nur auf den kleinsten Index zugreift.

Geht aber auch nur bei bedingungslosem Löschen

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1179944)

Zitat:

Oder von <start> bis <ende> und dabei immer nur auf den kleinsten Index zugreift.

Geht aber auch nur bei bedingungslosem Löschen

Gut, man kann den Index ja auch hochzählen, entsprechend der Bedingung. :angle2:

Nja, rückwärtslöschen ist einfacher, aber manchmal kommt es auf die Reihenfolge drauf an, wierum gelöscht wird.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1179937)

Ein paar Dinge gleich nach dem ersten Duchsehen:

1. Der Index in TObjectList ist 0-basiert, TClsButtonInfo.Num fängt aber bei 1 an.
2. Das Löchen von Elementen aus einer Liste funktioniert nur dann richtig, wenn man
   Delphi-Quellcode:

   for I:=<ende> downto <start> do

   verwendet.

Ja ich weiss deshalb sagte ich auch in einem der Beiträge das ich den ersten Button nicht in die ObjectList eingetragen habe.
Es scheint so das die ObjectListe damit nicht klar kommt wenn du sagst das ich unbedingt mit 0 anfangen muss.

Es dürfte klar sein das wenn man Button zu einem Fenster zur Laufzeit addiert dann muss zumindest 1 vorhanden sein der auch nicht gelöscht werden darf.
Dieser repräsentiert den Index 0;

Ich habe versucht bei 0 anzufangen in dem ich einfach

Delphi-Quellcode:

FSelButton := (FColButtons.Items[Btn -1]) as TClsButtonInfo;

Btn -1 zugewiesen habe..

Aber auch das habe ich schon angemerkt dann meldet er mir das der ListIndex Maximum(0) überschritten wäre.
Fange ich bei eins an meckert er das ListIndex Maximum(1) überschritten ist.

Da hab ich noch was zu tun ;)

Zitat:

1.Das Löchen von Elementen aus einer Liste funktioniert nur dann richtig, wenn man for I:=<ende> downto <start> do verwendet.

Müßte ich dann noch ändern.
In der Collection VB seite spielte das keine rolle.

Danke für die überprüfung.

gruss

[EWeiss]

Das addieren geht jetzt grundsätzlich schon mal
Muss jetzt nur noch das problem mit dem entfernen Korrigieren.

Hab da mit der Liste noch nicht den richtigen ansatz gefunden.
Habe da mal temporär die Indexes der Button als Caption addiert.

gruss

[Sir Rufo]

Wäre es nicht näher dran, wenn du statt TObjectList eine eigene TCollection nehmen würdest?

[EWeiss]

Zitat:

Zitat von Sir Rufo (Beitrag 1179955)

Wäre es nicht näher dran, wenn du statt TObjectList eine eigene TCollection nehmen würdest?

Eigentlch schon kam da aber nicht mit klar.

Beispiel:
Bei Add.
Da kann man ja nicht groß was übergeben.

TObjectList

Delphi-Quellcode:

  FColButtons.Add(oButton);
  FColButtons.Insert(oButton.Num, oButton);

TCollection:

Delphi-Quellcode:

function Add:

Wie soll ich hier die Classe TClsButtonInfo übergeben?

Die ObjektList kam der Collection von VB am nächsten.

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1179957)

Zitat:

Zitat von Sir Rufo (Beitrag 1179955)

Wäre es nicht näher dran, wenn du statt TObjectList eine eigene TCollection nehmen würdest?

Eigentlch schon kam da aber nicht mit klar.

Beispiel:
Bei Add.
Da kann man ja nicht groß was übergeben.

Eine Collection enthält immer nur Einträge, die von CollectionItem abgeleitet sind. Solange dies nicht für TClsButtonInfo zutrifft (aktuell tut es das nicht), ist eine Collection eher eine zusätzliche Zwischenstufe. Wenn du nicht auf eine generische Liste oder gar auf Dictionary umsteigen willst, ist TObjectList auch ganz OK.

Vieles an deinem Code ist offensichtlich aus dem VB Programm übernommen - insofern würde man viele Dinge heute in Delphi von vornherein anders machen. Die implizite Verbindung von TClsButtonInfo.Num zum Index in FColButtons (ob nun -1 oder nicht) bringt m.E. einen überflüssigen Overhead in die Implementation. Ich vermute dort die meisten Macken.

[EWeiss]

Zitat:

Vieles an deinem Code ist offensichtlich aus dem VB Programm übernommen

Ja ich wollte nicht das komplette Projekt neu erfinden. ;)
Denke auch wenn ich das heute direkt in Delphi also neu schreiben würde sähe es auch etwas anders aus.
Das wäre mir aber dann doch zuviel des guten zumal da ich es schon einmal geschrieben habe.

Zitat:

dem VB Programm übernommen

aus meinem VB Programm. ;)

Das mit dem addieren funktioniert jetzt ohne Probleme wie am am Shot erkennen kann.
Das entfernen werde ich dann auch noch schaffen.

Der vorteil an der ProgBar Klasse ist halt das ich die nur einmal erstellen muss
diese wird ja dann von zwei Unterschiedlichen Programmen verwendet.
Genauso wie die Klasse ButtonInfo da hab ich mir schon einiges an Arbeit gespart.

Das hier ist ja nur das Konfigurations Programm für die Button
Das eigentliche Programm ProgStart startet dann die Programme für die von ProgBar erstellten ToolBars.
Der sinn und zweck des programms war Hauptsächlich den Desktop sauber zu halten und Programme zu steuern die früher
keine eigene ToolBars enthielten so wie NotePad.

Aber grundsätzlich ist es schon richtig das man so ein Projekt eigentlich komplett neu aufsetzen sollte.
Aber wie schon gesagt zu viel des guten.

gruss

[EWeiss]

oops .. vergessen zu Antworten

Zitat:

Tja, die Collection in Delphi registriert sich bei ihren enthaltenen TComponents und auch andersrum.
Sobald einer er Beteiligten freigegeben wird, wird die aufgebaute Verknüpfung aufgelöst und die Komponenten aus der Liste ausgetragen.

Soweit man TComponente verwendet.

Zitat:

Wer es nicht schafft seine Verlinkungen sauberzuhalten und eindeutige Besitzverhältnisse sichzustellen (nur Einer darf etwas freigeben ... halt das Highlander-Prinzip "Es kann nur Einen geben") oder es so zu regeln, daß sich alle beteiligten Verantwortlichen untereinander informieren, der sollte besser auf Interfaces umsteigen oder auf andere Managed-Systeme.

Gebe ich dir im grunde recht. (Siehe Interface meiner LIB)
Aber es geht um Nonvcl da zählen einige deiner guten Ratschläge leider nicht.
Ansonsten würde ich sie verwenden.. kannst mir glauben ;)

gruss

[Medium]

Zitat:

Zitat von EWeiss (Beitrag 1180039)

Aber es geht um Nonvcl da zählen einige deiner guten Ratschläge leider nicht.

Klare Besitzverhältnisse haben imho nun garnix mit der VCL zu tun. Eher damit, ob man sich selber den Gefallen tun möchte oder lieber im eigenen Kauderwelsch suhlt ;)

[Blup]

Scheinbar hat hier oButton.Num nichts mit dem Index in der TObjectlist zu tun.
Ursache kann z.B. sein, das die Buttons nicht vollständig, doppelt oder nicht in der richtigen Reihenfolge eingefügt oder nach dem Einfügen nicht sortiert werden. Also sollte man den Index unberücksichtigt lassen, statt dessen nach dem richtigen Button suchen:

Delphi-Quellcode:

type
  TMyColButtons = class(TObjectList)
  private
    function GetButton(ANum: Integer): TClsButtonInfo;
  public
    procedure Add(AButton: TClsButtonInfo);
    procedure Remove(ANum: Integer);
    property Button[ANum: Integer]: TClsButtonInfo read GetButton; default;
  end;

function TMyColButtons.GetButton(ANum: Integer): TClsButtonInfo;
var
  i: Integer;
begin
  for i := 0 to Count - 1 do
  begin
    Result := TClsButtonInfo(Items[i]);
    if Result.Num = ANum then
      Exit;
  end;
  Result := nil;
end;

procedure TMyColButtons.Add(AButton: TClsButtonInfo);
begin
  Remove(AButton.Num);
  inherited Add(AButton);
end;

procedure TMyColButtons.Remove(ANum: Integer);
var
  oButton: TClsButtonInfo;
begin
  oButton := Button[ANum];
  if Assigned(oButton) then
    inherited Remove(oButton);
end;

Wichtig ist:
Wenn ein Button gelöscht werden soll, muss er aus der Liste entfernt werden, bevor er freigegeben wird.

[EWeiss]

Ahh hab diesbezüglich auch schon Fehler gefunden.
Beim klick auf einen Button werden mir nur ungerade Button korrekt zurückgeliefert.

Vielleicht behebt dein Code das problem direkt mit.

Werde es mal testen.

PS:
Ja leider geht nicht alles da VBCollection doch anderes gehandhabt werden.

Danke.

gruss

[EWeiss]

Hab mir deinen Code nochmal durchgesehen er hilft mir leider nicht weiter
Trotzdem nochmal Danke.

Zitat:

Wenn ein Button gelöscht werden soll, muss er aus der Liste entfernt werden, bevor er freigegeben wird.

Im moment ist mir noch nicht ersichtlich was eigentlich alles in die ObjectList gespeichert wird.
Die gesamten eigenschaften der Classen oder nur der Index des aktuell addierten Button.


gruss

[DeddyH]

In einer TObjectList werden die Instanzen abgelegt, Du hast also vollen Zugriff auf alle Eigenschaften und Methoden der jeweiligen Instanz. Wenn es sich nicht um eine spezialisierte Ableitung bzw. eine generische TObjectList handelt, musst Du diese aber vorher noch auf den entsprechenden Typen casten.

[EWeiss]

Zitat:

Zitat von DeddyH (Beitrag 1180068)

In einer TObjectList werden die Instanzen abgelegt, Du hast also vollen Zugriff auf alle Eigenschaften und Methoden der jeweiligen Instanz. Wenn es sich nicht um eine spezialisierte Ableitung bzw. eine generische TObjectList handelt, musst Du diese aber vorher noch auf den entsprechenden Typen casten.

Wenn ich dich also richtig verstehe sollten alle eigenschaften des aktuellen button(Instanz)

oButton.Num
oButton.BmpFile
oButton.ButtonKey
oButton.ToolTip
oButton.ButtonCmd

beispiel für button 1 im feld 0 gespeichert sein?
Also der Counter macht mir ärger.
Der dritte button wird einfach nicht addiert in die ObjectList

Delphi-Quellcode:

      if Btn > FColButtons.Count - 1 then
      begin
        try
          oButton := TClsButtonInfo.Create(nil);
          oButton.Num := Btn;
          AddButton(oButton);
        finally
          oButton := nil;
        end;
      end;

Die ersten beiden werden ordnungsgemäß addiert
aber beim dritten ist der Count immer noch 2 obwohl er eigentlich 3 sein müßte.
Die probleme nehmen einfach kein ende mit der Liste ;)

Sternchen für OK!
1*, 2* 3, 4*, 5, 6*, 7, 8*

Was ist mit den anderen die werden einfach nicht addiert.
Der FColButtons.Count erhöht sich nicht nach dem addieren des 2,4,6 usw..

gruss

[Medium]

Wofür braucht du überhaupt die Property "Num"? Die erscheint mir eher redundant, und gerade wenn sie mit dem Index in der Liste immer übereinstimmen muss, auch aufwändig zu pflegen (Man müsste nach jedem Insert in die Liste ggf. alle Buttons anpassen).
Soweit ich deinen (zugegebenermaßen recht eigentümlichen) Code verstehe, willst du doch nicht mehr, als einfach alle Buttons in eine ungeordnete Sammlug werfen. Dann kannst du die doch einfach in die Liste Adden, der Index (also "Num") ergibt sich dann ohnehin nachher implizit über seine Position in der Liste. Warum das gehuddel?

Eine Liste speichert ansonten immer auch nur Referenzen auf Objekte.

Delphi-Quellcode:

var
  myInstance: TMyClass;
  aList: TObjectList;
begin
  aList := TObjectList.Create;
  myInstance := TMyClass.Create;
  aList.Add(myInstance);
  // Folgende Zugriffe sind dann vollständig identisch:
  myInstance.SomeProperty := 'Foo';
  TMyClass(aList[0]).SomeProperty := 'Foo';
end;

[DeddyH]

Darf ich mal ganz doof fragen, was Btn eigentlich ist bzw. welchen Zweck sie erfüllen soll?

[EWeiss]

Zitat:

Zitat von DeddyH (Beitrag 1180086)

Darf ich mal ganz doof fragen, was Btn eigentlich ist bzw. welchen Zweck sie erfüllen soll?

Btn steht für Button..
Und ist der index des aktuellen Button.

gruss

[DeddyH]

Also wenn das eine Instanz ist, könntest Du mit IndexOf(Btn) den Index erfragen.

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1180103)

Also wenn das eine Instanz ist, könntest Du mit IndexOf(Btn) den Index erfragen.

Btn ist ein Integer und korrespondiert mit TClsButtonInfo.Num - das Problem ist, daß dieser Wert nicht mit dem Index in der TObjectLIst zusammenpasst. Der Wert wird aber an anderer Stelle (INI-Datei, Globale InterfaceListe) so gebraucht.

Anstatt mich weiter durch dieses Durcheinander zu hangeln, hätte ich das schon längst neu gemacht.

[EWeiss]

Zitat:

Btn ist ein Integer und korrespondiert mit TClsButtonInfo.Num - das Problem ist, daß dieser Wert nicht mit dem Index in der TObjectLIst zusammenpasst. Der Wert wird aber an anderer Stelle (INI-Datei, Globale InterfaceListe) so gebraucht.

Richtig deshalb brauche ich auch das "NUM" da es übergreifen verwendet wird.

Zitat:

Anstatt mich weiter durch dieses Durcheinander zu hangeln, hätte ich das schon längst neu gemacht.

Du hast ja so recht.

Wenn ich da nicht für mich in verbindung mit der Objectlist eine praktikable lösung finde bleibt mir nichts anderes übrig.
Es macht keinen sinn auf einige Themen einzugehen solange diese Leute den kompletten Quelltext nicht gesehen haben.
Da du dir den ja angesehen hast kennst du ja die probleme.

Es ist einfach so das die Listen egal VB Collection/Delhi ObjectList nicht annährend kompatibel sind.
Muss mich mit dem Teil nochmal speziell beschäftigen.
Na ja hab noch genug zu tun kann mich mit dem Thema zur gegebenen Zeit nochmal auseinander setzen.

Danke an alle die mir mit Ratschlägen weiterhelfen wollten/haben.

gruss

[EWeiss]

Nur für die Leute die meinen ich brauche das oButton.Num nicht.

Delphi-Quellcode:

    WM_RBUTTONDOWN:
    begin
      case LoWord(wP) of
        // Button steuerung
        ID_BTN_BUTTON_FIRST..ID_BTN_BUTTON_LAST:
        begin
          oButton := goProgBar.Button(wp-ID_BTN_BUTTON_FIRST);

          If not Assigned(oButton) then
          begin
            Result := 0;
            Exit;
          end;

          if frmKeysHandle = 0 then
            frmKeysCreate(frmButtonHandle);

          EnableWindow(frmButtonHandle, False);

          edKeys.SetWindowText(edKeys.Handle, PWideChar(oButton.ButtonKey));
          edTooltips.SetWindowText(edTooltips.Handle, PWideChar(oButton.ToolTip));
          edCommand.SetWindowText(edCommand.Handle, PWideChar(oButton.ButtonCmd));
          SKAERO_SetCTLText(lblKeyCaption.Handle, 'Knopf' + IntToStr(oButton.Num));
        end;
      end;
    end;

Was macht es für einen sinn den Index des Button aus der Objectlist zu verwenden.
Aber ist ja alles redundant ;)

gruss

[Medium]

Emil, dein Design ist einfach dermaßen unübersichtlich und wuschig (ja, auch wenn der Code direkt vor einem sitzt), dass es sich einem nicht unbedingt intuitiv erschließt was für Loopings und Korkenzieher deine Hirnwindungen dabei gemacht haben. Für DICH mag das alles sonnenklar sein, aber dein Code ist halt mal alles andere als selbstdokumentierend. Und selbst mit Beschreibungen sind deine Lösungen noch immer eher ... kurios. Nicht jeder hat die Zeit und Muße sich auch in die unorthodoxesten Dinge einzulesen, manch einer hat aber dennoch den guten Willen und eine Idee um ggf. hilfreich zu sein. Lass deinen Sarkasmus also bitte weg, und schmetter nicht jeden Designvorschlag damit ab, dass das alles ja so sein muss. Abgesehen davon, dass das einfach nicht stimmt, ist es auch eine recht unsympathische Haltung.
Das alles hier, trotz der Gewissheit, dass es wie nicht selten bei an sich mitunter sehr gut gemeinten Tipps und Nachfragen, mit unterschweliger Überheblichkeit des "Pragmatikers über den Akademiker" abgetan wird. Aber du merkst doch selber, dass du dich in deinem Zeug verzettelt hast, und nicht mehr nachvollziehen kannst, was wann wo warum passiert. Das IST ein Designproblem (und nicht nur auf diesen Thread bezogen), und mit kleinschrittigen Lösungen bis "es zumindest kompiliert und ggf. auch zur Runtime keine Fehler wirft" kommst du aus der Nummer sehr wahrscheinlich nicht heraus.

Aber ist ja alles nur abfälliges Gefasel, weil du als armes VB Opfer ja nichts dafür kannst. Sorry, aber der Seitenhieb war langsam angebracht. Auch eine Vergangenheit mit VB ist kein Grund, es nicht doch besser machen zu können. (Ich hab ja selber mit QBasic lange Jahre gelernt.)

[EWeiss]

Geschmacksache!
Ansonsten Daumen runter.
Zu dumm irgend etwas davon zu zitieren oder Kommentare drüber abzugeben.

gruss

[Medium]

Genau das meinte ich. Viel Erfolg dennoch.

[EWeiss]

Zitat:

Zitat von Medium (Beitrag 1180190)

Genau das meinte ich. Viel Erfolg dennoch.

Habe ich Bestimmt!

gruss

[Furtbichler]

Hört uff mit dem Kinderkram.

Also: Was möchtest Du mit der Liste anstellen? Baue Dir eine Klasse 'ButtonList', die genau die Methoden zur Verfügung stellt, die Du benötigst.

Wer soll die Button-Instanzen freigeben? Die Buttonliste? Dann verwende als Basis eine TObjectList. Wenn nicht, reicht auch eine TList oder von mir aus ein Array.

Erstelle dann eine Testumgebung, die die einzelnen Methoden deiner Buttonliste testet. Läuft der Test durch? Ok. Schmeiss die Testumgebung bloss nicht weg.

Nun hast Du dir ein Werkzeug 'Buttonliste' gebaut, mit dem Du dein Problem viel einfacher lösen kannst.

Nebenbei verwenden Handwerker individuell hergestellte Werkzeuge, um ihre Probleme zu lösen. Beispielsweise Tischler, die z.B. Schablonen herstellen, um Zapfen identische Abstände zu verpassen etc.

Die Kreide, die Du gerade fressen musst, hat JEDER hier im Forum, der meint, programmieren zu können, auch schon durchgekaut. Bei einem gings schneller, beim anderen nicht. Egal.

[EWeiss]

Zitat:

Bei einem gings schneller, beim anderen nicht. Egal.

Ich muss ja nicht mein Geld damit verdienen..
Von daher habe ich alle Zeit der Welt, von der, die mir noch bleibt. :lol:

gruss

[Furtbichler]

Zitat:

Zitat von EWeiss (Beitrag 1180202)

Zitat:

Bei einem gings schneller, beim anderen nicht. Egal.

Ich muss ja nicht mein Geld damit verdienen..
Von daher habe ich alle Zeit der Welt, von der, die mir noch bleibt. :lol:

:thumb: Gib nur nicht immer Delphi die Schuld. ;-)