Beiträge von alpines

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):

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.

Zitat von Gun-Food

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?

Such einfach nach Beispielcode der in C++ geschrieben ist, den könntest du als DllCall implementieren. Allerdings ist C++ m. E. n. schwieriger als C#.

Persönlich würde ich den Weg über einen C# Wrapper gehen.

Für Skype for Business scheint es eine App SDK zu geben, und für Lync gibts sogar schon Posts in den msdn Foren: https://social.msdn.microsoft.com/Forums/lync/en…communicatorsdk

Am besten suchst du einfach nach funktionierendem C# Code, oder schreibst ihn selber und bietest die als gewrappte DLL an wenn du unbedingt aus AutoIt das ganze machen möchtest.

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)

pasted-from-clipboard.png

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

div.boxesContentBottom {
    margin-top: 30px;
}

div.content {
    margin-top: -30px;
}

div.contentHeaderTitle {
    display: none;
}

div.pageNavigation {
    display: none;
}

time.datetime {
    opacity: 100;
}

.shoutboxContent {
    height: 307px;
}

.shoutboxEntry {
    padding: 0px;
}

.shoutbox {
    margin-top: -10px;
    background-color: #ECF1F7;
}

.containerContent, .htmlContent, .userMessage {
    margin: 0px;
}

.shoutboxContentFooter {
    margin: 0px;
}

.shoutboxContent, .fadeOut {
    padding-top: 0px;
    padding-left: 10px;
    padding-bottom: 0px;
}

.shoutboxContentFooterActions, .before {
    width: 0px;
}

Zitat von Professor Bernd

Oh je. Dennoch danke für deine Deutung. Ich will aber auch nicht zu sehr nachhaken, denn er hat bei andere Sachen Hilfe angeboten.

Setz es einfach auf die Liste. Ist ja eher nebensächlich, Hauptsache der Kern steht erstmal.

Zitat von Professor Bernd

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.

Zitat von Professor Bernd

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.

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.

Zitat von Professor Bernd

aber leider funktioniert der Hotkey "Crtl+Break" nicht in PSPad

Vielleicht ist der Hotkey bereits von PSPad gesetzt?

Zitat von Professor Bernd

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:

Zitat

>"C:\Program Files (x86)\AutoIt3\SciTE\..\AutoIt3.exe" "C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "C:\Users\GIGABYTE\Desktop\Joypad.au3" /UserParams

+>21:04:16 Starting AutoIt3Wrapper v.19.102.1901.0 SciTE v.4.1.2.0 Keyboard:00000407 OS:WIN_7/Service Pack 1 CPU:X64 OS:X64 Environment(Language:0407) CodePage:0 utf8.auto.check:4

+> SciTEDir => C:\Program Files (x86)\AutoIt3\SciTE UserDir => C:\Users\GIGABYTE\AppData\Local\AutoIt v3\SciTE\AutoIt3Wrapper SCITE_USERHOME => C:\Users\GIGABYTE\AppData\Local\AutoIt v3\SciTE

>Running AU3Check (3.3.14.5) from:C:\Program Files (x86)\AutoIt3 input:C:\Users\GIGABYTE\Desktop\Joypad.au3

+>21:04:16 AU3Check ended.rc:0

>Running:(3.3.14.5):C:\Program Files (x86)\AutoIt3\autoit3.exe "C:\Users\GIGABYTE\Desktop\Joypad.au3"

+>Setting Hotkeys...--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop

+>21:04:18 AutoIt3.exe ended.rc:0

+>21:04:18 AutoIt3Wrapper Finished.

>Exit code: 0 Time: 1.975

Alles anzeigen

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/questions/7486…s-id-on-windows

Zitat von Professor Bernd

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

Zitat von Professor Bernd

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/autoit3/docs/f…hellExecute.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.

Zitat von Professor Bernd

Fehlt nur noch eine Idee, wie ich die Ausführung des AutoIt-Scripts abbreche.

ProcessClose?

Du spawnst doch die neuen Skripte, und die haben alle unterschiedliche ProcessIDs. ProcessClose erlaubt es auch direkt PIDs abzuschießen.

Zitat von Professor Bernd

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.

Func _GUI_WM_DPICHANGED($hWnd, $iMsg, $wParam, $lParam)
    GUIRegisterMsg($WM_DPICHANGED, "")

    Local $tRect = DllStructCreate($tagRECT, $lParam)
    _GUI_Resize($hWnd, DllStructGetData($tRect, "Left"), DllStructGetData($tRect, "Top"), _WinAPI_HiWord($wParam))

    GUIRegisterMsg($WM_DPICHANGED, _GUI_WM_DPICHANGED)

    Return $GUI_RUNDEFMSG
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.

global boolean selChangedEventRunnning = false;

init {
    registerCallback("editorSelectionChanged", editorSelectionChangedCallback);
}

editorSelectionChangedCallback {
    if (Not selChangedEventRunning) {
        selChangedEventRunning = true;

        ;do stuff

        selChangedEventRunning = false;
    }
}

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:

init {
    registerCallback("editorSelectionChanged", editorSelectionChangedCallback);
}

editorSelectionChangedCallback {
    deregisterCallback("editorSelectionChanged", editorSelectionChangedCallback);

    ;do stuff

    registerCallback("editorSelectionChanged", editorSelectionChangedCallback);
}

Zitat von Professor Bernd

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.

Zitat von Professor Bernd

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.

Dein Pattern ist auch nicht ganz richtig. Du suchst nach allen was kein + ist und einem Zeichen was keine Ziffer ist. Allerdings in Kombination hintereinander, du willst aber alles außer einem + und Zahlen matchen.

Das wäre dann [^+\d] https://regex101.com/r/r7RMwL/1

Zitat von Aelc

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.

Zitat von Aelc

Ich meine ich muss ja trotzdem für jeden Control die $GUI_DOCKs definieren oder sehe ich das falsch?

Das musst du nur wenn du Custom-Resizing der Controls unterstützen möchtest. Also bspw. wenn du eine große Editbox hast und daneben eine weitere Editbox obwohl die rechte die Breite behalten und nur in der Höhe wachsen soll wenn du das Fenster verziehst, und die linke sowohl in der Breite als auch Höhe mitwachsen soll. Wenn du das nicht setzt, dann wachsen die Controls alle proportional.

Zitat von Aelc

Auf jeden Fall ist der adjust bei button3 nicht 100%ig, wie ich das sehen konnte. Beim resizen ist der dann irgendwann etwas breiter als der edit darüber, wobei es geringfügig ist und ich schwierigkeiten sehe das einzudämmen.

Das ist leider von OS zu OS unterschiedlich, da Win10 harte Kanten verwendet, und Win7 beispielsweise runde Kanten, bzw. das ganze fadet. Ich hab versucht das so genau wie möglich zu machen, aber auch da sind mir die Hände gebunden wenn es bspw. zu Rundungsfehlern kommt.

Vielleicht kriegst du den Entwickler ja dazu genötigt einen rudimentären Timer einzubauen, dann kannst du mit der Version in der Beta arbeiten und wenn er die Zeit hat und das fertig gebastelt hat pusht er das ganze als Release.

Die letzte Version ist vom Februar 2019, also wird ja daran noch mehr oder weniger aktiv gearbeitet und so viel Arbeit sollte das ja auch nicht sein, einfach eine Option anbieten, alle x Sekunden eine Funktion zu callen.

Wenns mit JScript klappt kannst du ja stattdessen damit weiterarbeiten, ich denke da nimmt sich nicht viel zwischen den Sprachen.

Wärs Open-Source hättest du das selber machen können, aber so wie ich das sehe ist das nicht Open-Source.

Andere Idee: Kannst du die Skriptinstanz/-umgebung an ein anderes Script weitergeben? Also ein vbScript extern ausführen aber noch auf die Editorfunktionen zugreifen?