Ich nehme mal stark an, dass _GDIPlus_ImageLoadFromFile das Handle auf dem Dateisystem offen hält und du somit nicht in die Datei schreiben kannst.
Was du allerdings machen kannst, ist das Image zu manipulieren, das alte zu disposen und das neue zu saven.
Als Beispiel kannst du z.B. mit _ImageScale das Bild skalieren und den Returnwert mit _ImageSaveToFile nutzen (vorher aber das alte $hFile mit _ImageDispose disposen).
Zeig uns doch mal wie das Fenster heißt bzw. um welches Programm es sich handelt, vielleicht sehen wir ja was was du übersehen hast.
Da das Programm ziemlich durcheinander kommen könnte, wenn mehrere Instanzen laufen, habe ich Prüfungen eingebaut die solche verhindern.
Das wars eigentlich auch schon.
Ich spiele noch mit dem Gedanken eine Lokalisation für das Programm anzubieten, weil ich ja auch eine deutsche Anleitung verfasst habe aber das Programm bisher noch in Englisch ist.
Wenn ihr schon die Variabledeklaration anprangert dann lasst mich doch wissen was gnau euch daran nicht gefällt.
Woher soll ich einen anderen Programmierstil haben ich bin zu alt fü so Blödsinn und progge erst seit gut einem Jahr.
Früher hat das Zeug bei uns einfach nur laufen müssen, wir haben Code verwendet nicht in die Vitrine gestellt.Man ihr seid aber echt brutal.
Brutal würde ich nicht sagen, du möchtest Feedback zum Code und das kriegst du, wir versuchen dir zu helfen und nicht dich vom Coden abzuhalten.
Du musst selber für dich entscheiden ob du das was du hier liest umsetzen möchtest oder nicht, es ist ratsam aber niemand zwingt dich dazu.
Wenn du deine Skripte so besser durchblickst dann behalte deinen Stil, es ist dein persönlicher Geschmack.
Zum Thema Variablen und Funktionen:
Du schreibst z.B. $Anzahl, $Bild, $VStep oder $Clip. Jetzt weißt du sicherlich noch was in diesen Variablen gespeichert wird, aber ich garantiere dir, wenn du ein paar Monate mal nicht reinschaust, dann wirst du keine Ahnung haben wofür die gedacht waren.
Um dem Problem vorzubeugen verwenden die meisten User hier die sogenannte 'ungarische Notation', dabei stellt man den Typ der Variable als Präfix vor den eigentlichen Namen.
So wird aus $Anzahl $iAnzahl (Integer), aus $Clip wird $aClip (Array), $Bild (kannst du dir eigentlich sparen, die Variable wird nicht verwendet.
Zum Thema Formatierung:
Die Einrückungen schauen soweit ok aus (bis auf den Anfang mit If compiled, If error etc) aber du könntest deinen Code ein wenig auseinander ziehen.
In der F_BildEinfuegen Funktion schreibst du z.B. die ganzen GDIPlus und Clipboard Funktionen mit dem ganzen Send und If Zeugs einfach untereinander.
Wenn du das ganze sinnvoll trennst (GDIPlus Funktionen als Absatz, Zeile frei, Clipboard Funktionen als Absatz), dann sieht das ganze nicht nur schöner aus, sondern ist auch einfacher zu lesen.
Die Kommentare die du auskommentiert hast kannst du entfernen (z.B. Debugmeldungen). Kommentare sind trotzdem gerne gesehen, besonders wenn sie komplizierte Passagen erklären.
Du solltest dir über das gesagte nicht komplett den Kopf zerbrechen, wenn du die Zeit und Lust hast kannst du ja mal das eine oder andere umsetzen und gucken wie es dir dann gefällt.
Nur weil du eine Rohfassung des Handbuchs hochgeladne hast heißt es ja nicht, dass es so bleiben wird.
Ich gebe zu hier wird meistens nur das negative genannt und die Komplimente bleiben außen vor und dafür entschuldige ich mich auch mal (böse Angewohnheit).
Ist eigentlich gar nix daran brauchbar oder was?
Dein Script ist brauchbar! Es läuft super, das Hilfefenster schaut schick aus und es klappt doch, nur hinter den Kulissen könnte es sauberer sein.
Wenn du für das Programm (ohne Feedback zum Code) Feedback möchtest dann gibt es eigentlich nicht sehr viel zu beanstanden.
//Edit: @Tuxedo du hast beim Upload des Scriptes vergessen cURL mitzuliefern! Nur die .au3 reicht für das Programm nicht.
@autoiter ich glaube @Tuxedo würde sich freuen wenn du ihm etwas über sein Script sagen könntest statt mir die Vorzüge von dem AutoIt-Stripper zu predigen 
Du gibst mir ganz schön eins auf die Glöocke heute.
Warte mal bis die anderen loslegen!
Hmm, ich jedenfalls kann weder im Quellcode noch im Handbuch einen Hinweis finden, dass er die Funktion _Singleton() absichtlich herauskopiert hat. Ich selbst bin, von wenigen Ausnahmen abgesehen, kein Freund davon, Standard-UDFs zu filetieren .
Schön freut mich Alpines die erste Frage von Musashi, hast du schon für mich erledigt genau das war mein Gedanke includes einzusparen.
Hehehehehe...
Dazu gibt es doch Stripper. (Also das Programm).
Gut zu wissen, trotzdem kopiere ich lieber alles selber raus 
Ich weiß nämlich nicht wie viel der rausstrippt, bei Konstanten schreibe ich den Wert direkt in die Funktion und lasse sie nicht als einzelne Zeile stehen. (Auch bei Hilfsfunktionen etc).
daß die nicht lange zuverlässig laufen wird, habe den Namen jetzt gegen @ScriptName ersetzt. Das sollte eigentlich immer gehen oder irre ich mich.
Also bei der letzten Version ("Multi-Clip_v1.68_Aktuell") sehe ich immer noch den alten String. Wenn du @ScriptName verwendest wird der aktuelle Dateiname verwendet, d.h. wenn jemand die Datei umbenennt und startet, dann werden wieder zwei Instanzen laufen!
Hast Du das selber gemacht? Oder bekommt man aktualisierte UDF zum Herunterladen?
@water schreibt die Excel-UDF und ich glaube er hatte vor ein paar Tagen in irgendeinem Thread eine aktualisierte Version gepostet wo er das selbe Problem wegen des AutoIt-Versionsupdates wie @autoiter angesprochen hatte. Welcher Thread das ist weiß ich allerdings nicht mehr.
Hallo @Tuxedo !
Bin gerade knapp mit Zeit, daher habe ich es nur schnell überflogen.
Zu : _Singleton("Multi-Clip_v1.68.au3",0)
Du brauchst die Funktion _Singleton() nicht komplett in deinen Quellcode übernehmen. Es langt : #include <Misc.au3> - Dort ist sie enthalten.
Gruß Musashi
Er hat sie absichtlich rauskopiert damit er das gesamte Include nicht reinnehmen muss, mache ich auch so. (_ArrayDelete z.B.)
Dann wollen wir dir mal auf die Finger hauen!
An das Icon wirst du nochmal rangehen müssen, das ist ziemlich verpixelt.
_Singleton("Multi-Clip_v1.68.au3",0)
_Singleton zu nutzen ist schön mal eine schöne Idee und immer gerne gesehen aber du solltest nicht vergessen
dabei nur einen Produktnamen bzw. einen einzigartigen String zu vergeben und keinen mit einer Versionnummer.
Warum? Ganz einfach, wenn du dein Script updatest und v1.72 rausbringst und den _Singleton dementsprechend änderst und ein altes Script noch läuft,
so bringst du die Hotkeys und die ganzen Clipboards durcheinander und das wäre doch schade.
Am besten du nimmst als String sowas wie "MultiClipTuxedo", halt etwas einzigartiges wobei du bleibst. Außerdem solltest du immer Feedback einbauen, d.h. wenn jemand das Script startet und eins schon laufen sollte, sollte das neue Skript eine Meldung ausspucken wie z.B. "Es läuft bereits eine Instanz von Multi-Clip.".
While $Aktiv = False
If Not $Aktiv Then ToolTip("Multi-Clip wird pausiert", MouseGetPos(0) + 100, MouseGetPos(1) - 30, "Toggle Pause mit ALT+p")
Sleep(500)
WEndDie If-Abfrage hättest du dir hier auch klemmen können oder nicht? Du bist nur in der Schleife wenn $Aktiv false ist und du prüfst nach ob Not $Aktiv True ist was äquivalent ist.
Du solltest das auch lieber einheitlich coden, wenn du schon Not $Aktiv verwendest dann nimm es auch inder While-Schleife oder in der If = False. Einheitlicher Code schaut besser aus und ist einfacher zu lesen.
Die Timings und die Clipgrenze wird eventuell noch angepasst, je nachdem was die Benutzer an mich zurückmelden,
werde ich das so einstellen, daß die meisten User damit klarkommen werden.
Warum nicht unbegrenzt? Was spricht dagegen?
Übrigens könnt ihr auch die Exe-Files im Nachhinein so umändern, daß das Teil selbstständig mit
Adminrechten arbeitet indem ihr mit einem Resoureceneditor das Manifest abändert ist aber nicht ratsam
und eigentlich auch nicht notwendig, oder eben per Contextmenü als Administrator starten.
Das kann nicht jeder (das Manifest ändern), du solltest lieber auf das Script verweisen und den Leuten raten in die erste Zeile ein #RequireAdmin zu schreiben und es neu zu compilen, oder
du baust in die nächste Version eine Option ein die mit IsAdmin() prüft ob das Script als Admin gestartet wurde und ansonsten ShellExecute(@ScriptName, "", "", "runas") ausführt und sich selbst terminiert.
Dazu eine kleine Ini-Datei wo gespeichert ist ob als Admin gestartet werden soll und du führst den Befehl dementsprechend aus.
Es wäre ratsam das Programm in den Autostartordner zu schieben, da du ja nicht immer das Script vorher selber starten möchtest, der dazugehörige Ordner ist:
C:\Users\<UserName>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, dort eine Verknüpfung mit FileCreateShortcut ablegen und fertig.
AutoIt hat auch dafür ein Makro: @StartupDir. Das kannst du ebenfalls in die vorhin angesprochene Ini-Datei speichern.
Den ganzen Trivia- bzw. Geschichtskram hättest du ruhig aus dem Handbuch rauslassen können, da sollten wirklich nur die Bedienung, Umfang, Danksagungen und Lizenzen enthalten sein.
Zu dem Sourcecode möchte ich ehrlich gesagt nicht sehr viel sagen, mir persönlich gefällt er nicht.
Da sind ziemlich viele unnötige Kommentare, Variablen-/Funktionsbenennung ist mies (Stichwort: Ungarische Notation für Variablen) und das Format gefällt mir nicht.
Das ist aber meine persönlich Meinung und auf die solltest du nicht all zu viel Wert legen, hier gibts sicherlich noch dutzende andere User die ihren Senf loswerden wollen.
Aber jedes Script fängt so an, es ist ja nicht so, dass das hier die letzte Version sein wird, hoffentlich nimmst du dir die Kritik hier zu herzen und verbesserst dein Script Zeile für Zeile 
Isolier das Problem mal in ein neues kleines Script damit wir sehen können wo du das ganze eingebaut hast.
If $oError Then MsgBox(0,0,"Test")
In der Dokumentation die ich dir geschickt habe wird nirgends der Rückgabewert von ObjEvent verwendet also warum tust du es?
Hier mal ein rudimentäres Beispiel, kommentier die 1. Zeile aus und du wirst den Unterschied merken:
$oErrorEvent = ObjEvent("AutoIt.Error", "_MyErrFunc")
$oObject = ObjCreate("DieserKlassennamExistiertNicht")
$oObject.Blablubb("Diese Methode existiert auch nicht!")
Func _MyErrFunc($oError)
MsgBox(16, "AutoIt Error", "_MyErrFunc wurde ausgelöst und die AutoIt Nachricht wurde unterdrückt!" & @CRLF & _
"(" & $oError.scriptline & ") : ==> COM Error intercepted !" & @CRLF & _
@TAB & "err.number is: " & @TAB & @TAB & "0x" & Hex($oError.number) & @CRLF & _
@TAB & "err.windescription:" & @TAB & $oError.windescription & @CRLF & _
@TAB & "err.description is: " & @TAB & $oError.description & @CRLF & _
@TAB & "err.source is: " & @TAB & @TAB & $oError.source & @CRLF & _
@TAB & "err.helpfile is: " & @TAB & $oError.helpfile & @CRLF & _
@TAB & "err.helpcontext is: " & @TAB & $oError.helpcontext & @CRLF & _
@TAB & "err.lastdllerror is: " & @TAB & $oError.lastdllerror & @CRLF & _
@TAB & "err.scriptline is: " & @TAB & $oError.scriptline & @CRLF & _
@TAB & "err.retcode is: " & @TAB & "0x" & Hex($oError.retcode))
EndFuncIch kenne die Bezeichnung "UDF" nur unter "User definied function" (Benutzerdefinierte Funktion) in VBA.
UDF hat die selbe Bezeichnung in AutoIt aber damit bezeichnen wir auch die entsprechenden Dateien (oder Includes wenn du so willst).
Probier es doch mal aus, du findest per Google ja paar Beispiele wie man diese Fehlermeldungen registriert und schau einfach mal was passiert.
Die leere Funktion existiert schon in der UDF, d.h. wenn du sie nochmal hinschreibst wird der Compiler wegen 'duplicate function name' rummeckern.
Du kannst in den Error-Funktionen auch die Meldungen auslesen und dementsprechend verarbeiten.
Ich soll bitte was aufmachen?
Na die UDF Die Excel.au3 im Include Verzeichnis der AutoIt-Installation! Dann wirst du die Funktion auch sehen.
also keine Objecte wie in dem von Dir verlinken Beispiel
Mach mal die UDF auf und guck was du zurückbekommst. Da steht Return SetError(0, $bApplCloseOnQuit, $oExcel) und $oExcel ist $oExcel = ObjCreate("Excel.Application").
Die IntelliSense gibt dir nichts zurück, da __Excel_ComErrFunc (zwei __ nicht eins!) eine leere interne Funktion ist, du kannst diese mit einer eigenen überschreiben und so selber die Fehler behandeln.
Weil du nicht richtig suchst, hier mal das ganze für die IE.au3 (offizielle Dokumentation!): https://www.autoitscript.com/autoit3/docs/f…ns/ObjEvent.htm
Für andere Objekte funktioniert es eigentlich gleich.
Die Anzeige kommt von der _ArrayDisplay-Funktion, kommentier die Zeile einfach aus und fertig.
Wie kann ich solche Fehler sauber und korrekt abfangen
Mit einem COM-Error-Handler. Solltest du die Excel-UDF verwenden, so sollte einer schon aktiv sein glaube ich (__Excel_COMErrFunc),
dort kannst du die Fehler soft abfangen, ohne eine MsgBox vom AutoIt-Interpreter zu bekommen.
Dein Script irritiert mich ein wenig, deshalb habe ich mal das ganze ein wenig vereinfacht und selber was gebastelt:
Du solltest dein Script mit der IE.au3-UDF bauen, da das stabiler läuft als die Handles von einer riesigen Liste aller Fenster auszulesen. Dann klappt das auch garantiert.
#include <IE.au3>
_IEErrorNotify(False)
$oIE1 = __IECreate("wetter.de")
$oIE2 = __IECreate("google.de")
$oIE3 = __IECreate("autoitscript.com")
WinMove(_IEPropertyGet($oIE1, "hwnd"), "", 0, 0, 400, 300)
WinMove(_IEPropertyGet($oIE2, "hwnd"), "", 0, 300, 400, 300)
WinMove(_IEPropertyGet($oIE3, "hwnd"), "", 0, 600, 400, 300)
; Ab und zu schlägt das _IECreate fehl, deshalb führt diese Funktion solange _IECreate ausw
; bist eine gültige Internet Explorer Instanz erstellt wurde.
Func __IECreate($s)
Do
$oIE = _IECreate($s)
Until IsObj($oIE)
Return $oIE
EndFuncMal vom eigentlichen Problem abgesehen bin ich doch sehr überrascht, dass den anderen Logikfehler noch niemand entdeckt hat
Ich hab das schon gesehen nur war es für diesen Thread irrelevant.
