Mit einem solchen Thread könntest du dein Formular ruckelfrei einblenden:

zusammenfalten · markieren

Delphi-Quellcode:

unit Unit45;

interface

uses
   Vcl.Forms, System.Types, System.Classes;

type
  TScroll = class(TThread)
  private
    { Private-Deklarationen }
    anzeigepos : TPoint;
    function Zeit : Cardinal;
    function berechnepos( anteil : extended ) : TPoint;
  protected
    procedure Execute; override;
    procedure Ausgeben;
  public
    meinupdateform : TForm;
    startpos, zielpos : TPoint;
    startzeit, scrollzeit : Cardinal;
  end;

implementation


uses unit44;


procedure TScroll.Ausgeben;
begin
  meinupdateform.Left := anzeigepos.x;
  meinupdateform.top := anzeigepos.y;
end;


function TScroll.Zeit : Cardinal;
begin
  Result := GetTickCount; // du könntest hier auch einen anderen Zeitmesser einbauen...
end;


function TScroll.berechnepos( anteil : extended ) : TPoint;
begin
  if anteil >= 1 then
  begin
    Result.X := zielpos.X;
    Result.Y := zielpos.Y;
  end
  else
  begin
    Result.X := round(anteil*(zielpos.X - startpos.X)+startpos.X);
    Result.Y := round(anteil*(zielpos.Y - startpos.Y)+startpos.Y);
  end;
end;

procedure TScroll.Execute;

var lastanteil, anteil : extended;
    lastp : TPoint;

begin
  startzeit := Zeit;
  meinupdateform.Left := startpos.X;
  meinupdateform.Top := startpos.Y;
  meinupdateform.Show;
  lastanteil := -1;

  repeat
    anteil := ( GetTickCount - startzeit )/scrollzeit; // läuft von 0..1
    if anteil > lastanteil then
    begin
        lastanteil := anteil;
        anzeigepos := berechnepos( anteil );
        Synchronize( Ausgeben );
    end;
  until ( anteil >= 1 ) or terminated;
end;

end.

So würdest du die Sache aufrufen:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm43.updatescroll;
begin
  scroll := TScroll.Create( true );
  scroll.FreeOnTerminate := true;
  scroll.Priority := tpHigher;

  scroll.startpos := Point( -form44.Width, -0 ); // startpunkt
  scroll.zielpos := Point( 0, 0 ); // zielpunkt

  scroll.scrollzeit := 300; // in Millisekunden
  scroll.meinupdateform := form44;

  scroll.Start;
end;

Ich hab's mit eingeblendetem Hint gecheckt. Bei mir ruckelt nix.
Natürlich könnte man den Code schöner schreiben... .

Aber es ist wie dir Zacherl geschrieben hat: Mit Synchronize musst du automatisch in den Hauptthread - und wenn dich dort was ausbremst, dann nützt dir die Nutzung eines Threads rein gar nix.
Du könntest natürlich eine eigenständige exe schreiben, welche einfach deine Updateinfp einblendet .

Zitat:

scroll.startpos := Point( -form44.Width, -0 ); // startpunkt
scroll.zielpos := Point( 0, 0 ); // zielpunkt

Wenn man einen Monitor links neben dem Hauptmonitor hat, dann würde das hier ziemlich hässlich aussehen.

Danke Michael,
Genauso hatte ich das vor.

Ich hatte das Scrollen selbst ja in einem Thread, und hatte irrtümlicherweise angenommen ein synchronize würde nur zwischen den beteiligten Threads synchronisieren.

Ich werde das so mal umsetzen und ausprobieren.

Der Gedanke mit einer eigenen Exe hatte ich auch schon, hab den aber wieder verworfen, weil ich das noch so schön finde.

Gruß Hobbycoder

Hallo Hobbycoder

für Windows 10 könntest du auch das Windows Notification Center nutzen.

Ein Beispiel findest du hier:
http://docwiki.embarcadero.com/CodeE...cations_Sample


Noch einmal zu deinem Scrollen:
Wenn du aufwändige Arbeiten durchführen musst, dann lagere diese immer in einen Thread aus.

Selbst wenn du im Hauptthread sowas wie

markieren

Delphi-Quellcode:

procedure BenoetigtVielZeit;
var i : integer;
var
  i := 0;
  while i < 1000000000 do
  begin
      inc(i);
  end;
end;

aufrufst: Dein "Scroll Thread" wird blockiert, bis die "procedure BenoetigtVielZeit" beendet ist.

Natürlich könntest du all deine zeitaufwändigen Dinge im Hauptthread laufen lassen und immer wieder Application.ProcessMessages aufrufen (dann würde dein Scroll Thread weiter laufen) - das ist aber absolut nicht empfehlenswert. Ein Programm, welches Application.Processmessages verwendet gehört nicht auf eine Festplatte .

markieren

Delphi-Quellcode:

procedure BlockiertNichtIstAberMist;
var i : integer;
var
  i := 0;
  while i < 1000000000 do
  begin
      inc(i);
      Application.ProcessMessages;
  end;
end;

Gruss
M

Wir benutzen für Threadausgaben auch NonVCL-Fenster. Das ist einer der wenigen Fälle, in denen das wirklich Sinn macht. Denn da kann man wirklich aus dem Thread heraus das Fenster komplett ohne Synchronisation verwenden. Wenn man dann mehrere Threads hat und mehrere solcher Fenster und die auch ohne Blockierungen zu verursachen bewegen kann, ist das schon sehr angenehm.

Gut, die Entwicklung der Fenster ist nicht so schön, aber mit ein paar Wrapperklassen lässt sich das quasi wie ein VCL-Formular nutzen.

Zitat von Michael II:

Hallo Hobbycoder

für Windows 10 könntest du auch das Windows Notification Center nutzen.

Ein Beispiel findest du hier:
http://docwiki.embarcadero.com/CodeE...cations_Sample


Noch einmal zu deinem Scrollen:
Wenn du aufwändige Arbeiten durchführen musst, dann lagere diese immer in einen Thread aus.

An das Windows Notifacation Center hatte ich auch schon gedackt. Ich glaube nur Knapp 5-10% der Kundenrechner arbeiten schon unter Win10 (Für einen Großteil der verwendeten Anwendungen gibt es noch keine Freigabe für Win10). Von daher kann ich die nicht überall nutzen. Und auf Updates aufmerksam machen kann ich nicht von Win10 abhängig machen.

Und noch einmal zum Thema Scrollen:
Das passiert z.B. wenn ein Hint angezeigt wird, und teilweise bei bestimmten Aktionen der verwendeten Fremdkomponenten. Am deutlichsten ist es aber bei Hints. Darauf habe ich keinen Einfluss und kann das nicht in einen Thread auslagern. Ich denke der Weg die Updatemeldung in eine Thread zu packen ist schneller zu realisieren. Ansonsten läuft schon alles, was in irgendeiner Form Last verursacht bereits in einem Thread. Aber ein paar Interaktionen müssen schon noch im Hauptthread laufen. Und alle Proceduren, die im Hauptthread laufen, sind bisher nicht für das stocken verantwortlich, das habe ich geprüft.

Zitat von jaenicke:

Wir benutzen für Threadausgaben auch NonVCL-Fenster. Das ist einer der wenigen Fälle, in denen das wirklich Sinn macht. Denn da kann man wirklich aus dem Thread heraus das Fenster komplett ohne Synchronisation verwenden. Wenn man dann mehrere Threads hat und mehrere solcher Fenster und die auch ohne Blockierungen zu verursachen bewegen kann, ist das schon sehr angenehm.

Gut, die Entwicklung der Fenster ist nicht so schön, aber mit ein paar Wrapperklassen lässt sich das quasi wie ein VCL-Formular nutzen.

Hm....klinkt verlockend. Aber ich nehme mal an, du möchtest das nicht hier posten?

Zitat von Hobbycoder:

Hm....klinkt verlockend. Aber ich nehme mal an, du möchtest das nicht hier posten?

Darf ich leider nicht...
Aber da steckt eigentlich nicht viel dahinter, wenn man es richtig macht.

Das Fenster selbst steckt ja in einer Ressource. Das schöne ist nun, dass nach der Anzeige eines solchen Fensters dessen Controls ja alle da sind. Man findet die also direkt.

Die Klasse für solch einen Dialog ist nun von TThread abgeleitet. Beim Start des Threads zeigt der das Fenster mit ShowWindow an. Danach findet man mit EnumChildWindows die Controls, wobei als Userpointer einfach der eigene Dialog angegeben ist. So bekommt die Threadinstanz einen Methodenaufruf pro gefundenem Control.

Mit GetClassName bekommt man nun den Typ des Controls heraus und erstellt eine passende Wrapperklasse, alle abgeleitet von einer Basisklasse. Die Instanz kann man sich dann direkt merken um über die ID an die entsprechende Wrapperinstanz zu kommen.

Das Basiscontrol braucht sich nur das Fensterhandle usw. zu merken. Und ein Wrapper für ein Edit-Control muss eine property Text haben, die auf WM_GETTEXT, SetDlgItemText usw. geht.