Beiträge von Andy

Hi,
habe dir mal das Script bissl umgebaut und Kommentare eingefügt, damit du verstehst was dort los ist^^

Anmerkungen von mir dazu:
- Das Sleep() hält dein Programm für diese Zeit an, d.h. alle Maus-Klicks auf die Buttons werden in dieser Zeit nicht registriert!
Im Prinzip ist es Geschmacksache, aber ich würde überall, wo du bestimmte Zeit "warten" musst, den Eventmodus verwenden, damit du nicht diese Klimmzüge über den Timer machen musst.
Dem Eventmodus ist es nämlich egal, ob du in deinem Programm mit einem Sleep(23451223) einige Minuten die Programmausführung angehalten hast, er "unterbricht" gewissermassen das Sleep() und macht sofort weiter...
- Den Call() -Befehl brauchst du nicht unbedingt, du kannst die Funktionen auch so wie in meinem Beispiel aufrufen
- Alle Deklarationen von Variablen und Hotkeyset() und GuiOnEvent() gehören IMMER VOR DIE ENDLOSSCHLEIFE! Stehen sie dahinter, werden sie niemals abgearbeitet...
- Der Übersicht halber gehören die Funktionen alle HINTER DIE SCHLEIFE!
- Wenn du mit Scite arbeitest, drück ab und zu mal (bei Extras) auf TIDY AUTOIT SOURCE oder Ctrl+T , dann wird der Code automatisch "schön" gesetzt^^

ansonsten viel Spass mit AutoIt
ciao
Andy

*/edit*/ Man könnte die Pausefunktion komplett wegfallenlassen....mach das Script kürzer und ändere es so, daß man die Pause mit einem 2. Tastendruck auf die Pausetaste wieder beendet^^

Hi,
was ich bisher absolut nicht begriffen habe, was soll dieses "Tage=80" (in meiner Ini steht Tage=64 ).
Ich würde die INI so aufbauen:

Zitat

[Task1]
Tage=Montag,Mittwoch,Samstag, Sonntag
Uhrzeit=00:14
Quelle=c:\blablob\tralala\test
Ziel=f:\sicherungen\test

[Task2]
Tage=Donnerstag,Sonntag
Uhrzeit=16:22
Quelle=c:\kasjdfhakjh\traadaalala\test
Ziel=f:\sicherungen\skdjfh

[Task3]
Tage=Donnerstag,Freitag
Uhrzeit=19:14
Quelle=c:\kasjdfhakjh\traadaalala\test
Ziel=f:\sicherungen\skdjfh

Alles anzeigen

damit kannst du erstens recht einfach die Liste in der GUI füllen und auch die Abfrage der Zeiten wird einfach:
Das Dienstprogramm....läuft rund um die Uhr....

Und mit deiner GUI fütterst/änderst du nur die INI....

Generell ist es sinnvoll, die Forensuche zu bemühen....
z.B. so....Google sucht in AutoIt.deDa ca 80% aller Fragen im Wochenturnus wiederkehren, wirst du da sicher fündig, einfach mal die Scripte ausprobieren und gucken was die so machen....Fragen nerven nur, wenn man das Gefühl hat, dir soll einer "den Arm aus der Sonne legen"

*****Glaskugel reib...und reib....und reib........nix erscheint!***** Da wirst du wohl dein Script zeigen müssen.....

Zitat

Wenn die Funktion verlassen wird, werden alle lokalen Variablen gelöscht

Das gilt für Variablen, aber nicht für Strukturen! Genau das Problem hatte ich...in einer Func Strukturen definiert, die ich im nachhinein alle "von aussen" wieder löschen musste, dabei ist mir auch diese Lockbit-Geschichte aufgefallen....Die Pointer auf die Struktur kann man ja ByRef nach aussen weitergeben, oder per Return....

Naja, das Script hast du doch schon, in der Zeit, in der du das Posting geschrieben hast, wäre die GUI (wie von dir vorgeschlagen) schon 5x gescriptet!

Hallo,
was ich in diesem Zusammenhang immer extrem seltsam finde: genaue Koordinaten und Pixelfarben kann man also herausfinden, selbst als Hexzahl, aber für einen Blick in die Hilfe zu "Pixelsearch" (kostet nur ein F1 ! ) und das dort angegebene Beispiel anpassen ist zu schwer? Auch die Fehlermeldung von AutoIt ist nicht zu verachten "SYNTAX ERROR" und sogar das FALSE ist markiert.....also weg damit! Und schon funktioniert das Script!
ciao
Andy

Window-Info ist dein Freund, lies einfach das Control der Msgbox aus....

*EDIT* Markiert wird aber dadurch nichts.....

autoBert
diese Idee hatte ich auch schon, aber dann hat mich

Zitat

Wenn ich die .exe per Dateiebene direkt im Verzeichnis öffne, wird die MAC - Adresse mit übergeben und es funktioniert.

gewundert. In deinem Vorschlag würde die WAKE.EXE im @scriptdir ausgeführt, dort würde sie die Textdatei aber bei händischem Aufrufen (im Verzeichnis \WOL\1\ ) nie finden....

Zitat

Frage stellt sich mir, warum bzw. wozu Du es benötigst.

Da die MAC eindeutig vergeben bzw. zuzuordnen ist, gibt es nur extrem wenige "seriöse" Fälle/Anwendungen für einen Wechsel der MAC. Auf dei Antwort bin ich jedenfalls mal gespannt^^

Hi,
In der Regel setzt man den Timeout-Parameter etwas höher (einige Sekunden) um dem aufgerufenen Fenster Zeit zu geben um auf unvorhergesehene Ereignisse zu reagieren.
Man stellt so gewissermaßen sicher, daß das Fenster auch nach einer "angemessenen Zeit" nicht aktiv ist, also ist bei der Rückgabe von 0 irgendetwas schief gegangen...
Mit einigen Millisekunden Timeout ist der WinWaitActive-Befehl m.E. sinnlos, es soll damit ja extra so lange gewartet werden, bis das Fenster aktiv ist.
ciao
Andy

Hi,
öffnet die WAKE.EXE die Textdatei mit der MAC "automatisch" oder musst du die Textdatei als Parameter übergeben?

Zitat

Wie werden eigentlich die beiden DllStructs $tRect und $tData (_GDIPlus_BitmapLockBits) wieder freigegeben

Naja, die Struct hat eine Größe von 40 Byte (nochmal 14 für den Header sind zusammen 54Byte), die lässt man unter den Tisch fallen. Neulich las ich von einem Compiler, welcher bei jedem Byte nicht "ordentlich freigegebenem" Speicher eine Fehlermeldung rauswirft. Bei meiner Art zu Scripten hätte ich da keinen Spass mehr^^

Um dieses Speicher-Gepfriemel nicht auf die Spitze zu treiben wurde doch m.E. die "Garbage Collection" erfunden, alles was nach einem gewissen Zeitraum nicht zuzuordnen ist, kommt in den Müll, d.h. wird vom System freigegeben. Aber du hast schon Recht, genau so bin ich nämlich auf das Problem gekommen. Bei einigen Bytes ist das noch egal, aber wenn das Script haufenweise Speicher reserviert und nicht mehr freigibt, und dann nach 5 Minuten Windows aufgrund von Speichermangel die Ohren anlegt, dann ist das Geheule über das sog. "WinDOOF" wieder groß....dabei sitzt das größte Problem meistens zwischen den Ohren 40cm vor dem Bildschirm^^
Jedenfalls vielen Dank für deine Info!

Hi
wenn ich die html-Seite von hand aufrufe bekomme ich dort im Fenster im player die Info "Problem beim Verbindungsaufbau" im Flashplayer. 2% Prozessorlast
In der GUI sieht man nur ein kreuzchen statt des players....

omfg^^
nun hab ich 50% Last und keine GUI mehr, ABSTURZ^^

Hi,
wie HIER beschrieben, reserviert _GDIPlus_BitmapLockBits() einen "temporären" Puffer, der aber durch ein UnLock nicht mehr freigegeben wird...

Einfach mal das Script starten und im Task-Manager sieht man, daß die Speicherauslastung alle 5 Sekunden um ca 5MB (22´´) steigt.
Gibt es eine andere Möglichkeit, den Pointer auf die Bitmapdaten zu bekommen?
ciao
Andy

Hi,
ich vermute, daß (logischerweise) je nach System (32/64Bit) andere System-dll´s vom Betriebssystem aufgerufen werden. Ich bin sicher, daß wenn man zu diesem Script eine 32Bit(User32 oder etwas in dieser Richtung)-dll "hinzulinken" könnte, dann würde das Script auch in einem 64Bit-System fehlerfrei laufen.
Irgendein Aufruf irgendeiner API-Funktion schiesst quer....

Hi,
wie Greenhorn schon schrieb, hast du von den "nativen" 64Bit nur etwas, wenn du auch die entsprechenden Funktionen verwendest, d.h.bei einem "Installationsscript" wirst du wohl weniger etliche Gigabyte Adressraum und andere spezielle "schnelle" 64-Bit-Prozessorbefehle nutzen. Da hat das 64-Bitprogramm keinerlei Vorteile gegenüber 32 Bit....
Bei Bildbearbeitung und ähnlichem kann das schon anders aussehen. Aber da stellt sich die Frage, ob man sich so etwas mit AutoIt überhaupt antuen muss^^
Ich drücke es mal aus meiner Sicht aus, 64Bit braucht in der "Normalo"-AutoIt-Welt zzt noch kein Mensch.
Daher würde ich bei 32 Bit-Programmen (und Installation) bleiben. Auch mit Sicht auf die Weitergabe von Scripten.
Wenn du wirklich mal mit einem Script mal den 4-Gig-Addressraum sprengen musst, dann kompiliere es einfach in der parallel laufenden 64-Bit-Version
ciao
Andy

Zitat

und du kannst die Skripte immernoch als 32Bit Version kompillieren lassen wenn du willst.

so siehts aus..

Zitat

Fazit: Rücktritt eher unwahrscheinlich, wegen fehlender Vereinbarung der Beschaffenheit

FALSCH! Die vereinbarte Beschaffenheit geht davon aus, daß die Grafikkarte NICHT fiept. Seit Urzeiten gibt es Grafikkarten, NIEMALS ist dort ein Fiepen in irgendeiner Art und Weise vorgekommen! Wenn die Eigenschaft des Produktes derart gravierend geändert wurde, daß das Fiepen nun Bestandteil ALLER Grafikkarten ist, dann ist diese Änderung der Eigenschaft dem Kunden mitzuteilen! ich jedenfalls habe keine Info auf Seiten des Herstellers gefunden, der als "Feature" der Grafikkarte nun ein gegenüber dem Vorgängermodell hinzugefügtes Fiepen mitteilt^^

Aber du hast Recht...es ist müßig sich darüber Gedanken zu machen. Ähnliche Vorkommnisse haben allerdings schon etliche Firmen in den Ruin getrieben...wegen einiger "gesparter" Cent...

Zitat

aber es geht ums Prinzip, findet ihr nicht auch ?

Eine nicht Vertrags-(Vereinbarungs)gemäße Eigenschaft einer Ware stellt einen Mangel dar. Weder in deinem Kaufvertrag, noch in der Beschreibung (habe im i-Net nur eine "Installationsanweisung" gefunden) und auch nicht in der Werbung dieser Grafikkarte ist das Fiepen als eine (normale) Eigenschaft beschrieben. Im Prinzip liegt somit sogar eine arglistige Täuschung seitens des Händlers (Herstellers) vor, da diesem diese negative(!) Eigenschaft vor der Veräußerung bekannt war, er diese dir aber nicht mitgeteilt hat!

Da die Alternative gerade bei Grafikkarten ziemlich groß ist, würde ich den Weg des unzufriedenen Kunden gehen: Karte zu eBay und ein anderes Produkt kaufen.....

teste das mal.....