Wait Animation

[EWeiss]

Projekt entfernt..

[himitsu]

Sind 7 MB für eine Warteaanimation nicht bissl viel?

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1364221)

Sind 7 MB für eine Warteaanimation nicht bissl viel?

Das sind die Ressourcen für die Skins.
Die benötigen nun mal ihren Platz.

Später werde ich eine extra DLL erstellen die dann keine Skins mehr verwendet da sie auch aus der VCL heraus gestartet werden soll.

OnlyWindow.exe = 183KB (Meine Test Anwendung für die Library)
SK_Aero.dll = 427KB
Background Ordner = 4,14 MB
Skins = 3,96 MB

Auf der anderen Seite es wird niemand gezwungen die Dateien zu laden. ;)
Ich programmiere Hauptsächlich für die Allgemeinheit.
Wenn die Leute davon etwas brauchen können gut wenn nicht auch Gut.

gruss

[EWeiss]

Habe nun eine eigenständige DLL erstellt die auch mit einer VCL Anwendung funktioniert.
Allerdings habe ich ein anderes Verhalten erwartet zumindest was die CPU Auslastung angeht.
Eigentlich hat ja die Anwendung selbst mit der Animation nichts zu tun destotrotz wird bei dieser die CPU Auslastung addiert\angezeigt nicht in der DLL.

Hmmm...

Vielleicht hat ja irgend jemand bock das noch zu optimieren so das die DLL (Animation) Thread (Hintergrundaktivität\ausgelastet) abhängig läuft.
Würde dann den Quelltext der DLL noch hochladen.

gruss

[Ghostwalker]

Logisch. Eine DLL ist kein eigener Prozess. Die Funktionen (und damit die CPU-Last) werden immer dem Prozess zugeordnet, der die entsprechende Funktion nutzt.

Daran würde auch die Abspaltung eines Thread's nichts ändern. Dieser würde genauso vom Prozess (sprich der Anwendung) "abgespalten".

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364260)

Logisch. Eine DLL ist kein eigener Prozess. Die Funktionen (und damit die CPU-Last) werden immer dem Prozess zugeordnet, der die entsprechende Funktion nutzt.

Daran würde auch die Abspaltung eines Thread's nichts ändern. Dieser würde genauso vom Prozess (sprich der Anwendung) "abgespalten".

Ok dann muss ich ne EXE erstellen.
Und übergebe das *.PNG über Commandline.
Kein Problem ;)

gruss

[Ghostwalker]

hmmm....also.....irgendwie werd ich nicht wirklich schlau, was die WaitCursor sache angeht.

Es gibt, wenn ich hier nicht irre, zwei Situationen, in denen der WaitCursor (Sanduhr) auftaucht.

a) Meine Anwendung ist ausgelastet.

Dann wir der Cursor nur angezeigt, wenn das entsprechend programmiert wurde (sprich Cursor = crHourglass).


b) Windows ist ausgelastet

Dann steuert Windows die Anzeige und zwar global unabhängig von irgendwelchen anderen
Prozessen. In so einem Fall startet aber auch kein Programm mehr.


Hab ich bis dahin schon was falsch verstanden ?:gruebel:

Wenn nicht:

In welchem Fall soll deine Animation jetzt greifen ?

Im Fall a)

Würd ich das wie schon erwähnt, als Komponente machen oder Funktionen mit Start/Stop.

Das wär dann genau als Alternative zu curor := crHourglass bzw. cursor := crDefault

Im Fall b)

hmm...der Fall tritt bei mir nur kurz vor einem Systemcrash auf...da wärs mir dann wurscht was
er da anzeigt.:mrgreen:

Aber ok..für den Fall bräuchte es ein Programm, das im Hintergrund die komplette Auslastung
des System prüft, und ggf. die Anzeige startet.

[EWeiss]

Zitat:

als Komponente machen

Nö keine gute Lösung soll unabhängig sein also von VCL/NONVCL

Beispiel:

Wenn ich mit meiner Anwendung eine Liste einlade und die Anwendung dadurch bedingt lange warten muss
beim starten dann soll die Animation angezeigt werden.

Das gleiche bei anderen Prozessen wie beim WaitCursor ist der Thread ausgelastet soll die Animation starten.

Wenn die Anwendung komplett steht brauch ich auch keine Animation mehr da Hilft nur noch ein String/Alt Entfernen
oder halt der Taskmanager über Prozess beenden.

Zitat:

Funktionen mit Start/Stop.

Ist auch nicht ganz so simple denn irgendwie muss ich ja die *.PNG Datei übergeben damit sie von der EXE dann ausgeführt wird.
Das geht am besten über Command-Line wenn ich nicht irre ;)

gruss

[EWeiss]

Das gleiche als EXE unter Verwendung von Command Line siehe oben.

gruss

[Ghostwalker]

Ah...ok...es geht also doch um die Anwendung :):zwinker:

Dann würd ich das aber als DLL machen. Damit wird zwar die Last der Anwendung zugeordnet, aber das ist ja auch richtig so, da sie ja auch das Warten verursacht.

Das ganze mit 2-3 Funktionen (start/stop evtl. init fürs PNG) und gut.

Vorteile DLL:

- Ist nur einmal im Speicher, auch wenn mehrere Anwendungen parallel die DLL nutzen
- Die Steuerung ist von der Anwendung aus einfacher.
- Kann von den meisten Programmiersprachen aus genutzt werden (selbst Script-Sprachen)
- Weniger Probleme mit den Windowsrechten auf einem Mehrbenutzer-System (und damit bei der
Installation einer Anwendung)


Vorteile EXE:

- Eigener Prozess unabhängig von der Anwednung


Nachteile DLL:

- Last wird dem Anwendungsprozess zugeordnet

Nachteile EXE:

- Wesentlich höherer Speicherverbrauch bei mehrfacher Nutzung unterschiedlicher Anwendungen
- Commandline-Aufrufe sind für einen Programmierer schwieriger zu handeln, als einfache
Funktions-Aufrufe
- Es gibt Script-Sprachen, die keine Commandline-Aufrufe machen können
- Schwierigeres handling auf Mehrbenutzersystemen, wegen Rechte von Executables.


Eine Komponente könnte man dann auch auf der DLL aufbauen (für die ClickyClicky-Fraction :) )

Ich hoff ich hab dir jetzt nicht den ganzen Plan über den Haufen geschmissen.:mrgreen:

[EWeiss]

Zitat:

Dann würd ich das aber als DLL machen. Damit wird zwar die Last der Anwendung zugeordnet, aber das ist ja auch richtig so, da sie ja auch das Warten verursacht.

Die frage wäre dann nur was passiert beim laden einer List mit mehr als 5000 Einträge (SoundListe)
wenn das laden schon verhindert das die Anwendung erst später angezeigt wird, läuft die Animation dann noch?

Zitat:

Das ganze mit 2-3 Funktionen (start/stop evtl. init fürs PNG) und gut

Habe zwei Initialize, DeInitialize
Initialize erstellt das Window und startet die Animation (jetzt in einem Thread)
Deinitialize stoppt die Animation und zerstört das Window.
Gut könnte man umbenennen was aber an der eigentlichen Funktion nichts ändert.

Zitat:

Commandline-Aufrufe sind für einen Programmierer schwieriger zu handeln, als einfache Funktions-Aufrufe

Sollte eigentlich kein Problem sein solange man sich an die Gegebenheiten hält.

Delphi-Quellcode:

procedure TForm1.StartAnimation;
var
  ExePath: PWideChar;
  Parameter: PWideChar;
begin
  // Parameter 1 = Png File
  // Parameter 2 = Delay
  // Parameter 3 = ParentHandle
  ExePath := PWideChar(ExtractFilePath(ParamStr(0)) + 'Spinner.exe');
  Parameter := PWideChar('/Eagle.png/30' + '/' + IntToStr(Handle));
  ShellExecute(0, 'open', ExePath, Parameter, nil, SW_SHOW);
end;

Ich parse dann in der Funktion nach dem erstellen des Windows die CmdLine mit dem Delemiter "/"

Delphi-Quellcode:

function IsFile(FileName: String): Boolean;
begin

  Result := FileExists(FileName) and not DirectoryExists(FileName);
end;

Delphi-Quellcode:

    Style := WS_POPUP or WS_VISIBLE;
    MainHandle := CreateWindowExW(WS_EX_TOOLWINDOW or WS_EX_TOPMOST, 'Spinner',
      '', Style, 0, 0, 0, 0, 0, 0, hInstance, nil);

    CmdLine := split(lpCmdLine, '/');

    if High(CmdLine) > 0 then
    begin
      if IsFile(CmdLine[1]) then
        Initialize(StrToInt(CmdLine[3]), MainHandle, ExtractFilePath(ParamStr(0)) + CmdLine[1],
          StrToInt(CmdLine[2]));
    end
    else
      DestroyWindow(MainHandle);

sollte eigentlich für kein Programm ein Problem sein ShellExecute aufzurufen. (Abgesehen von den UAC User Rechten)

Zitat:

Vorteile DLL:

- Ist nur einmal im Speicher, auch wenn mehrere Anwendungen parallel die DLL nutzen
- Die Steuerung ist von der Anwendung aus einfacher.
- Kann von den meisten Programmiersprachen aus genutzt werden (selbst Script-Sprachen)
- Weniger Probleme mit den Windowsrechten auf einem Mehrbenutzer-System (und damit bei der
Installation einer Anwendung)

Das ist alles richtig ;)

Zitat:

Eine Komponente könnte man dann auch auf der DLL aufbauen (für die ClickyClicky-Fraction)

Habe nichts dagegen wenn du Lust hast dir das zu überlassen mit der Komponenten.
Sag bescheid lade dann den Quelltext der DLL hoch .

Optimierung was die CPU Auslastung angeht kann man immer noch.
Ist halt auch abhängig davon wie groß die Animationen sind und dem entsprechenden Delay dazu.
Habe bisher von den erstellten Strips die ich habe eine Last zwischen 0 und 15%

Die Nachteile der EXE sind dann doch schwerwiegender abgesehen davon ob die Animationen auch noch laufen wenn die Anwendung selbst
wartet oder warten muss wenn ich die DLL Version letztendlich verwende.

EDIT:
Eventuell was noch fehlt.
Eine Callback in der die Start und beenden Aufrufe gestartet werden abhängig von der aktuellen Auslastung der Anwendung.
Vielleicht zu kompliziert? (Async Thread?)

gruss

[Ghostwalker]

Zitat:

Zitat von EWeiss (Beitrag 1364360)

Zitat:

Dann würd ich das aber als DLL machen. Damit wird zwar die Last der Anwendung zugeordnet, aber das ist ja auch richtig so, da sie ja auch das Warten verursacht.

Die frage wäre dann nur was passiert beim laden einer List mit mehr als 5000 Einträge (SoundListe)
wenn das laden schon verhindert das die Anwendung erst später angezeigt wird, läuft die Animation dann noch?

Da der die Startfunktion vor dem Starten der Ladefunktion aufgerufen wird, wird die auch
zuerst ausgeführt :) Sollte also schonmal kein Problem sein. Natürlich kann es zu Ruckel-Effekten
kommen, wenn das ganze den Rechner arg überlastet, aber das Problem hast du mit jeglichen Geschichten in der Hinsicht (selbst mit der simplen Progress-Bar).

Zitat:

Zitat:

Das ganze mit 2-3 Funktionen (start/stop evtl. init fürs PNG) und gut

Habe zwei Initialize, DeInitialize
Initialize erstellt das Window und startet die Animation (jetzt in einem Thread)
Deinitialize stoppt die Animation und zerstört das Window.
Gut könnte man umbenennen was aber an der eigentlichen Funktion nichts ändert.

Richtig, wie sie heißen is Wurscht.:-D

Zitat:

Zitat:

Commandline-Aufrufe sind für einen Programmierer schwieriger zu handeln, als einfache Funktions-Aufrufe

Sollte eigentlich kein Problem sein solange man sich an die Gegebenheiten hält.

Delphi-Quellcode:

procedure TForm1.StartAnimation;
var
  ExePath: PWideChar;
  Parameter: PWideChar;
begin
  // Parameter 1 = Png File
  // Parameter 2 = Delay
  // Parameter 3 = ParentHandle
  ExePath := PWideChar(ExtractFilePath(ParamStr(0)) + 'Spinner.exe');
  Parameter := PWideChar('/Eagle.png/30' + '/' + IntToStr(Handle));
  ShellExecute(0, 'open', ExePath, Parameter, nil, SW_SHOW);
end;

Ich parse dann in der Funktion nach dem erstellen des Windows die CmdLine mit dem Delemiter "/"

Delphi-Quellcode:

function IsFile(FileName: String): Boolean;
begin

  Result := FileExists(FileName) and not DirectoryExists(FileName);
end;

Delphi-Quellcode:

    Style := WS_POPUP or WS_VISIBLE;
    MainHandle := CreateWindowExW(WS_EX_TOOLWINDOW or WS_EX_TOPMOST, 'Spinner',
      '', Style, 0, 0, 0, 0, 0, 0, hInstance, nil);

    CmdLine := split(lpCmdLine, '/');

    if High(CmdLine) > 0 then
    begin
      if IsFile(CmdLine[1]) then
        Initialize(StrToInt(CmdLine[3]), MainHandle, ExtractFilePath(ParamStr(0)) + CmdLine[1],
          StrToInt(CmdLine[2]));
    end
    else
      DestroyWindow(MainHandle);

sollte eigentlich für kein Programm ein Problem sein ShellExecute aufzurufen. (Abgesehen von den UAC User Rechten)

Aber im Vergleich zu einem Funktionsaufruf doch weit umständlicher :)

Zitat:

Zitat:

Vorteile DLL:

- Ist nur einmal im Speicher, auch wenn mehrere Anwendungen parallel die DLL nutzen
- Die Steuerung ist von der Anwendung aus einfacher.
- Kann von den meisten Programmiersprachen aus genutzt werden (selbst Script-Sprachen)
- Weniger Probleme mit den Windowsrechten auf einem Mehrbenutzer-System (und damit bei der
Installation einer Anwendung)

Das ist alles richtig ;)

Zitat:

Eine Komponente könnte man dann auch auf der DLL aufbauen (für die ClickyClicky-Fraction)

Habe nichts dagegen wenn du Lust hast dir das zu überlassen mit der Komponenten.
Sag bescheid lade dann den Quelltext der DLL hoch .

Optimierung was die CPU Auslastung angeht kann man immer noch.
Ist halt auch abhängig davon wie groß die Animationen sind und dem entsprechenden Delay dazu.
Habe bisher von den erstellten Strips die ich habe eine Last zwischen 0 und 15%

Die Nachteile der EXE sind dann doch schwerwiegender abgesehen davon ob die Animationen auch noch laufen wenn die Anwendung selbst
wartet oder warten muss wenn ich die DLL Version letztendlich verwende.
[/QUOTE]

Das mit der Komponente kann ich gerne machen. Btw..da fällt mir ein, wenn jemand unbedingt das
als eigenständige EXE braucht, kann er sich ja auch ein kleines Programmschreiben, das dann extra
ausgeführt wird :)

Zitat:

EDIT:
Eventuell was noch fehlt.
Eine Callback in der die Start und beenden Aufrufe gestartet werden abhängig von der aktuellen Auslastung der Anwendung.
Vielleicht zu kompliziert? (Async Thread?)

gruss

Die Auslastung würd ich garnicht hernehmen, schließlich muss die permanent überprüft werden (egal ob nun in der Anwendung selbst oder in einem externen Programm oder in der DLL).

[EWeiss]

Zitat:

Das mit der Komponente kann ich gerne machen. Btw..da fällt mir ein, wenn jemand unbedingt das
als eigenständige EXE braucht, kann er sich ja auch ein kleines Programmschreiben, das dann extra
ausgeführt wird

Supi ;)

Mache das noch mit dem Thread fertig addier noch ein paar Animationen zum testen und lade es dann hoch.
Werde dann den Versuch mit der EXE löschen.

gruss

[EWeiss]

Neue Version oben incl. Thread\Source und neuer Animationen.
Hoffe du findest nicht zu viele Fehler ;)

Hier auf die schnelle noch ne Anim
Im Source Archiv enthalten.

Einfach im Projekt zur Case addieren ..

Delphi-Quellcode:

    if SpinnerCount = 9 then
      SpinnerCount := 0;

Auf 8 erhöhen und das anfügen.

Delphi-Quellcode:

      6:
        begin
          Spinner := CTRL_SpinnerCreate;
          SpinnerHandle :=  Spinner.CreateWindow(Handle);
          SpinnerFile := ExtractFilePath(ParamStr(0)) + 'spinn.png';
          Spinner.Start(Handle, SpinnerHandle, SpinnerFile, 100);
        end;

      7:
        begin
          Spinner := CTRL_SpinnerCreate;
          SpinnerHandle :=  Spinner.CreateWindow(Handle);
          SpinnerFile := ExtractFilePath(ParamStr(0)) + 'butterfly.png';
          Spinner.Start(Handle, SpinnerHandle, SpinnerFile, 75);
        end;

      8:
        begin
          Spinner := CTRL_SpinnerCreate;
          SpinnerHandle :=  Spinner.CreateWindow(Handle);
          SpinnerFile := ExtractFilePath(ParamStr(0)) + 'cube01.png';
          Spinner.Start(Handle, SpinnerHandle, SpinnerFile, 16);
        end;

gruss

[Ghostwalker]

Sieht gut aus. Das einzige das ich vermisse ist,
das ich keinen Stream statt eines Dateinamens (für die Animation) angeben kann.:zwinker:


Komponente is auch so gut wie fertig :)

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364390)

Sieht gut aus. Das einzige das ich vermisse ist,
das ich keinen Stream statt eines Dateinamens (für die Animation) angeben kann.:zwinker:

Dann noch eins.. ;) Ist einiges an Arbeit die Anims zu erstellen :)
Im Source Archiv enthalten.

Ja das Problem ist mit Streams das ich GdipDrawImageRectRectI die einzelnen Frames zeichne.
Ich muss mich mal schlau machen ob es möglich ist die Animationen als Stream zu zeichnen. (Habs noch nie gemacht)
Das bringt allerdings nur etwas wenn das einen kräftigen Schub bringt was die Auslastung angeht.

Solltest du was anderes meinen dann kannst du es gerne ändern wenn es möglich ist und es deiner Meinung etwas bringt.

Hoffentlich schlägt Daniel mich nicht für die ganzen Uploads.

Zitat:

Komponente is auch so gut wie fertig

Supi! :thumb:

gruss

[Ghostwalker]

Neeeee....Streams wie TStream als Quelle der Animation. Damit könnte man z.B. das png mit in die Resource der Anwendung packen und dann statt filename einfach einen TResourceStream übergeben :)

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364395)

Neeeee....Streams wie TStream als Quelle der Animation. Damit könnte man z.B. das png mit in die Resource der Anwendung packen und dann statt filename einfach einen TResourceStream übergeben :)

Ach so..
JO würde gehen macht aber die EXE dementsprechend groß ;)
So wie es im Moment ist, ist man unabhängig und kann Nacheinander die Anims laden so wie man sie gerade braucht.

gruss

[Ghostwalker]

Naja...die Varianten schließen sich ja nicht aus :) Entweder ein Dateiname oder ein Stream.

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364399)

Naja...die Varianten schließen sich ja nicht aus :) Entweder ein Dateiname oder ein Stream.

Jo gegen eine Kombination hätte ich nichts ;)

gruss

[Ghostwalker]

Naja..hab mal fix in der msdn geguggt. In der GDI+ gibts eine entsprechende Funtkion
(...LoadFromStream) die als Parameter einen IStream erwartet, statt einer Datei.


Sollte also für dich kein Problem darstellen :)

Das ganze im Interface über eine alternative Start-Funktion eingebaut und feddich :)

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364403)

Naja..hab mal fix in der msdn geguggt. In der GDI+ gibts eine entsprechende Funtkion
(...LoadFromStream) die als Parameter einen IStream erwartet, statt einer Datei.


Sollte also für dich kein Problem darstellen :)

Das ganze im Interface über eine alternative Start-Funktion eingebaut und feddich :)

Jo sollte funktionieren..
Werde mir das nachher mal anschauen.

EDIT:
Wie würdest du denn die Function für das laden der Ressource übergeben wollen ?
Die DLL kennt ja die Ressource nicht.

gruss

[Ghostwalker]

Als Interface (IStream), so wie es letztlich (lt. Doku) auch die API braucht. Das funktioniert auch
mit DLL's

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364429)

Als Interface (IStream), so wie es letztlich (lt. Doku) auch die API braucht. Das funktioniert auch
mit DLL's

Kein Problem mit Interface die verwende ich ja auch selbst in der DLL.

Das Problem ist ein anderes, was ich meine.

Theoretisch kannst du die Ressource ablegen als "PNG" "BINARY" "RCDATA"
Woher soll nun die DLL wissen welchen Ressourcenamen die EXE für seine PNG Dateien verwendet ?

NEBENBEI:
Habe das teil jetzt in meine Soundmachine eingebunden.. > 5000 Dateien
Wenn die Liste geladen wird, dann wird diese Animation angezeigt.
Wenn fertig schaltet sie aus und mein Fenster der Anwendung wird angezeigt.

Zudem wird sie eigenschaltet bei kritischen Prozessen wo ich weis das diese etwas länger dauern bis sie abgeschlossen sind.
Wenn ich zum Beispiel von der ListView zur Visualisierung schalte. usw..

gruss

[Ghostwalker]

Braucht sie nicht. Du bekommst das IStream-Interface von der Anwendung übergeben.

Das brauchst du im Endeffekt nur durchreichen an die entsprechende GDI+-Funktion.

In etwa so:

Delphi-Quellcode:

   :
    procedure StartStream(ParentHandle: HWND; WinHandle: HWND; stream:IStream SpeedDelay: Integer);
   :

Die GDI+ funktion sollte sich die Daten dann statt aus der Datei aus dem Stream holen.

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364432)

Braucht sie nicht. Du bekommst das IStream-Interface von der Anwendung übergeben.

Das brauchst du im Endeffekt nur durchreichen an die entsprechende GDI+-Funktion.

In etwa so:

Delphi-Quellcode:

   :
    procedure StartStream(ParentHandle: HWND; WinHandle: HWND; stream:IStream SpeedDelay: Integer);
   :

Die GDI+ funktion sollte sich die Daten dann statt aus der Datei aus dem Stream holen.

Ok.
Ich denke das einladen von der Ressource wird dann die Anwendung übernehmen und die übergibt lediglich den IStream
den ich in der DLL benötige um daraus das Img zu erstellen.
Korrekt?

Ok dann werde ich die Funktion so übernehmen.

gruss

[EWeiss]

Neue Version mit dem IStream (ActiveX) hochgeladen.
Ich hoffe das es läuft habe es nicht getestet.

Laden von Spectragram siehe Shot der Ball.

gruss

[EWeiss]

So..
Leider hat das letzte Archiv mit der Funktion GdipLoadImageFromStream nicht funktioniert.
Ich hatte vergessen den var Parameter zu addieren.

Delphi-Quellcode:

function GdipLoadImageFromStream(
  stream: IStream;
  var image: Cardinal
): GPSTATUS; stdcall; external LibGdiPlus;

Damit das jetzt alles funktioniert habe ich auch gleich eine PNG in die Ressource gepackt und die Funktion getestet.
Das 4 Image wird jetzt aus der Ressource geladen.

Delphi-Quellcode:

      4:
        LoadStream(1);

Delphi-Quellcode:

procedure TForm1.LoadStream(Index: Cardinal);
var
  ResStream: TResourceStream;
  adapter: IStream;
begin
  ResStream := TResourceStream.CreateFromID(hInstance, Index, RT_RCDATA);
  ResStream.Position := 0;
  adapter := TStreamAdapter.Create(ResStream);

  try
    Spinner := CTRL_SpinnerCreate;
    SpinnerHandle :=  Spinner.CreateWindow(Handle);
    Spinner.StartStream(Handle, SpinnerHandle, adapter, 30);
  finally
    ResStream.Free;
  end;
end;

sollte jetzt Funktionieren.
Bin jetzt aber nicht sicher ob ich den adapter auf Nil setzen sollte.
Kann man später noch machen sollte das nötig sein. :stupid:

sorry für den Ärger ;)

gruss

[Ghostwalker]

Was für Ärger ?:shock:

Habs mir schonmal runtergeladen. Sobald ich die Komponente geupdated hab, stell ich as mal hier rein :)

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364473)

Was für Ärger ?:shock:

Ich meine das ich das Archiv wieder aktualisieren musste wegen meiner eigenen Dummheit.

Zitat:

Habs mir schonmal runtergeladen. Sobald ich die Komponente geupdated hab, stell ich as mal hier rein :)

Fein ;)

gruss

[Ghostwalker]

Und hier schon mal eine Runde von mir :)

Ich musste zwar umstellen auf die Ansi-Api, weil mein System zu alt ist. Aber funktioniert soweit :)

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364483)

Und hier schon mal eine Runde von mir :)

Ich musste zwar umstellen auf die Ansi-Api, weil mein System zu alt ist. Aber funktioniert soweit :)

Lechs direkt mal testen.

gruss

[EWeiss]

Ok Vom Stream funktioniert nicht.
Muss es mal nach D2010 umlegen weil die Komponenten TntStdCtrls, TntDialogs nicht vorhanden sind.
Kann es so nicht debuggen.

gruss

[Ghostwalker]

Ja, wie gesagt ich muß noch den Umweg über TNT gehen. D2010 und XP mögen sich nicht wirklich :)

(Aber Rettung ist in Sicht)

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364490)

Ja, wie gesagt ich muß noch den Umweg über TNT gehen. D2010 und XP mögen sich nicht wirklich :)

OK ;)

Zitat:

(Aber Rettung ist in Sicht)

Was meinst du meine Änderungen oder deine?

EDIT:
Ok vom Stream funktioniert wenn in der Ressource der Eagle eingebaut ist.

gruss

[EWeiss]

Habe die Komponente nach D2010 umgeändert und zum ersten Post addiert.

gruss

[Ghostwalker]

:thumb:

[EWeiss]

Zitat:

Zitat von Ghostwalker (Beitrag 1364507)

:thumb:

Danke für deine Mithilfe denke sollte jetzt komplett sein :)

gruss

[HolgerX]

Hmm..

Habe mir das Demo angesehen..
(ohne Src anzuschauen)

Was mir nur aufgefallen ist, dass der Spinner immer an der Stelle auf dem Bildschirm verbleibt, an welcher er gestartet wurde.

Verschiebt man nun das Fenster der Applikation oder minimized es, bleibt der Spinner stehen.

Vielleicht gibt es ja eine Möglichkeit das der Spinner mitgeht.

Und eventuell Transparenz? ;)

(alles nur Ideen.. ;) )

[EWeiss]

Zitat:

Was mir nur aufgefallen ist, dass der Spinner immer an der Stelle auf dem Bildschirm verbleibt, an welcher er gestartet wurde.

Ja es ist eine Wait Animation.
Und diese wird zentriert über das Parent Fenster gesetzt.

Es ist nicht vorgesehen das die Animation mitgeht.
Ich glaube nicht das wenn eine Anwendung bei verschiedenen Prozessen ausgelastet ist der User sein Window Verschieben will.
Das Sample ist ja nicht maßgeblich da hier die Animation nur gestartet und beendet wird.

Bsp.
Ich starte eine Anwendung die beim initialisieren ein liste mit mehr als 5000 Einträge lädt.

Delphi-Quellcode:

function TPlayList.LoadM3UFile(Filename: String): Boolean;
var
  F: TextFile;
  Buffer, iTime, sFilename, sParse: string;
  k, iPos1, iPos2: Integer;
begin
  Spinner := CTRL_SpinnerCreate;
  SpinnerHandle := Spinner.CreateWindow(MainHandle);
  SpinnerFile := SKAERO_FOLDER + 'Spinner.png';
  Spinner.Start(MainHandle, SpinnerHandle, SpinnerFile, 30);

  AssignFile(F, Filename);
  Reset(F);
  PlayListCount := 0;
  while not Eof(F) do
  begin
    ReadLn(F, Buffer);
    if Buffer = '#EXTM3U' then
      Continue;

    ReadLn(F, sFilename);
    LVPlayList.SetSysItemIcon(PlayListCount, 2, sFilename);

    if Pos('#EXTINF', Buffer) > 0 then
    begin
      LVPlayList.InsertItem(LVPlayList.Handle, PlayListCount, IntToStr(PlayListCount + 1));
      iPos1 := Pos(':', Buffer);
      iPos2 := Pos('|', Buffer);

      iTime := Copy(Buffer, iPos1 + 1, iPos2 - iPos1 - 1);
      LVPlayList.SetItemText(LVPlayList.Handle, PlayListCount, 1, iTime);

      for k := 0 to 2 do
      begin
       sParse := ParseThis(Buffer, '|', K + 1);
       case K of
         0:
           LVPlayList.SetItemText(LVPlayList.Handle, PlayListCount, 2, sParse);
         1:
           LVPlayList.SetItemText(LVPlayList.Handle, PlayListCount, 3, sParse);
         2:
           LVPlayList.SetItemText(LVPlayList.Handle, PlayListCount, 4, sParse);
       end;
      end;
      LVPlayList.SetItemText(LVPlayList.Handle, PlayListCount, 5, sFilename);

      Inc(PlayListCount);
    end
    else
    begin
      if ExtractFilePath(Buffer) = '' then
        FFile.Add(ExtractFilePath(Filename) + Buffer)
      else
        FFile.Add(Buffer);

      FTitle.Add(Buffer);
      FTime.Add('');
    end;
  end;
  CloseFile(F);

  LVPlayList.SetColAutoSize(LVPlayList.Handle, 2);
  LVPlayList.SetColAutoSize(LVPlayList.Handle, 3);
  LVPlayList.SetColAutoSizeUseHeader(LVPlayList.Handle, 4);

  if (PlayListCount > 0) then
    MainApp.PlayListPlay(LVPlayList.Handle, PlayListCount);

  Result := True;
end;

Dann starte ich den Spinner.
Nach dem laden wenn das Fenster angezeigt wird beendet sich dieser.
Also ein Fenster ist in dem Fall gar nicht sichtbar wenn die Animation startet.

Delphi-Quellcode:

      MainInit := TRUE;

      if SpinnerHandle <> 0 then
        SpinnerHandle := Spinner.Stop;

      while GetMessage(Msg, 0, 0, 0) do
      begin
        if IsDialogMessage(MainApp.Handle, Msg) = False then
        begin
          TranslateMessage(Msg);
          DispatchMessage(Msg);
        end;
      end;

Zitat:

Und eventuell Transparenz?

Welche Transparenz?

Die Animationen sind Transparent dazu verwende ich die DWM.

gruss