Panel mit vielen Buttons baut sich langsam auf

[jaenicke]

Zitat von NielsB:

mit Windows Themes vom Win 98 Style wegzukommen

Wo ich das lese:
Wirklich wichtig ist gerade auf den langsamen Atom Rechnern, dass man unter keinen Umständen die Themes deaktiviert. Sofern die Hardware diese unterstützt, wird dabei die Grafikkarte für vieles benutzt, das ohne Themes die CPU machen muss. Deshalb wird so Leistung frei, die dann dem Programm zur Verfügung stehen.

Wir hatten dabei schon extreme Unterschiede in der Richtung.

[NielsB]

Zitat von jaenicke:

Zitat von NielsB:

mit Windows Themes vom Win 98 Style wegzukommen

Wo ich das lese:
Wirklich wichtig ist gerade auf den langsamen Atom Rechnern, dass man unter keinen Umständen die Themes deaktiviert. Sofern die Hardware diese unterstützt, wird dabei die Grafikkarte für vieles benutzt, das ohne Themes die CPU machen muss. Deshalb wird so Leistung frei, die dann dem Programm zur Verfügung stehen.

Wir hatten dabei schon extreme Unterschiede in der Richtung.

Du meinst damit aber nicht die VCL Styles, oder? Die scheinen nämlich der Ursprung allen Übels zu sein
Ich habe mir die Optionen der Windows Themes angeschaut und offenbar kann man dort (mit entsprechend gepatchten Windowsdateien) ähnlich viel erreichen wie bei Delphi, allerdings ohne den Performanceverlust. Außerdem kann man die Optik direkt in Delphi sehen, was ich bei VCL Styles bisher nur zur Laufzeit konnte, man benötigt aber ein zusätzliches Tool, um die msstyles Dateien komfortabel bearbeiten zu können.

[jaenicke]

Nein, ich meine die Windows Themes. Ich habe aber schon oft gesehen, dass die auf solchen schwachen Systemen im Businessumfeld deaktiviert waren, was dann extra noch langsamer ist.

[Sherlock]

Zitat von NielsB:

Außerdem kann man die Optik direkt in Delphi sehen, was ich bei VCL Styles bisher nur zur Laufzeit konnte, man benötigt aber ein zusätzliches Tool, um die msstyles Dateien komfortabel bearbeiten zu können.

Diese Art des "Styling" geht aber auch nur bis zu einer bestimmten Windows Version gut. Spätestens Version 8 dürfte leider dagegen "immun" sein. Ich hatte auch früher mein XP mit einem Apple Skin versehen...aber irgendwann muss man auch mal einsehen, daß das Betriebssystem alles richtig macht. Vor allem, wenn der Anwender sich selbst Farben und eventuell auch Skins konfiguriert hat. Daran sollte man sich anpassen, und nicht andersherum. Freilich ist das in einem Kiosk-System anders. Aber wenn man da mit Performance zu kämpfen hat, dann sollte man eventuell beim Wesentlichen bleiben, und das wäre ein solides Programm mit einer durchdachten GUI. Im Moment will mir ehrlich kein Anwendungsfall ins Hirn, bei dem man 60 Buttons auf einmal brauchen sollte - den man nicht auch eleganter und für den Anwender verständlicher/übersichtlicher lösen kann.

Sherlock

[FarAndBeyond]

Zitat:

Ich stelle mir das gerade so ähnlich wie das hier vor:
http://www.bulkrenameutility.co.uk/Screenshots.php

Ich glaub' du hast da was falsch verstanden... Das ist eine sehr schöne GUI, die darüberhinaus noch übersichtlich und selbsterklärend ist!
Alter Schwede, ist das'n cooles Formular. Ganz offensichtlich darf man dafür auch etwas bezahlen wenn man möchte!!!



@NielsB:
Hast du mal darüber nachgedacht mit allen Verantwortlichen zusammen zu überlegen, ob es nicht besser ist das Schrottprogramm in die Tonne zu hauen und lieber ein neues Programm zu schreiben? Jeder schreibt genau auf was er von dem Programm erwartet und was es können muß und dann baut man ein sauberes, intelligentes Programm, daß für alle zukünftigen Dinge auch ausgerüstet und vorbereitet ist. Ich würde keine Sekunde in so ein Programm stecken...

Also die Beschreibung und die vielen durchnumerierten Buttons sprechen eine deutliche Sprache...


Davon mal abgesehen: Ich hab' z. B. Windows 7 (32bit Sp1) schon auf Rechnern installiert die weniger als 500 MB RAM hatten. Nach der Installation war Null MB RAM übrig.
Dann hab' ich die klassische Oberfläche eingestellt und die Aufgabenplanung und die Dienste komplett entrümpelt und danach hatte der Rechner wieder 200 MB freien RAM. Das Ding lief danach total stabil. Entscheidend ist, dass man den kleinen Rechner für einfache Aufgaben problemlos einsetzen konnte und das war keine HighEnd-Installation. 2/3 der Dienste sind für normale Aufgaben und Benutzer völlig wertlos und nur für Systemadministratoren interessant. Systemadmins werden allerdings wohl kaum einen Server mit 'ner normalen Windows-Version bestücken, falls sie überhaupt Windows einsetzen würden...

Weiterhin viel Spass und gute Nerven...

[FarAndBeyond]

Hi,
wenn du keine Angst vor fremden Echsen hast, dann kannst du ja mal diese hier ausprobieren..
Die hab' ich mit D7 gebaut und sie erzeugt bei mir 171 Buttons bis der Bildschirm voll ist. Das sind bei mir (W7 Sp1 x64) nur 1 MB im RAM und auf dem ältesten Rechner (P4 FirstVersion) mit XP x86 ungefähr 2,3 MB im RAM (96 Buttons).... (bei einem Klick auf den Button...) Das ist ja fast nichts... drollig... hatte bis jetzt noch nie viele Buttons in Gebrauch...

Alles baut sich sauber auf so wie es in der For-Schleife angedacht ist....

Delphi-Quellcode:

Unit uFullScreenButton;

Interface
 Uses
  Windows, SysUtils, Classes, Controls, Forms,
  StdCtrls, ExtCtrls;

 Type
  TForm1 = class(TForm)

   Panel1 : TPanel;
   Label1 : TLabel;
   Button1: TButton;

    Procedure FormCreate   (Sender: TObject);
    Procedure Button1Click (Sender: TObject);
  End;

 VAR
  Form1: TForm1;

Implementation
 {$R *.dfm}

Procedure TForm1.FormCreate(Sender: TObject);
 Begin
  Self.DoubleBuffered  := True;
  Panel1.DoubleBuffered:= True;

  Self.SetBounds(0, 0, Screen.WorkAreaWidth, Screen.WorkAreaHeight);
  Panel1.SetBounds(0, 85, (Self.ClientWidth), (Self.ClientHeight-85));

  Label1.Caption:= 'LOADING...';
 End;


Procedure TForm1.Button1Click(Sender: TObject);
  Var
   I: Integer;
   B: TButton;
   myTop, myLeft, countLeft, countTop,
   btnWidth, btnHeight, maxLeft, panMaxH,
   panMaxW: Integer;
 Begin
  btnWidth  := 100;
  btnHeight := 100;
  countLeft :=   0;
  countTop  :=   0;
  myTop     :=   0;
  myLeft    :=-100;

  Label1.Show;
  Form1.Update;
   panMaxH:= (Panel1.ClientHeight Div btnHeight);
   panMaxW:= (Panel1.ClientWidth  Div btnWidth);

   For I:= 1 To (panMaxH*panMaxW)
   Do
    Begin
     myLeft:= myLeft +btnWidth;

      If (Panel1.ClientWidth-(countLeft*btnWidth)) < btnWidth
      Then
       Begin
        myLeft   := 0;
        myTop    := myTop +btnHeight;
        maxLeft  := countLeft;
        countLeft:= 0;
        countTop := countTop +1;
       End;

     B:= TButton.Create(Self);
     B.SetBounds(myLeft, myTop, btnWidth, btnHeight);
     B.Parent:= Panel1;

     countLeft:= countLeft +1;
    End;
  Label1.Hide;
  Panel1.Show;
 End;
 
End.

Vielleicht bringt der Vergleich ja was, vielleicht auch nicht.... probieren geht über studieren...
Bis dann...

[Luckie]

Ich bin ja immer noch der Meinung, dass eine CheckListbox oder ein CheckListview das Kontrol der Wahl wäre, wenn mehrere Buttons ausgewählt werden können für eine Operation. Eventuell sollte sich der Threaderstelle sich diese Controls mal angucken. Obwohl ein Klick auf eine Schaltfläche löst eine Aktion aus, da würde sich eher eine normale Listbox anbieten. Leider habe ich immer noch nicht verstanden, warum das nicht möglich ist. Auch eine Listbox kann man dynamisch befüllen.

[himitsu]

Zitat von jaenicke:

Nein, ich meine die Windows Themes. Ich habe aber schon oft gesehen, dass die auf solchen schwachen Systemen im Businessumfeld deaktiviert waren, was dann extra noch langsamer ist.

Nicht nur das, vor allem via RDP, am Liebsten in einem schwachen Server/Netzwerk.

Wenn im System (Server 2008/2012) das Theming abgeschaltet ist, dann sind auch die neuen CommonControls v6.0 deaktiviert. (zumindestens im Delphi)
Sowas wie den TTaskDialog kann man dann vergessen (die gehen einfach nicht auf und es gibt auch keine Fehlermeldung) und auch die "neuen" FileOpenDialoge fallen auf die alte API zurück.

[NielsB]

Zitat von FarAndBeyond:

@NielsB:
Hast du mal darüber nachgedacht mit allen Verantwortlichen zusammen zu überlegen, ob es nicht besser ist das Schrottprogramm in die Tonne zu hauen und lieber ein neues Programm zu schreiben? Jeder schreibt genau auf was er von dem Programm erwartet und was es können muß und dann baut man ein sauberes, intelligentes Programm, daß für alle zukünftigen Dinge auch ausgerüstet und vorbereitet ist. Ich würde keine Sekunde in so ein Programm stecken...

Also die Beschreibung und die vielen durchnumerierten Buttons sprechen eine deutliche Sprache...


Davon mal abgesehen: Ich hab' z. B. Windows 7 (32bit Sp1) schon auf Rechnern installiert die weniger als 500 MB RAM hatten. Nach der Installation war Null MB RAM übrig.
Dann hab' ich die klassische Oberfläche eingestellt und die Aufgabenplanung und die Dienste komplett entrümpelt und danach hatte der Rechner wieder 200 MB freien RAM. Das Ding lief danach total stabil. Entscheidend ist, dass man den kleinen Rechner für einfache Aufgaben problemlos einsetzen konnte und das war keine HighEnd-Installation. 2/3 der Dienste sind für normale Aufgaben und Benutzer völlig wertlos und nur für Systemadministratoren interessant. Systemadmins werden allerdings wohl kaum einen Server mit 'ner normalen Windows-Version bestücken, falls sie überhaupt Windows einsetzen würden...

Weiterhin viel Spass und gute Nerven...

Das ist in der Tat schon eine Überlegung gewesen, denn das Programm stammt noch aus Win98 Zeit und wurde bis vor ein paar Jahren von einer einzigen Person entwickelt - dementsprechend sieht auch der Code aus... Über die Jahre hat sich einiges an Funktionalität angesammelt, die in einer Neuentwicklung vorhanden sein müsste. Tendenziell wird der Großteil der Ressourcen aber für das Instandhalten gebraucht, sodass eine Neuentwicklung in nächster Zeit unrealistisch ist.

[NielsB]

Zitat von FarAndBeyond:

Hi,
wenn du keine Angst vor fremden Echsen hast, dann kannst du ja mal diese hier ausprobieren..
Die hab' ich mit D7 gebaut und sie erzeugt bei mir 171 Buttons bis der Bildschirm voll ist. Das sind bei mir (W7 Sp1 x64) nur 1 MB im RAM und auf dem ältesten Rechner (P4 FirstVersion) mit XP x86 ungefähr 2,3 MB im RAM (96 Buttons).... (bei einem Klick auf den Button...) Das ist ja fast nichts... drollig... hatte bis jetzt noch nie viele Buttons in Gebrauch...

Alles baut sich sauber auf so wie es in der For-Schleife angedacht ist....

Danke, das stellt mein Problem super dar. Ich habe die Größe der Buttons angepasst, um meinen PC sichtbar zu beschäftigen, etwa 10000 Stück. Nicht, dass das irgendeinen Sinn hätte, aber man sieht deutlich, wie zunächst nichts passiert, während die Buttons erzeugt werden. Sobald das Label verschwindet, fangen die Buttons an, von unten nach oben zu erscheinen, anstatt alle gleichzeitig angezeigt zu werden.

Zitat von Luckie:

Ich bin ja immer noch der Meinung, dass eine CheckListbox oder ein CheckListview das Kontrol der Wahl wäre, wenn mehrere Buttons ausgewählt werden können für eine Operation. Eventuell sollte sich der Threaderstelle sich diese Controls mal angucken. Obwohl ein Klick auf eine Schaltfläche löst eine Aktion aus, da würde sich eher eine normale Listbox anbieten. Leider habe ich immer noch nicht verstanden, warum das nicht möglich ist. Auch eine Listbox kann man dynamisch befüllen.

Das ist vollkommen richtig und führt vermutlich auch zum Ziel. Allerdings gibt es die Probleme, die in diesem Beispiel durch die große Anzahl an Komponenten besonders sichtbar ist, auch in den anderen Formularen und wie oben gezeigt, auch auf moderner Hardware. Ich habe bisher noch keine definitive Antwort gefunden, ob das aufgrund von Delphi/Windows/Hardware-Limitierungen nicht möglich ist.