![]() |
Wait Animation
Projekt entfernt..
|
AW: Wait Animation
Sind 7 MB für eine Warteaanimation nicht bissl viel?
|
AW: Wait Animation
Zitat:
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 |
AW: Wait Animation
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 |
AW: Wait Animation
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". |
AW: Wait Animation
Zitat:
Und übergebe das *.PNG über Commandline. Kein Problem ;) gruss |
AW: Wait Animation
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. |
AW: Wait Animation
Zitat:
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:
Das geht am besten über Command-Line wenn ich nicht irre ;) gruss |
AW: Wait Animation
Das gleiche als EXE unter Verwendung von Command Line siehe oben.
gruss |
AW: Wait Animation
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: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:34 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz