4. RAD Studio XE Sneak Preview

RAD Studio XE Sneak Preview

  • V

    Hat schon einer mal versucht die JEDI VCL vom SourceForge Server runter zu laden über das neue SVN IDE Feature?

    Bin grade dabei bzw. ist der Rechner mittlerweile 7 Stunden drüber
    CPU-Auslastung 100% (1 Core) und die Downloadliste bewegst sich nur sehr sehr langsam. Hat wohl ein Problem mit vielen Dateien? Oder liegst schon wieder
    an meinen Vista Testrechner?

    Also mal Tortoise SVN angeschmissen rennt wie sau.

    [EDIT] Habs nun Abgebrochen

    [EDIT2] Habs neu gestartet erst gehts ganz schnell und je mehr heruntergeladen wird merkt man es wird langsamer und natürlich volle CPU Auslastung 🙄

    0
  • ?

    Kann man diese ganzen Zusatztools, die jetzt mitgeliefert werden, wenigstens bei der Installation abwählen ?

    0
  • Z

    nn schrieb:

    Kann man diese ganzen Zusatztools, die jetzt mitgeliefert werden, wenigstens bei der Installation abwählen ?

    Yup sind alle in der Featurelist abwählbar.

    0
  • V

    Keine change je mehr Dateien das neue IDE-SVN runterläd desto langsamer wird es
    nun läuft wieder Tortoise SVN.

    0
  • A

    VergissEs schrieb:

    Hat schon einer mal versucht die JEDI VCL vom SourceForge Server runter zu laden über das neue SVN IDE Feature?

    Hm, nein - ich habe immer "svn checkout" verwendet.

    VergissEs schrieb:

    Hat wohl ein Problem mit vielen Dateien?

    Da benutzt wohl jemand Array + lineare Suche anstelle einer Hashmap...

    Von einem schnellen Blick in den Version Insight-Quelltext (gleichfalls auf SourceForge verfügbar, außerdem in den Samples mitgeliefert) konnte ich nicht erkennen, woran das liegen könnte - es sieht aus, als ob einfach nur die entsprechende Prozedur im SVN-API aufgerufen würde.

    0
  • A

    Das Problem ist, denke ich, das TListView im Update-Fenster:

    procedure TUpdateDialog.Add(const FileName, Action: string;
  Conflicted: Boolean);
var
  Item: TListItem;
  I: Integer;
begin
  if Files.Items.Count = 0 then
    for I := 0 to Files.Columns.Count - 1 do
      Files.Columns[I].Width := -1;
  Item := Files.Items.Add;
  Item.Caption := Action;
  Item.SubItems.Add(FileName);
  if Conflicted then
    Item.GroupID := 0
  else
    Item.GroupID := 1;
  //Autoscoll
  if not Conflicted then
    Item.MakeVisible(False);
end;

    Bei solch einem Datenumfang wäre es sicherlich sinnvoller, OwnerData zu benutzen...

    0
  • V

    Da hast du wirklich das Übel gefunden!

    Bei solchen Massen an Daten die vorkommen können sollte man wirklich die ListView virtuell verwenden.

    0
  • V

    Informierst du Uwe Schuster über dieses Fehlverhalten?
    bzw. das es evtl. in das nächste Patch mit kommt, damit es auch verwendbar ist.

    0
  • A

    VergissEs schrieb:

    Informierst du Uwe Schuster über dieses Fehlverhalten?

    Genau gesagt hätte ich nichts dagegen, wenn du einen QC-Report verfassen würdest, du hast es schließlich entdeckt 🙂 Aber es kann schon sein, daß ich Uwe eine Mail dazu schreibe.

    0
  • A

    Uwe schrieb mir, das Geschwindigkeitsproblem sei bekannt und intern längst behoben.

    Der Fix dürfte, nebst zahlreichen anderen, hier verfügbar sein:
    RAD Studio Version Insight Community Version

    0
  • V

    Leider ist das Problem nur "halb" behoben den es wird immer noch keine virtuelle ListView verwendet
    http://radstudioverins.svn.sourceforge.net/viewvc/radstudioverins?revision=13&view=revision

    Und wiso nicht die ganze

    procedure UpdateColumnWidth(AColumn: TListColumn; AItem: TListItem);

    sparen und den Benutzer selbst die Spaltenbreite verändern lassen?

    0
Anmelden zum Antworten