Beiträge von BugFix

  • Unterstützung für AutoIT Script

    Zitat von shitgettinserious

    wenn ich das Dropdown Menü bediene, die Daten im gleichen Fenster neben dem Dropdown Menü erscheinen.

    Die simpelste Variante:

    Besser geeignet wäre aber staat Combo & Anzeige-Control ein Listview.

  • _GUICtrlListView_SetColumnWidth() - keine Funktion bei Aufruf mit Array-Variabel

    Es gibt häufig Probleme, wenn ein mit nativer Funktion erstelltes Control in UDF genutzt werden soll, da diese in der Regel ein Handle statt einer ID erwarten.

    _GuiCtrlListViewSetColumnWidth switcht und ruft bei Übergabe eines Handle _SendMessage($hWnd, $LVM_SETCOLUMNWIDTH, $iCol, $iWidth) und bei Übergabe einer ID GUICtrlSendMsg($hWnd, $LVM_SETCOLUMNWIDTH, $iCol, $iWidth) auf.

    Somit sollte das in beiden Fällen funktionieren. - Aber versuche es doch mal mit

    _GUICtrlListView_SetColumnWidth(GUICtrlGetHandle($ListView_Overview), ... )

  • Interessanter Artikel von Wolfgang Thierse

    Wegen diesem Artikel wurde er von Linken, Grünen und Teilen der SPD angefeindet, u.a. wegen dieser Passage

    Zitat

    Die eigene Betroffenheit, das subjektive Erleben sollen und dürfen nicht das begründende Argument ersetzen. Biografische Prägungen – und seien sie noch so bitter – dürfen nicht als Vorwand dafür dienen, unsympathische, gegenteilige Ansichten zu diskreditieren und aus dem Diskurs auszuschließen. Opfer sind unbedingt zu hören, aber sie haben nicht per se recht und sollten auch nicht selbst Recht sprechen und den Diskurs entscheiden.

    Wie kann es denn sein, dass Opfer nicht per se Recht haben - das wurde doch in der #metoo Debatte als Standard definiert. :Face:

    Ich bin knapp 60 und mit meinen Lebenserfahrungen kann ich sagen: Der Mann spricht mir aus der Seele.

    Dieser inflationäre Gebrauch von * etc. ist bisher nicht offizieller Bestandteil deutscher Rechtschreibung und Grammatik. Deshalb hat die neue Ausgabe des Duden völlig zu Recht viel Kritik geerntet, da dort diese Schreibweisen als Regel aufgeführt sind.

    Ich kann nur für mich sprechen, aber wenn ich z. B. in einem Hörsaal vor Frauen und Männern stehe, diese alle ansehe und dann mit "Studenten" anrede, impliziert das für mich, dass sowohl Studenten weiblichen als auch männlichen (und auch sonstigen) Geschlechts gemeint sind.

    Sprache ist etwas Lebendiges, und wenn Änderungen den Menschen sinnvoll erscheinen und diese sich vor Allem beim Sprechen "richtig" anfühlen, dann werden diese auch übernommen.

    Alles andere ist Doktrin und einer Demokratie unwürdig.

  • AutoItSimpleObjects - Objektorientierung in AutoIt

    SEuBo

    Eine Bitte:

    Deklariere alle Variablen. Ich vermute, dass das Abstürzen damit zusammenhängt.

    Lass einfach mal mein Prüfskript drüberlaufen um alle nicht deklarierten Variablen zu finden.

    EDIT

    Da habe ich jetzt aber das falsche skript eingestellt (man wird alt). Dieses zeigt dir ja nur (un)genutzte Variablen.

    Das Skript, welches ich meinte, war "SetVarsDeclared". Da es aber von 2014 ist, werde ich das erst nochmal anschauen. Zumal es auch ein AutoIt-Skript ist. Für diesen Zweck ist Lua geeigneter.


    Kannst du in SciTE so einbinden (Pfade anpassen):

    Code
    # 39 Unused Vars 
command.39.*.au3="$(autoit3dir)\autoit3.exe" "C:\CODE\AutoIt\TEST\GetUnusedVars.au3" "$(FilePath)" "0" "1"
command.name.39.*.au3=GetUnusedVars
command.save.before.39.*.au3=1
command.is.filter.39.*.au3=1
command.shortcut.39.*.au3=Ctrl+Shift+Alt+U
command.mode.39.*=subsystem:1

    Dazu brauchst du die:

  • AutoItSimpleObjects - Objektorientierung in AutoIt

    Zitat von Professor Bernd

    Wenn nicht für GUI Elemente, wofür würdest du Objekte vorrangig haben wollen? :)

    Ich finde es schon interessant, das für GUI zu nutzen. Letztlich kann man es ja für alles nutzen. Aber wir brauchen ja erst mal die Basis, die das kann. Du tapezierst ja auch nicht, bevor du die Wände gemauert hast. 8o


    EDIT:

    Hier mal ein ganz minimalistisches Bsp. um mit ASO und GUI zu arbeiten:

  • AutoItSimpleObjects - Objektorientierung in AutoIt

    SEuBo

    Ich habe mit dem DL aus Post1 getestet.

    Was ich nicht ganz verstehe:

    Im 2.ten Bsp. möchte ich als Parameter die Property eines anderen Objekts übergeben, das geht daneben.

    Da hatte ich mich vertan - funktioniert

    Test
    Code
    ; fehlende Deklarationen
; in "AutoItObject_internal.au3" - Func: "Invoke" - "$b", "$pVARIANT_Getter" und "$tVariantSource"
;                                - Func: "__AOI_PropertyGetFromName" - "$tProperty", "$sPropertyName"
;                                - Func: "__AOI_PropertyCreate" - "$tProperty", "$sPropertyName"

Das sind die, die ich bemerkt hatte. Danach habe ich die Option (MustDeclareVars) deaktiviert.


    EDIT:

    Aber Verkettung scheint so nicht machbar.

    Die Methoden reichen ja beim Verlassen die Objektreferenz weiter. Eigentlich sollte doch somit die Folgemethode aufgerufen werden können.

  • AutoItSimpleObjects - Objektorientierung in AutoIt

    Zitat von Professor Bernd

    Mir ist gerade ein Paradebeispiel über den Weg gelaufen: Die CheckBox.

    Für die CheckBox muss man sich verschiedene Funktionen zusammensuchen, die einem nicht so richtig intuitiv einfallen (zumindes mir nicht). 8o

    GUICtrlSetState() Häkchen setzen/entfernen.
    GUICtrlGetState()
    GUICtrlRead()    		 Prüfen, ob das Häkchen gesetzt ist.
    GUICtrlSetData() Text zuweisen.
    GUICtrlGetData()
    GUICtrlRead() mit advanced = 1    		 Text auslesen.


    Bei einem Objekt und dessen Eigenschaften würde ich mir das so vorstellen:

    CheckBox1.Checked = True/False Häkchen setzen/entfernen.
    If CheckBox1.Checked Then Prüfen, ob das Häkchen gesetzt ist.
    CheckBox1.Text = "Hallo Welt!" Text zuweisen.
    $sChkText = CheckBox1.Text Text auslesen.

    Vielleicht sieht das mancher anders, aber ich finde das total easy und eingängig. :)

    Das wäre ja dann eine Portierung von GUI Funktionen in ein Objekt. Das kannst du natürlich selbst durchführen und ist in deiner beschriebenen Form ja möglich.

    SEuBo geht es ja darum, was das Objekt als Solches sonst so können sollte. Die Implementierung von GUI etc. ist ja absolut unproblematisch und es liegt dann an dir, wie du das in deiner Variante umsetzt

  • Umgebungsvariablen

    Das Thema ist nicht AutoIt spezifisch, sondern generell sehr unklar.

    Ich wollte (hier) durch Setzen von Umgebungsvariablen (SCITE_USERHOME) unterschiedliche Pfade bereitstellen zum Starten verschiedener SciTE-Versionen.

    Das war meine erste intensivere Beschäftigung mit Umgebungsvariablen (bisher hatte ich diese ausschließlich abgefragt). Nun wollte ich diese aber setzen.

    Ergebnis:

    Die geänderten Variablen haben den neuen Wert nur im direkten Kontext des Änderungsprogrammes. D.h.

    VARIABLE Wert: "Alter-Wert"

    - Öffnen 1. Konsole

    set VARIABLE=Neuer-Wert

    - Abfrage in 1. Konsole: set VARIABLE -- Ausgabe: VARIABLE=Neuer-Wert

    - parallel Öffnen 2. Konsole

    - Abfrage in 2. Konsole: set VARIABLE -- Ausgabe: VARIABLE=Alter-Wert

    In AutoIt ist das analog.

    EnvSet("Variable", Wert)

    EnvUpdate()

    EnvGet("Variable")  zeigt den neuen Wert, Abfrage über die CMD bringt aber wieder den alten Wert.

    Wie also werden von Windows diese Variablen gesetzt? Denn wenn ich das händisch über <Systemeigenschaften> <Umgebungsvariablen> durchführe ist es ja möglich.

    :?:

  • AutoItSimpleObjects - Objektorientierung in AutoIt

    Zitat von SEuBo

    5. Was brauche ich von Euch?

    Anwendungsfälle, Ideen, Feedback.

    Mal ins Blaue gedacht: Wofür würdet Ihr OO- benutzen? Sind Dinge wie Interfaces, Klassen, Traits, ByRef-Paramter, usw. für Euch unabdingbar bzw. was wäre Funktionalität, die Ihr nicht braucht?

    Ist die UDF einfach genug - oder zu einfach gehalten? Sind die Syntaxmöglichkeiten in AutoIt ausreichend?

    Ich hatte vor Jahren mit AutoIt-Object mal die String- und später Teile der GUI-Funktionen in Objektform dargestellt. (Link)

    Für GUI mit vielen gleichartigen Control ist eine Methode .Clone natürlich fein. Aber das ist natürlich in erster Linie Syntactic Sugar.

    Aber sicherlich ist eine Portierung der AutoIt-Funktionen nicht das Ziel.

    Wofür also ist OOP wünschenswert?

    Das kann ich ad hoc gar nicht mal sagen. Was ich in AutoIt prozedural programmiere mache ich z.B. in Nim mit OO. Die Sprache bietet es an, also nutze ich es - schon allein wegen der angenehmeren Syntax.

    Achja, was ich angenehm finde (denn das stört mich bei AutoIt):

    Die Parameter in Methoden sollten über ihren Namen angesprochen werden können. Also wenn ich z.B. habe

    Method(Param1=Default, Param2=Default, Param3) ,

    rufe ich auf mit

    .Method(Param3=Wert3)

    statt

    .Method(Default, Default, Wert3).

  • Installation mehrerer SciTE-Versionen

    [EDIT] Kommando zurück:

    Autoit kann ja gar nicht Systemvariablen setzen. Es wird das gewählte SciTE gestartet, aber wenn ich eine Abfrage der Umgebungsvariable mache, bleibt die gleich.

    Muss wohl auf CMD-Ebene ausgeführt werden - mal testen.

    [EDIT 2]

    Umgebungsvariablen scheinen ein Ding für sich zu sein:

    Der AutoIt-Befehl EnvSet beeinflusst sie nicht, damit kann man nur eigene (Laufzeit-Umgebungsvariablen) erstellen.

    Ausführen in der CMD: set VAR=Neuer_Wert ist erfolgreich.

    Ausführen in AutoIt: Run(@ComSpec & " /c " & 'set VAR=Neuer_Wert', '', @SW_HIDE) wird ignoriert.

    Muss ich dafür echt eine Batch Datei verwenden? :Face:


    Ich habe es jetzt mit einem Launcher gelöst:

    Verknüpfung auf dem Screen zu:

    - C:\Launcher\SciTELaunch.exe "4.4.6" - startet SciTE v4.4.6

    - C:\Launcher\SciTELaunch.exe - startet SciTE4AutoIt

    Ini-Datei im Launcherordner:

    Code: SciTELaunch.ini
    [Scite_UserHome]
AutoIt=%LOCALAPPDATA%\AutoIt v3\SciTE
4.4.6=C:\Scite446

[Run]
AutoIt=C:\Program Files (x86)\AutoIt3\SciTE\SciTE.exe
4.4.6=C:\Scite446\SciTE.exe

    Die andere SciTE-Version habe ich bewusst nicht im Programmordner installiert, damit ich die dortigen Property-Dateien auch bearbeiten kann.

  • Installation mehrerer SciTE-Versionen

    Bitnugger

    Das nützt leider nur bei Projekten etwas, da die Hierarchie nur eine Ordnerebene erlaubt. Ausschließlich die SciTEUser.properties sind allgemein gültig.

    Alternativ müsste ich dann in jedem Skriptordner eine SciTEDirectory.properties erstellen mit dem Inhalt der SciTEUser.properties. Obwohl, das könnte man ja ohne Verwendung von Speicherplatz per Link regeln.

  • Installation mehrerer SciTE-Versionen

    Ach stimmt, da wird ja (leider) eine Umgebungsvariable gesetzt. Und die zuletzt installierte Version prüft: Variable gesetzt - OK, alles gut - dann nehmen wir den Pfad. So ein Mist.

    Ich trauere noch immer den Zeiten nach, als sämtliche Settings im Programmordner selbst abgelegt wurden.

    OK, mal sehen ob das was Brauchbares wird. Ansonsten bleibt nur der Umweg über zweiten Windows-User oder VM.

  • Installation mehrerer SciTE-Versionen

    Ich würde gern neben der Installation von SciTE4AutoIt auch die jeweils aktuelle SciTE-Version installieren. Es gibt jedoch ein Problem, für das ich noch keine Lösung habe.

    Egal welche SciTE-Variante: "SciTEUser.properties" wird immer aus C:\Users\USER\AppData\Local geladen. Egal in welchem Unterordner sich die Datei befindet. Das bedeutet, dass z.B. auch das "normale" SciTE sofort nach seiner Installation auf die im Unterordner ..\AppData\Local\AutoIt v3\SciTE vorhandene SciTEUser.properties zugreift.

    Meine Überlegungen waren jetzt

    1. ein Menü zum Aufruf der jeweiligen SciTE-Variante, beim Start wird die gewünschte SciTEUser.properties aktiviert (durch Umbenennen)

    Nachteil: Aufrufe müssen ausschliesslich über das Menü erfolgen

    2. Überwachung der SciTEUser.properties auf Zugriff (die Datei ist dann eine Leerdatei), Abfragen welches SciTE Zugriff haben will und Weiterleitung zur zugehörigen SciTEUser.properties

    Da fehlt mir momentan aber noch der Ansatz zur Realisierung

    Hat jemand von euch schon mal vergleichbares gemacht?


    P.S.

    Ich habe in meiner VM mal die SciTE4Autoit Version 4.2.0_2019-09-03 installiert. Wenn ich mich recht erinnere, sollte doch in der aktuellen Version durch die Option create.hidden.console=1 das Aufpoppen des CMD-Fensters unterdrückt werden. Funktioniert das bei jemandem? - Bei mir tut sich da nichts.