Beiträge von Matricus

    Und natürlich meckert nicht nur der Feuerfuchs, sondern auch der IE 11 unter Windows Threshold.
    Der Spartan Browser von Win10 interessanterweise nicht bei immer den gleichen wie der IE 11.


    Leider lässt sich dies auch nicht auf jeder Seite umgehen (durch hinzufügen/entfernen von www bzw. setzen als trusted page), sondern kann nur einen anderen Browser nutzen der aber womöglich ebenso reagiert.

    Da ich gerade mal ein paar Minuten hatte und den Thread damit auch schließen möchte...
    Zur Optimierung wird nun, wie von Water vorgeschlagen, ein 1D-Array aus einer Spalte des 2D-Arrays erstellt und dieses entsprechend geschrieben.


    Angepasstes Beispiel:


    Vielen Dank für die Hilfe! :)


    Im OnEvent Mode braucht es genau wie im MsgMode eine Endlosschleife um das Skript am Laufen zu halten. Ein einziger Blick in irgendein beliebiges GUI-Bsp. der Hilfe hätte das auch gezeigt.


    Natürlich braucht es eine Endlosschleife, dennoch würde das UI nicht reagieren, wenn das Skript z.B. mit WinWait() "pausiert".


    Und wenn ich mir meinen Text erneut durchlese, sehe ich nicht, an welcher Stelle ich dem widersprochen hätte. :/

    Grundlegend kannst du das Skript bzw. die Funktion in Bezug auf ein Fenster mit WinWaitClose() bzw. WinWait() anhalten, je nachdem ob du darauf wartest das es geschlossen bzw. geöffnet wird.
    Während es wartet ist es jedoch nicht mehr ansprechbar.


    Damit die UIs weiterhin funktionieren, musst du die betreffende Funktion z.B. mit AdlibRegister() aufrufen (und mit AdlibUnRegister() am Ende schließen), sodass der Rest des Skriptes weiterhin ausgeführt werden kann:



    Aber gibt es einen Grund, weshalb du die GUIs in separaten Funktionen erstellst?
    Ich pers. erstelle mit OnEvent alle GUIs zu Beginn und blende diese dann bei Bedarf ein/aus (GuiSetState()); so hast du auch nur deine normale While-Schleife für das Skript, außerhalb einer Funktion.


    Bei einem simplen Skript macht dies zumindest keinen Unterschied in Bezug auf die Ressourcen und ist auf Dauer simpler zu managen.

    Die Excel UDF schreibt immer den kompletten Array nach Excel. Eine Möglichkeit wäre, die Spalte aus Deinem Array mit Hilfe einer der _Array* Funktionen in einen neuen Array zu kopieren und diesen dann an die _Excel_RangeWrite Funktion zu übergeben.


    Guter Einfall, die zu kopierende Spalte einfach in ein neues 1D-Array zu kopieren.
    Werde ich bei Gelegenheit mal versuchen, vielen Dank. :)


    Zitat

    Sieh dir mal Beispiel 4 aus der Hilfe an: autoitscript.com/autoit3/docs/…ons/_Excel_RangeWrite.htm
    Damit sollte es doch egtl funktionieren


    Wie bereits von Water erwähnt, funktioniert dies leider nicht so ganz mit mehreren Werten, außer man übergibt ein komplettes Array.

    Grüße!


    Großes, kleines Projekt, wie es noch einmal so ist. ;)


    Im Moment liebäugle ich damit einen Teil meines Scripts zu optimieren, welches sich mit dem Umsortieren großer Datenmengen in Excel befasst.
    Die Daten stammen aus einem dynamischen 2D-Array.


    Langsamste Stelle im Script ist aktuell das Schreiben einer gesamten Spalte des 2D-Arrays in die (sich ständig ändernde) Excel-Spalte.


    Aktuell schreibt das Skript jede Zeile dieser Spalte manuell in die Datei.
    Vereinfachtes Beispiel:




    Bei steigendem row-count dauert das natürlich entsprechend lange.


    Gibt es eine Möglichkeit, direkt eine bestimmte Array-Spalte oder -Zeile in eine Excel-Spalte/-Zeile zu schreiben, ohne die einzelnen Felder des Arrays per loop durchzugehen?
    Ich dachte daran, vielleicht direkt VBA-Code an das Objekt zu hängen statt die Funktion zu verwenden, aber aus den VBA-Schnipseln innerhalb der RangeWrite-Funktion der UDF werde ich diesbezüglich nicht schlau.


    Vielleicht habt's ihr noch einen spontanen Hinweis.


    Cheerio,
    Matricus

    So etwas kannst du mit StringFormat() realisieren.
    Dort kannst du den übergebenen Wert speziell formatieren, so also auch einer Zahl führende Nullen verpassen.



    ProgressOn("Example", "Formatiere Int via StringFormat")


    For $i=1 To 100 Step 1
    $FileName = StringFormat("%03i", $i) & ".dat" ; 3 stelliger integer, mit führender 0
    ProgressSet($i, $FileName)
    If FileExists(@ScriptDir & "\" & $FileName) Then ExitLoop ; Datei gefunden
    Sleep(75)
    Next
    ProgressOff()


    Ein wahrer Augenöffner, gar keine Frage. ;)
    Danke!


    Erst einmal wieder 'solved', wie zu nächsten Frage. :S

    Irgendwie komme ich mir vor wie ein Grundschüler, der gerade das erste Mal Mathematik Unterricht hat und nichts versteht.
    Ich steig' nicht hinter die Berechnungen von UEZ zur Erfassung des "Siegesfeldes".


    Hier noch mal seine Funktion:


    Floor - Abrunden, Ceiling - Aufrunden ... klar.
    Mod ist schon komplexer - Berechnung des Restes aus einer Division, aber sollte klar sein.


    $iRunden = Floor($ff / 360)
    $iSegment = Mod($iRunden + Ceiling($ff / 15), 25)
    [...]
    If Mod($ff, 15) > 14.45 Or Mod($ff, 15) < 0.55 Then $iSegment = 0
    Meine Frage dazu: Warum teilst du bei Ceiling und später beim Modulos durch 15? Was hat es mit dieser 15 auf sich - da grüble ich jetzt schon' bisschen dran. :S
    Den Zusammenhang verstehe ich nicht ganz.


    Und steht die 25 als Divisor bei der $iSegment-Berechnung für die Anzahl der Felder oder wofür?


    Naja, wenn ich's nicht hinbekomme, mache ich einfach 'ne Color-PixelSearch. :D

    Welche Dynamik fehlt dir denn?


    Naja, zum Bleistift die simple Tatsache, dass es ein Bild ist. Folglich müssen alle Variationen, ob nun Anzahl der Felder oder dessen (visueller) Inhalt als Bild vorhanden sein.


    Das macht eine Dynamik, z.B. das sich die Werte der Felder jede Runde ändern können, quasi unmöglich.


    Meine Berechnung sieht etwas kompliziert aus, aber sollte nicht so schwer sein zu verstehen, da die Kalkulation sich im Prinzip auf 4 Zeilen beschränkt.


    Im Prinzip werden die Rotationen zusammen gezählt und auf das Glücksrad übersetzt. Insgesamt sind es 24 Segmente zu je 15°. Ferner wird noch geprüft, ob der Zeiger auf der "Kippe" steht.


    Wenn man es auf die Tatsachen reduziert, ja, einfach. Es aber logisch zu übernehmen ist wie eine andere Sache.


    Mag' daran liegen, dass ich die jetzige Version in den 2 vorherigen Tagen nach der Arbeit Abends um 22 Uhr zusammengeschustert habe und mein Gehirn einfach schon abgeschalten hat.
    Vielleicht steig' ich ja jetzt durch, wo ich mal 3 Tage am Stück frei habe und nicht immer so im Arbeit-Frei-Wechsel bin. :rolleyes:


    Zitat

    - Anzeige von Werten auf dem Rad, in den Feldern (als Text, nicht als Bild)


    Da ist mir spontan selbst eine Idee gekommen - ja, jetzt wo man frei hat, kann man den Geist auf Wanderschaft schicken :).
    Ich setz' einfach 1 bis 3 labels ein, die am Punkt an dem letztlich der Marker liegt die Werte anzeigen; den aktuellen, sowie den vom vorherigen und nächsten Feld.
    Diese werden dann beim spin auch permanent aktualisiert.


    Ist zwar nicht die optimale Lösung, aber besser als eine Legende oder gar keine Anzeige.


    Wenn jemand 'ne andere oder bessere Idee hat, dann immer her damit. :)

    Ich bin's wieder! ;)


    Ich hab' in der wenigen Freizeit nun mal etwas an dem Projekt gearbeitet und bisher das Zustande gebracht:



    Es ist so aus allen Vorschlägen etwas. :)


    UEZ' Vorschlag war gut, jedoch auf lange Sicht gesehen, nicht dynamisch genug.
    bollens' Vorschlag geht in die Richtung, in die ich es auch jetzt habe.


    Also hab ich anhand euer Vorschläge selbst was gebaut.


    Probleme die ich noch habe:
    - Anzeige von Werten auf dem Rad, in den Feldern (als Text, nicht als Bild)
    - Ermittlung in welchem Feld es stehen geblieben ist (*)


    * Das war bei UEZ' Vorschlag zwar mit drin, aber aus den Berechnungen werde ich nicht ganz schlau. Wenn ich es richtig verstehe, wird einfach errechnet, wie weit es sich gedreht hat und welches Feld dann dort sein müsste, hm?
    Wo die Position zur Ermittlung ist, sei erst einmal dahingestellt.


    Jemand'n Ideechen?

    Hier mal ein Prototyp.


    Dank' Dir! Ich werd' mich am Wochenende mal reinlesen.


    Beim spontanen Überfliegen sehe ich, dass die Beschriftungen auf dem Bild rein zur Darstellung sind, richtig?
    Die tatsächlichen Werte sind in $aFelder gespeichert.


    Zitat

    UEZ nett, aber er hält manchmal (jedes 2te Mal bei mir) auf dem schwarzen Strich, evtl. sollte man dann noch 2-3cm weiter drehen :D


    Kann man ja einbauen, dass es sich automatisch ein Stück weiterdreht. Daran soll es letztlich nun nicht scheitern. ;)


    Zitat

    Es soll nur als Ideengeber dienen, so dass Matricus was zum basteln hat.


    Und das ist es, definitiv! Ich werde mir das, wie gesagt, am Wochenende genauer anschauen und solange drehen, bis ich's Rad nicht mehr sehen kann. :D
    Da muss ich mich zwar wieder ein einiges einlesen, aber learning by doing ist eh der beste Weg für so etwas.


    Vielen Dank für deinen Entwurf!


    Ich setz den Thread erst einmal auf solved. Wenn ich weitere Hilfe brauche, lasse ich es euch wissen. ;)


    <3

    Danke euch beiden soweit! Wie immer schnelle und gute Hilfe. :)


    Ich mach recht wenig mit Grafik, aber zu Glücksrad würden mir als erstes
    _GDIPlus_GraphicsDrawPie und
    _GDIPlus_MatrixRotate
    einfallen. Lies dich da mal ein und probiere die Bsp.


    Mit _GraphicsDrawPie komm ich klar und kann die Abschnitt auch dynamisch berechnen lassen - ist ja nicht sonderlich schwer - aber mit _MatrixRotate komm' ich nicht zurecht.
    Ick schau mal ob ich es nicht noch hinbekomme, aber hab' dafür nach der Arbeit und am Abend kaum noch einen Nerv für. ;)


    Zitat von bollen

    du kannst auch nur die Farben rotieren lassen. Ich hab ein beispiel angehängt, aber erst schauen wenn du selber eine Lösung hast!! sonst hat es ja keinen zweck ;)


    Ich hab reingeschmult - ich bin böse und hab das Geschenk schon vor allen anderen geöffnet. :whistling:
    Bitte nicht verhauen. ^^


    Wenn ich recht sehe, zeichnest du im Skript bei jeder "Rotation" die Felder neu bzw. lässt die Farben einfach aktualisieren/eine Position weiterrücken, sodass ein Rotationseffekt entsteht, hm?
    Jedenfalls eine interessante Methode. :)


    Kann man dazu auch noch Text in die Felder einblenden? Es würde reichen, wenn es am Anfang (vorm Drehen) und am Ende (nach dem Drehen) angezeigt wird.
    Ich würde spontan sagen, dass man zu Beginn bei der Bestimmung der Farben diesen direkt ein label mit abspeichert.


    Aber: Lassen sich labels mit Rotation X anzeigen, sodass man sie am Anfang & Ende in den Feldern mit einblenden kann?


    Edit: Beim Rumdoktorn an deinem Skript bollen ist mir auch aufgefallen, dass der pointer, der letztlich das ausgewählte Feld bestimmt z.B. nicht "zwischen" 2 Feldern sein kann ("knappe Drehungen" usw.), da die Felder ja nicht wirklich rotieren, sondern nur 'weitergereicht' werden.
    Wäre natürlich superb, wenn die tatsächliche Rotation möglich wäre.

    Post aktualisiert! Bitte in diesen Beitrag zur Aktualisierung schauen.


    Hey folks,


    ich beschäftige mich seit langem mal wieder mit AutoIt. Als "Aufwärmübung" wollte ich'n Glücksrad basteln.
    Sprich ein Kreis der sich auf Klick drehen lässt, wobei dieser in Bereiche unterteilt werden kann.


    Kurz um:
    - drehender Kreis
    - Kreis in X Bereiche unterteilbar
    - Fixpunkt um zu ermitteln in welchem Bereich der Fixpunkt nach dem Drehen ist


    Ich dachte dabei natürlich an GDI+ und unter anderem an _GDIPlus_GraphicsDrawArc, aber damit lassen sich innerhalb des Kreisen ja keine Bereiche festlegen.


    Da die Suche nichts hilfreiches ergeben hat die Frage: In welche Richtig sollte ich mich orientieren bzw. welche Funktionen wären hilfreich?
    Speziell um Bereiche zu definieren (die an den Abschnitt gebunden sind) usw.


    Cheers,
    Matricus

    Ich gehe einmal davon aus, dass du ein 64bit Betriebssystem hast du aber eine 32bit Applikation erzeugst.


    Falls dies zutrifft, so leitet Windows deine Anfragen auf Windows- oder Registry Verzeichnisse automatisch auf die 32bit Version um, anstatt, wie es nötig wäre, auf die 64bit Pfade zuzugreifen (Stichwort: Abwärtskompatibilität).
    In der Registry ist das HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\... bzw. \Windows\SysWOW64 bei Verzeichnisanfragen.


    Bei der Registry ist es möglich dies direkt zu umgehen (HKLM64\Software\... - siehe Hilfe), bei Pfaden jedoch nicht.


    Folgende Zeile einfach an den Anfang deines Scriptes setzen, dann sollte die Umleitung für Verzeichniszugriffe für das laufende Programm deaktiviert sein (und du musst nichts am Code ändern):
    DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)

    Das bringt mich doch schon mal weiter, Danke.


    Nun müssen sich die erstellten controls nur noch bewegen lassen, was mit $GUI_WS_EX_Parentdrag kein Problem ist, jedoch bewegt sich dann, logischweise, nur 1 control.
    Wie lasse ich nun diese "controlgruppe" (oder Fenster) sich gemeinsam bewegen als wenn alle im selben Fenster wären?


    Gibt es da eine einfachere Methode als es per Event "nachzuschieben":

    Als Beispiel:


    $ProgrammName = "Test"
    $Pfad = @UserProfileDir
    $DateiName = "Datei.txt"


    If Not FileExists($Pfad & "\" & $ProgrammName & "\" $DateiName) Then DirCreate($Pfad & "\" & $ProgrammName)


    Es wird geprüft ob die Datei "Datei.txt" in %userprofile%\Test vorhanden ist, wenn nicht wird der Ordner (%userprofile%\Test) angelegt.
    Anzumerken sei, dass du mit FileExists auch prüfen kannst ob ein Verzeichnis exisitiert - einfach den Dateinamen und letzten Backslash weglassen.


    %userprofile% entspricht C:\Benutzer\<Benutzername> (Bei XP oder älter wäre es C:\Dokumente und Einstellungen\<Benutzername>
    Der Laufwerksbuchstabe und sowas wird auch automatisch aktualisiert (auf das Windows-Laufwerk, was ja für gewöhnlich C: ist)
    Für mehr "Pfadmakros", wirf einen Blick in die Hilfedatei unter Makros.


    @ScriptDir entspricht z.B. dem aktuellen Pfad indem die .exe liegt.

    Heyho,


    um es einem anderen Programm zu ermöglichen ein Fenster eines meiner Programme zu erfassen, welches transparent sein soll (nur controls sichtbar), darf dieses transparente Fenster nicht den Windows-Layered Stil verwenden, da es sonst für das Programm nicht "sichtbar" ist.


    Gibt es eine Möglichkeit ein transparentes Fenster ohne $WS_EX_LAYERED zu erstellen?
    GDI+ verwendet ja ebenfalls ein layered Fenster, jedenfalls soweit ich das gesehen habe.


    Entsprechender Code-Auszug:

    Schön das du dir zu helfen weist, geht aber viel einfacher ;)


    $cBG = GUICtrlCreatePic($path, 0, 0, 253, 149)
    GUICtrlSetState(-1, $GUI_DISABLE)


    Durch das $GUI_DISABLE sollten die Events ganz normal empfangen werden :)


    *-*
    Das ich auf solch eine einfache Lösung nicht komme... Ist aber immer so, ich denke zu kompliziert. ;)


    Vielen Dank dafür, funktioniert!

    Okay, die Lösung war einfacher als gedacht.


    Das Script hat, so wie es gedacht war, schon funktioniert, nur seltsamerweise hat das "Hintergrundbild", die Splash Art, die Controls beim klicken überlagert, sodass keine Events empfangen wurden.
    Als ich nun das Image Control als letztes deklariert habe, funktionierten die Events wie gewünscht, nur mit dem Fehler, dass die Controls nun tatsächlich hinter dem Bild waren (nicht sicht- aber anklickbar).


    Als Lösung dafür: 2 GUIs erstellt (parent & child), eines für den Hintergrund, das andere als overlay für die controls.
    Etwas umständlicher, wird aber funktionieren...