Beiträge von Velted

    Moin,


    nach dem GUISetState() braucht es noch etwas Zeit, bis das Fenster im Vordergrund angezeigt wird. Bei mir reicht es, wenn ich dahinter ein WinWaitActive($hGUI) einfüge.


    MfG, Velted

    SWbemServices.ExecQuery() gibt eine SWbemObjectSet Collection zurück, wenn man nicht das Flag wbemFlagForwardOnly setzt. Mit dem Flag soll es nach MS schneller gehen und weniger Speicher verbrauchen, andererseits verfügt die 'normale' Collection über eine Count Eigenschaft, die die Anzahl der Einträge liefert. Damit sollte sich das 'Array-Dim-Gehampel' erübrigen, weil die maximale Anzahl der Einträge feststeht. Wenn Leereinträge übersprungen werden sollen, kann man mitzählen und das Array zum Schluss passend eindampfen.


    AutoIt
        ...    
        $colItems = $objWMIService.ExecQuery("SELECT * FROM Lenovo_BiosSetting", "WQL", _
                    $wbemFlagReturnImmediately) ;  + $wbemFlagForwardOnly)
        MsgBox(0, "Anzahl der Einträge", $colItems.Count)
        ...

    Moin,


    wenn Du nichts Anderes bestimmst, werden Label-Controls mit der Hintergrundfarbe des Fensters gezeichnet.

    Global $GUIBKCOLOR = 0x738599

    Das ist zwar kein Schwarz, erweckt aber beim kurzen Flackern einen recht dunklen Eindruck.

    Wenn Du den Fensterhintergrund auf Weiß setzt, siehst Du den Unterschied.


    Für GUICtrlSetBkColor(-1, $GUI_BKCOLOR_TRANSPARENT) muss AutoIt in den Zeichenprozess eingreifen. Wie das geschieht, bleibt bei "Closed Source" ein Geheimnis.


    Das Folgende funktioniert hier recht gut bei 10 Hz (100 ms);


    Aber ich gehe halt mal davon aus dass das noch ein Bug von Autoit ist und hoffe mal darauf dass es in der nächsten Version behoben sein wird.

    Moin,


    da irrst Du gewaltig. AutoIt verändert zwar den Inhalt der Controls durch das Senden entsprechender Nachrichten, um die Darstellung auf dem Bildschirm kümmert sich aber das System, in diesem Fall höchstwahrscheinlich der Desktop Window Manager (DWM), zusammen mit den vom System bereitgestellten Fensterprozeduren für die Windows Standardcontrols. Man kann das nur durch das setzen von Styles bzw. Exstyles beeinflussen.

    Moin,


    ich habe das mal eingearbeitet. Die IDs der zu behandelnden Inputs werden in der globalen Variablen $sInputs gesammelt. Mit AutoIt 3.3.16 böte sich eine Lösung per Map an.


    Solche 'Komfortfunktionen' machen für mich allerdings nur Sinn, wenn auch bereits bei derEingabe geprüft wird, ob die Daten 'sinnvoll' sind (z.B. Pause-Beginn nach Arbeit-Beginn oder Pause-Ende nach Pause- Beginn oder Pause nicht länger als 10 Stunden oder ...).


    Die Berechnung des 'frühesten Feierabends' ist übrigens nicht korrekt.


    Viel Spaß, Velted

    Moin,


    mal ein Beispiel für das Aufteilen der eingelesenen Daten:

    Moin,


    nach vielem Gegoogle und Ausprobieren habe ich Licht am Ende des Tunnels gefunden. Hilfreich war dabei die Eigenschaft documentMode des HTMLDocuments.


    AHK:

    AHK lädt anfangs ein Objekt mit Kompatibilität zum IE5. Das Meta-Tag "<meta http-equiv=""X-UA-Compatible"" content=""IE=9"">" schaltet ohne weitere Maßnahmen auf Kompatibilität mit IE9 um. Damit wird auch die querySelector() Methode erfolgreich ausgeführt.


    AU3:

    AHK lädt anfangs ein Objekt mit Kompatibilität zum IE8. Das Meta-Tag "<meta http-equiv=""X-UA-Compatible"" content=""IE=9"">" änderte in allen meinen Versuchen nichts daran. Für AU3 führt allerdings ein Eintrag in der Registrierung zum gewünschten Verhalten:

    Code
    HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION\AutoIt3.Exe DWORD: 0x2AF8 (11000)
    bzw. 
    HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION\AutoIt3_x64.Exe DWORD: 0x2AF8 (11000)

    Damit erzeugt AU3 auch ohne das Meta-Tag ein Objekt, das kompatibel mit dem IE11 ist und die Methode querySelector() ebenfalls unterstützt. Experimente mit den Werten 10000 (IE10) und 9000 (IE9) brachten keine Veränderung.

    Anbei eine Vermutung:

    Wennn ich richtig bin gibt es den "main" tag erst mit html5, evtl. kann das autoit objekt damit nicht umkommen, denn das der main-start-tag im header vor dem schließenden head-tag und vor dem body-tag eingefügt wird, sieht für mich falsch aus (<HEAD><META http-equiv=X-UA-Compatible content=IE=9><MAIN></HEAD>).

    Auch wenn man den main-tag später einfügt,landet dieser immer im header.

    Nicht nur die Platzierung des <Main> Tags ist merkwürdig, es fehlen auch die Anführungszeichen bei http-equiv="X-UA-Compatible" und content="IE=9".

    Dann zeig doch mal den funktionerenden AHK-Code


    Bitte sehr:

    Moombas:

    Natürlich. Der Fehler entstand bei meinen vielen Versuchen, das irgendwie zum Laufen zu bringen. Ist korrigiert, ändert aber nichts am Ergebnis.

    Die Schreibweise "<meta http-equiv=""X-UA-Compatible"" content=""IE=9"">" ist nach Doku immer noch zulässig. Ich habe auch schon die Alternativen probiert.


    AspirinJunkie:

    Ja, das funktioniert ja mit AHK. Eine eigene Doku zu htmlfile gibt es nicht. Dahinter verbirgt sich das Webbrowser.Document Objekt. Der erste Kommentar im Code liefert die Beschreibung von w3schools. Auch in AHK funktioniert das aber nur, wenn das <META> Tag gesetzt wird.

    Moin,


    ich versuche gerade, ein AHK-Codeschnipsel nach AutoIt (3.3.16) zu portieren:

    Mit AHK liefert die erste MsgBox folgende Ausgabe

    und die zweite liefert

    Zitat

    Contents lol


    Mit AutoIt sieht die erste Meldung so aus

    und die zweite liefert den Fehler

    Zitat

    "D:\AutoIt_Neu\HTMLDOC\HTMLDOC.au3" (15) : ==> The requested action with this object has failed.:

    MsgBox(0, "InnerText", $oHtmlDoc.querySelector("Main > h3 > em").innerText)

    MsgBox(0, "InnerText", $oHtmlDoc^ ERROR

    ->10:40:39 AutoIt3.exe ended.rc:1


    Was mache ich falsch?

    Moin,


    der führende Unterstrich wurde als Mermal für Funktionen in den UDF-Skripten vereinbart. Funktionen, die dort nur intern genutzt werden sollen, beginnen normalerweise mit zwei Unterstrichen.

    Hi Velted,


    Wenn ich deinen Code in mein Script einsetzte, hängt sich Excel komplett auf.

    Moin,


    das liegt wahrscheinlich daran, dass ich die Befehle aus dem Beitrag #14 von water kopiert habe. So dürfte es besser passen:


    AutoIt
    With $oWorkbook.PublishObjects.Add($xlSourceRange, $Freigabe & "web\" & $Gewerk & ".htm", $Gewerk, "$A$1:$U$40", $xlHtmlStatic, "", "")
        .Publish(True)
        .AutoRepublish = False 
    End With


    Ich habe versucht, ein SKript zu basteln, das ohne die Excel-UDF auskommt. Testen kann ich mangels Excel und Deiner Daten hier nicht. Probier doch mal ob das besser läuft. Beachte dabei die oben im Skript unter Einstellungen vorhandenen Variablen:


    Moin,


    ein paar Gedanken, wobei ich davon ausgehe, dass im Beitrag #19 das komplette Skript steht:


    Hast Du mal den Hinweis von water im Beitrag #8 zu $bForceNew umgesetzt? Dien Skript enthält keinen Aufruf von _Excel_Close() bzw. $oExel.Quit(). Damit bleibt nach Ende des Skripts wahrtscheinlich die Excel-Instanz im Hintergrund aktiv.


    In der Microsoft Dokumentation zu PublishObjects.Add() findet sich ein Beispiel für das, was Du machen willst. Du kannst das nahezu unverändert übernehmen:

    Code
    With $oWorkbook.PublishObjects.Add($xlSourceRange, $oWorkbook.Path & "\web\123.htm", "Polsterei", "$A$1:$U$40", $xlHtmlStatic, "", "")
        .Publish(True) 
        .AutoRepublish = False 
    End With

    Deine zwei Aufrufe der PublishObjects.Add()() Methode erzeugen möglicherweise zwei Objekte.


    Die mehrfache Versorgung von DisplayAlerts bringt meiner Meinung nach nichts. Im Skript wird DisplayAlerts bereits in _Excel_Open() auf False gesetzt. Wenn das an dieser Stelle nicht wirkt, wirkt es auch später nicht. Hast Du in der Excel-Datei vielleicht noch andere Makros, die automatisch ablaufen und sich mit dem Skript 'verhaken' können?