Beiträge von alpines

    ControlSetText($Bereich,"","[CLASS:Edit; $Textbox_X]", "Text2") ; sollte auf Input Control "$Textbox_X" der GUI test senden.(INSTANCE:2)

    Du kannst nicht einfach eine Variable an dem Platz als String einfügen und erwarten, dass er das Control anspricht welches im anderen Skript in $Textbox_X eingespeichert ist. Lies dir mal die Hilfe dazu genauer durch.

    Der Selektor ist ungültig, du müsstest stattdessen direkt nach dem Control suchen.


    Möglich wäre (sofern $Textbox_X die Control-ID ist):

    AutoIt
    1. ControlSetText($Bereich, "", $Textbox_X, "Text")

    Ich würde an deiner Stelle vielleicht den englischen Beitrag in einen Spoiler setzen, denn beide Sprachen gleichzeitig braucht man nicht.

    Eine kleine Nachricht oben im Thread "English version here" oder so, und fertig, aber es ist ja dein Thread.



    Was ist denn der aktuelle Entwicklungsstand? Welche Features willst du noch implementieren?

    Arbeitest du eigentlich schon an den Eventsachen? Du könntest die ja vorerst als Menupunkt einbinden, und wenn die Events stehen schreibst du das einfach um, dann hast du den Code bis dahin schon mal fertig.

    Das Problem ist, dass beide Umgebungen in verschiedenen User-Kontexten laufen. Wenn das Programm als Admin läuft, aber die Netzwerkfreigabe nicht mit Admin-Rechten geöffnet wurde, geht kein Drag&Drop. Beides muss also im gleichen Kontext sein, dann klappt das auch.

    Ich hatte mal das selbe Problem, ohne verschiedene Privilegien. Dazu hatte ich sogar mal ein Ticket erstellt aber das wurde geschlossen weil der Code fehlerhaft war, auch wenn ich zig Drag&Drop-Skripte probiert habe.

    Unter Win7 gings ohne Probleme.


    x0r wie schaut denn dein Skript aus mit dem du das reproduzieren kannst?

    Hi Code4Fun,


    aus Gründen des Datenschutzes habe ich das Bild mal vollständig entfernt, denn du hast die Ziffern am Ende nicht unkenntlich genug gemacht.

    Die Nummer konnte man sich immer noch zurechtbiegen. Ob das nun eine echte Telefonnummer war weiß ich nicht, aber lieber Vorsicht als Nachsicht.


    Es gab mal zu Skype eine Bibliothek namens Skype4COM. Vielleicht wird diese ja noch unterstützt und du kannst daraus den ankommenden Anruf identifizieren?

    Da die Shoutbox ausgetauscht wurde habe ich mein CSS angepasst, jetzt schaut das ganze so aus:

    (Die Smileys glitchen komisch rum wenn man die Box öffnet aber, wers braucht passt das an)



    Das RegEx ist immer noch dasselbe, die Styles in Stylebot schauen so aus:

    Changelog habe ich noch nie gemacht.

    Einfach nur die neuen Features der neuen Version posten, so dass man sehen kann was sich verändert hat. Ein Beispiel wie es aussehen kann findest du hier.


    Hat die "Installation" denn bei dir geklappt? Funktionieren die Shortcuts und die Fav-Tools? Kommt der Compiler-Output an?

    Ja, alles super. Der Syntaxhighlighter ist nur ein wenig von den Block-Kommentaren #cs #ce irritiert. Die werden als Präprozessoren geparst obwohl das so ja nicht ganz richtig ist.

    Super Sache, mit dem Thread wirds schon fast amtlich/offiziell. :thumbsup:


    Wünschenswert (für die zukünftigen Releases/Zwischenstände) wäre ein Changelog um zu sehen was sich zwischen den Versionen verändert hat.

    Und wenn die Events für PSPad kommen, dann gehts richtig los.

    Das macht der Editor, nicht ich. Wie in SciTE, so auch in PSPad, öffne ich ein AutoIt-Script und drücke F5 für "Run". Den Compiler habe ich in PSPad eingetragen, inkl. AutoIt3Wrapper-Parameter. Wenn ich nun F5 drücke, wird das Script ausgeführt.

    Sicher, dass es der Compiler macht? Ich denke SciTE startet bei F5 den AutoIt3Wrapper und dieser managed die ganzen Hotkeys. Die Konsole bestätigt auch das ganze:


    Also macht SciTE mit den Hotkeys nichts, der Wrapper macht das ganze. D.h. du schreibst entweder einen eigenen Run/Compiler-Wrapper oder benutzt den AutoIt3Wrapper. Wenn du letzteres nutzt musst du den Hotkey nicht abfangen, das macht das Teil ja für dich.


    Wenn du das ohne den Standardwrapper machen möchtest (deshalb wurde das Ding ja gebaut, weil SciTE nicht die Funktionen dafür anbietet), kannst du das machen in dem du die PID des Parentprozesses holst, bzw. alle Child-PIDs von der aktuellen PSPad Instanz.

    Wie man Parent PIDs holt findest du hier: https://stackoverflow.com/ques…ent-process-id-on-windows

    Nachtrag: Was bedeuted denn "Du spawnst doch die neuen Skripte"?

    Wenn man in SciTE ein AutoIt-Script auführt (F5) und das Script in einer Routine festhängt, kann man mit dem Hotkey "Ctrl+Break" die Ausführung abbrechen.

    Guck mal auf den Returnwert: https://www.autoitscript.com/a…unctions/ShellExecute.htm

    Wenn du das Skript ausführst, und das tust du ja, und nicht der Editor, weißt du auch die PID mit der es läuft.

    So wird das auch der Wrapper machen.


    Spawnen kannst du in diesem Kontext gleichsetzen mit Ausführen.

    Auch das Beispiel von Jan ist einleuchtend: Wenn der Extention-Schreiber z. B. den markierten Text auswertet und ändert, während der Editor-User selbst den markierten Text ändert, kann das in eine Endlos-Schleife laufen.

    Das mag sich anfänglich übel anhören, ist es aber nicht. Je nachdem wie die Event-Callbacks registriert werden deregistrierst du ihn einfach.

    Viele WM-Funktionen werden so in AutoIt realisiert.


    Ein kleines Beispiel findest du z.B. bei meiner GUIScaling-UDF.

    Code
    1. Func _GUI_WM_DPICHANGED($hWnd, $iMsg, $wParam, $lParam)
    2. GUIRegisterMsg($WM_DPICHANGED, "")
    3. Local $tRect = DllStructCreate($tagRECT, $lParam)
    4. _GUI_Resize($hWnd, DllStructGetData($tRect, "Left"), DllStructGetData($tRect, "Top"), _WinAPI_HiWord($wParam))
    5. GUIRegisterMsg($WM_DPICHANGED, _GUI_WM_DPICHANGED)
    6. Return $GUI_RUNDEFMSG
    7. EndFunc


    Wenn das Fenster auf einen anderen Monitor mit unterschiedlicher DPI-gezogen wird, dann wird _GUI_WM_DPICHANGED ausgelöst.

    Innerhalb der Funktion werden die von Windows vorgeschlagenen neuen Koordinaten verwendet um das Fenster zuresizen und zu WinMoven (WinMove passiert in der _GUI_Resize).


    Würde man die WM_DPICHANGED nicht deregistrieren würde das Fenster auf dem neuen Monitor die falsche DPI haben, da das Fenster erst gemoved wird, das DPI-Event nochmal ausgelöst wird, es wird wieder gemoved, resized, und anschließend mit dem ursprünglichen Resizing resized.

    Das ist aber nicht Sinn der Sache, also deregsitrieren wir den Callback, behandeln die DPI-Changed Routine indem das Fenster verschoben und resized wird, so, dass es nicht mehr das DPI-Changed Event auslöst wenn die Nachricht wieder registriert wird, und zu guter letzt wird der Callback dazu wieder registriert.


    Im Kerne möchte ich darauf hinaus: Erlaubt es PSPad innerhalb von Skripten die Callbacks zu registrieren, dann ist der Pluginentwickler vollends selber schuld, denn so schwierig ist das nicht.

    Wird das Callback nur einmal registriert, bzw. über Plugineinstellungen, und man hat im Nachhinein keine Möglichkeit mehr das zu ändern, dann verwendet man einfach Sempaphoren / Mutex.


    Das kann dann in etwa so aussehen.


    So würde die zweite gefeuerte Eventfunktion den Code nicht auslösen, da der Trigger noch gesetzt ist.


    Darf das Plugin die Callbacks zu jeder Zeit selber setzen, und nicht nur im Init oder in den Plugineinstellungen ginge das ganze noch einfacher:

    Zur grundsätzlichen Ebene: Bei mir gibt es keinen Zeit- oder Erfolgsdruck, für mich ist das ein Hobby. Hobbys kosten. In diesem Fall Zeit und Aufwand, den ich gerne investiere und selbst wenns in die Hose geht, genieße ich dennoch die Zeit der Suche und Entwicklung. Das ist fast wie ein guter Krimi. ;) Der Aufwand lohn sich, solange es Spaß macht. Sollte ich Erfolg haben, teile ich das mit anderen, die dann auch was davon haben.

    Das sollte sich grundsätzlich jeder Programmierer mal zu Herzen nehmen. Ich weiß gar nicht wie viele Projekte ich gebastelt habe einfach um das mal gemacht zu haben obwohl es das gleiche in viel besser schon von anderen Entwicklern gibt.

    Realistisch betrachtet wird das PSPad Plugin kaum jemand nutzen, aber der Erfahrungsgewinn dadurch ist enorm groß, einfach weil man programmiert und in dem limitierten Bereich arbeiten muss.


    Da du sowieso keinen Zeit- und Erfolgsdruck hast kannst du einfach nach Lust und Laune dran arbeiten.


    Kein Erfolg mit JScript! Ich krieg nichts ins Laufen. Alles ist mit dem Browser verbunden, den es im Editor nicht gibt. Überall steht "window.setInterval(...)", aber ich weiß nicht, wo ich "window" herbekommen soll.

    Das ist das Browserfenster, du dürfest da auch Zugriff auf document haben und das sind Standardelemente in der Webprogrammierung.


    Wenn die Events eingebaut sind kannst du sicherlich richtig loslegen, die Sorgen, dass ein Skript den Editor zum hängen bringt ist meiner Meinung nach eher Quatsch.

    Denn auch ohne Events kann man den Editor einfach zum Hängen bringen. Wenn man in den Events die Codebereiche synchronisiert bzw. mit Semaphoren oder Mutex, dann wird da auch nichts doppelt ausgeführt oder könnte sich aufhängen.

    habe Commandozeilen probiert und auch von windows direkt mit Hilfe der sndvol.exe (wo ich aber den richtigen Control nicht finde, der den angezeigten wert ausgibt bzw. nicht auslesen kann.)

    Das würde sowieso nicht funktionieren, da der Limiter ja immer auf 100% ist, und nur der grüne Balken auf dem Volume-Slider rumtanzt, der wird aber nachträglich mit ein bisschen GDIPlus-Magie eingefügt (hab sowas ähnliches in meinem Player gemacht).


    Der Player scheint aber ein Plugininterface zu haben, warum erstellst du dir kein Plugin und behandelst das von da aus? Da sitzt du ja direkt im Player drin und kannst so rumfuschen,

    ansonsten fällt mir nur ein extern über MemoryRead oder dergleichen auszulesen in welchem Zustand sich der Player befindet.