Beiträge von GML

>

Könnte es sein das dieses (Fehl)Verhalten darin begründet ist das ich kein xlsx sondern ein xlsm aufmache (die zweite Excel-Datei die ich aufmache ist dann wieder ein xlsx)?

<

Hab ich gerade probiert. Das .xlsm als .xlsx gespeichert (brauch die Makros nicht), die Funktion _Excel_BookClose($oWorkbook, False) funktioniert wie gedacht und gewünscht.

D.h. die Excel-Datei läßt sich ohne Probleme - ohne speichern - schließen. Es scheint als ob Excel.au3 da einen kleinen Fehler hat.

Nein, das Makro in der Excel-Datei hat keinen Fehler, das funktioniert einwandfrei.

Grüsse

LG

PS: auch der Parameter für _Excel_Open ( [$bVisible = False) funktioniert mit .xlsm nicht, genauso wie der Parameter $bScreenupdating der auch ignoriert wird.

ProcessClose ist relativ brutal tät ich gerne vermeiden, da Excel nochmal aufmachen wieder Zeit kostet.

>

Was ist der Wert von @error und @extended nach _Excel_BookClose?

<

beides 0.

Könnte es sein das dieses (Fehl)Verhalten darin begründet ist das ich kein xlsx sondern ein xlsm aufmache (die zweite Excel-Datei die ich aufmache ist dann wieder ein xlsx)?

Grüsse

LG

Ich verwende AutoIt 3.3.14.5 und Ms-Office Standard 2016

Was mache ich:

Excel starten

$hReport = _Excel_Open(Default, Default, False, Default, True)

Excel-Datei readonly öffnen:

$oWorkbook = _excel_bookopen($hReport, "Exceltest.xlsx", True)

Arbeitsblatt ___Teile____ aktiv setzen

$oWorkbook.WorkSheets("___Teile____").Activate

mögliche gesetzte Filter zurücksetzen

_Excel_FilterSet($oWorkbook, Default, Default, 0)

Filter setzen auf Spalte 6 <> blank

_Excel_FilterSet($oWorkbook, "___Teile____", Default, 6, "<>")

gefilterten Bereich verarbeiten, in Array schreiben usw. funktioniert alles einwandfrei 

Excel-Datei schließen ohne speichern (funktioniert einfach nicht

_Excel_BookClose($oWorkbook, False)

Excel selber wird nicht geschlossen, da danach noch eine andere Excel-Datei geladen und verarbeitet

wird, das funktioniert einwandfrei, ich ändere aber in der Exceldatei auch nichts.

Excel-Datei schließen:

Warum kommt hier trotz "False" - nicht speichern - immer die Aufforderung "Speichern: Ja/nein" von Excel?

Das Skript pausiert natürlich an der Stelle bis das beantwortet wird.

Danke an alle die darüber nachdenken

LG

Danke, das wäre wirklich zuviel Aufwand.

Eine andere Möglichkeit habe ich noch im englischen Forum gefunden (allerdings ohne Zustandsspeicherung, also entweder eingeklappt oder ausgeklappt starten):

For the opening of scripts to be folded by default, then add this into your User Options file and save.

(Originalbeitrag)

# Folding
# enable folding, and show lines below when collapsed.
fold=1
fold.compact=1
fold.flags=16
fold.symbols=2
fold.on.open=1
fold.comment=1
fold.preprocessor=1

Ich habe bin aber offensichtlich nicht in der Lage das zu finden ...

Gibt es eine Möglichkeit SciTE so einzustellen, das

#Region

.

.

#EndRegion

Zustände - auf- oder zugeklappt - beim Öffnen/Speichern/kompilieren wiederhergestellt werden wie ich sie auf-/oder zugeklappt hatte?

Vielleicht weiß das jemand und kann mich erleuchten.

Danke

LG

Gelöst!

Mittels eines Beitrages aus dem englischen AutoIt-Forum. Voraussetzung ist ein GUI (kann auch ein Dummy sein, bzw. ein unsichtbares Fenster).

#include <WinAPIProc.au3>
#include <WinAPI.au3>
#include <WinAPISys.au3>
#include <Array.au3>
#include <GUIConstants.au3>
#include <APISysConstants.au3>

Global $hGUI = GUICreate("GUI")
GUISetState(@SW_SHOW, $hGUI)

GUIRegisterMsg(_WinAPI_RegisterWindowMessage('SHELLHOOK'), 'WM_SHELLHOOK')
_WinAPI_RegisterShellHookWindow($hGUI)

Run("notepad.exe")

Local $nMsg=0
While 1
    $nMsg = GUIGetMsg()
    Select
        Case $nMsg = $GUI_EVENT_CLOSE
            ExitLoop
    EndSelect
WEnd
_WinAPI_DeregisterShellHookWindow($hGUI)
Exit

Func WM_SHELLHOOK($hWnd, $iMsg, $wParam, $lParam)
    #forceref $iMsg
    Switch $wParam
        Case $HSHELL_WINDOWDESTROYED
            ConsoleWrite('Destroyed: ' & @CRLF & _
                    @TAB & 'PID: ' & WinGetProcess($lParam) & @CRLF & _ ; This will be -1.
                    @TAB & 'ClassName: ' & _WinAPI_GetClassName($lParam) & @CRLF & _ ; This will be empty.
                    @TAB & 'hWnd: ' & $lParam & @CRLF) ; This will be the handle of the window closed.
        Case $HSHELL_WINDOWCREATED
            ConsoleWrite('Created: ' & @CRLF & _
                    @TAB & 'PID: ' & WinGetProcess($lParam) & @CRLF & _
                    @TAB & 'ClassName: ' & _WinAPI_GetClassName($lParam) & @CRLF & _
                    @TAB & 'hWnd: ' & $lParam & @CRLF) ; This will be the handle of the window closed.
    EndSwitch
EndFunc   ;==>WM_SHELLHOOK

Bei den Case-Abfragen in WM_SHELLHOOK kann man dann weitere Fensterabfragen/-behandlungen einbauen.

Grüsse

LG

Guten Morgen

Danke!

Das mit der zweiten Datei war der entscheidende Hinweis. Wußte nicht wie ich eine selbstüberwachendes

Programm realisieren könnte, da ja ein externes Programm zum Ausdruck aufgerufen wird.

LG

Vielleicht zum besseren Verständnis (meines Unverständnisses )

#include <MsgBoxConstants.au3>    ; div. Warnzeichen für MsgBox
#include <Dialogue.au3>           ; Options-Dialog (PAL-UDF)

local $ausdruck1 = "c:\temp\00. ungeschützt.pdf"    ; ein "normales" PDF
local $ausdruck2 = "c:\temp\00. geschützt.pdf"      ; ein PDF mit Kennwortschutz der den Ausdruck nicht erlaubt

$iOption = _MessageBox("Druckerauswahl","Make a choice",0,"SumatraPDF","FoxitReader")
if $iOption = 0 then
    exit
ElseIf $iOption = 1 then
    $sPdfDrucker = "c:\sumatra\SumatraPDF.exe "
    $PdfOpt = "-print-to-default "
elseif $iOption = 2 then
    $sPdfDrucker = "C:\Program Files (x86)\Foxit Software\Foxit Reader\FoxitReader.exe "
    $PdfOpt = "/p "
endif

; ShellExecuteWait ( "filename" [, "parameters" [, "workingdir" [, "verb" [, showflag]]]] )
$ergebnis = ShellExecuteWait($sPdfDrucker, $PdfOpt & chr(34) & $ausdruck1 & chr(34), @WorkingDir, "", @SW_HIDE)
; mit SumatraPDF bekomme ich den Rückgabewert 0
msgbox($MB_ICONINFORMATION, "Debug","Dokument 1 ungeschützt (return 0)" & $ergebnis)
$ergebnis = ShellExecuteWait($sPdfDrucker, $PdfOpt & chr(34) & $ausdruck2 & chr(34), @WorkingDir, "", @SW_HIDE)
; mit SumatraPDF bekomme ich den Rückgabewert 1 (da die Datei Passwortgeschützt/Ausdruck nicht erlaubt ist), ABER den
; sehe ich erst wenn ich die Messagebox von SumatraPDF bestätigt habe
; (das Script pausiert an dieser Stelle wg. shellexecutewait) und genau um die Bestätigung dieses
; Meldefensters geht es mir.
; Wie kann ich vor dem Ausdruck in meinem Programm einen handler installieren, der mir das Auftauchen solcher
; Meldefenster überwacht und gegebenenfalls bestätigt damit der Ausdruck in der Nacht weiterläuft??
; Das diese Datei nicht gedruckt wurde, sehe ich dann in der Log-Datei die mitgeführt wird.
; Zum Zeitpunkt des Druckens ist mir das egal, wichtig ist nur das der Ausdruck in so einem Fall fortgesetzt wird.
msgbox($MB_ICONINFORMATION,"Debug", "Dokument 2 geschützt (return 1)" & $ergebnis)

exit

Sorry für den hölzernen Code, ist nur ein schnelles Bespiel zum probieren.

Danke im Voraus für alle die mich erleuchten.

LG

Hallo

Vielleicht kann mir jemand die grundsätzlich mögliche Vorgangsweise erläutern .. auch ob sowas überhaupt geht.

Mit meinem Programm kann ich einen ganzen Verzeichniszweig ausdrucken. Jeder Verzeichniswechsel erzeugt einen Ausdruck auf andersfärbiges Papier aus einem zweiten Schacht.

Beim Programmstart wird das Start-Verzeichnis in ein Array eingelesen und dann abgearbeitet. Soweit so gut, funktioniert auch gut mit xls, doc, pdf, jpg, gif usw..

Hier im Prinzip:

verzeichnis rekursiv in array schreiben

do while 1 to verzeichnisarray_letzter_Eintrag
   falls neues Verzeichnis -> zwischenblattdruck
       +1 zeile im Array
   falls Verzeichnis -> loop, andernfalls
       ausdruck mit shellexecutewait("sumatrapdf.exe" ...)
   +1 zeile im Array (für nächste datei oder verzeichnis)
enddo verzeichnisarray

* EOF

Wie muß ich vorgehen um Meldungen (= Meldungsfenster wie "Im Batchmodus können keine PDF/a gedruckt werden" o.ä.) vom shellexecutierten Programm (aka SumatraPDF) abzufragen, die auftauchen KÖNNEN aber nicht mÜSSEN, (zwecks Log-Datei-Eintrag) und zu bestätigen, damit der Ausdruck - der meist über Nacht erfolgt - nicht an dieser Stelle stehen bleibt und das Meldefenster auf eine Benutzeraktion wartet?

Ein ähnliches Problem tritt auf wenn Excel ausgedruckt wird, aber noch kein Druckbereich definiert wurde.

Ich muß shellexecutewait verwenden, da sonst die Reihenfolge der Dokumente innerhalb eines Verzeichnisses nicht stimmt.

Meinem Verständnis nach müßte ein Task im Hintergrund auf solche Meldungsfenster lauern, dann ein OK absetzen und einen Eintrag in der Log-Datei vornehmen. Aber wie unterscheide ich solche Meldefenster programmtechnisch von einem Programmfenster das ich in der Zwischenzeit gestartet habe (und das nicht unter dem Kontext meines Druckprogrammes läuft)? Wie sieht das Programmtechnisch aus?

Danke für jede Hilfe

LG

Ganz, ganz großer Respekt

Was für eine Arbeit

Win10/64, Checkpoint Virenscanner, lokaler Admin, Version: "Radio Station remix.kwed.org.exe" von Post #13

Win10/64, Checkpoint Virenscanner, lokaler Admin, 1. Version dieses Programmes ...

pasted-from-clipboard.png

und geht noch viel weiter ... (4-5x so lang wie der screenshot)

LG

Hallo

Vielleicht könnten wir hier eine Sammlung erstellen, betreffend des Verhaltens der Antivirusprogramme (AV) und kompilierten AutoIt-Scripten.

Mir ist bis jetzt folgendes aufgefallen (kompiliert immer ohne Laufzeitpacker):

Win7/64, AutoIt 3.3.14.5, Avast

Kompilat in 32bit sowie 64bit: keine AV-Beeinträchtigung

Win10/64, AutoIt 3.3.14.5, Checkpoint

Kompilat in 32bit: erkennt Virus in exe, löscht Kompilat

Kompilat in 64bit: keine AV-Beeinträchtigung

Aufgefallen: ich inkludiere per #pragma compile(Icon, ".\irgendaIcon.ico") ein Icon (und zwar nur hier im Source-Code). Erstelle ich das 32bit-Programm ohne dieses Icon, spricht Checkpoint bei 32bit auch nicht an. Jetzt wäre natürlich genial wenn ich diese #pragma-Anweisung per Abfrage #if compile=64 oder so ähnlich ein- bzw. ausschalten könnten (müßte dann nicht immer händisch auskommentieren vor dem kompilieren).

LG

Danke für das zur Verfügung stellen!

Sowas suche ich schon länger. Für mich werde ich die Farben entfernen da ich nur eine

5-zeilige Datei zu editieren habe.

Danke!

GML

Danke!

Hab ich probiert. Am Firmen-PC (mit Domäne, WinDefender wird - meistens - nur ein Fenster geöffnet und ich sehe die Warnmeldung in diesem Fenster, das schon eine Instanz läuft, wie gesagt, meistens. Wenn man öfter probiert werden manchmal trotzdem mehrere Fenster geöffnet. Das Verhalten ist nicht klar reproduzierbar. Überwiegend funktionierts, manchmal nicht.

Daheim-PC (Win7/64 gleich wie in der Firma, AvastAV, keine Domäne, kein Wins, kein NetBios, reine Netzwerkverbindung über IP) werden die schon laufenden Instanzen in gar keinem Fall erkannt und soviele Fenster geöffnet, als ich Verzeichnisse im Explorer markiert habe.

LG

Zwischenzeitlich habe ich das Problem so gelöst:

local $sname = "testprog"

; PC ist in Domäne
if @LogonDNSDomain Then
    If _Singleton($sname, 1) = 0 Then
         MsgBox(bitor($MB_ICONERROR, $MB_SYSTEMMODAL), "singleton", "flieg grad raus ... ")
         Exit
    EndIf
; PC ist in keiner Domäne, DNSDomain ist leer ohne Domain ...
Else
     If WinExists($sName) Then
         MsgBox(bitor($MB_ICONERROR, $MB_SYSTEMMODAL), "autoitwinsettitle", "flieg grad raus ... ")
         Exit
     EndIf
     AutoItWinSetTitle($sName)
EndIf

löst zwar nicht das Verhalten von _singleton (warum es auf einem PC geht, am anderen nicht) aber funktioniert zumindest zuverlässig und es wird nur eine Instanz des Programmes gestartet.

Grüsse und danke an alle die das Problem behirnt haben ..

LG

Ja, wär eine Möglichkeit. Könnte auch einen Registry-Schlüssel mit Zeitstempel setzen, den könnte ich automatisch löschen

lassen wenn z.B. der Zeitstempel um 5 sek. abweicht.

Ich mach daheim noch den Test auf die Domänenvariante (in der Domäne _singleton, nicht in Domäne AutoItWinSetTitle).

Grundsätzlich funktioniert _singleton ja, aber nur am FirmenPC (-> Domäne). Daheim am PC gehts nicht, dafür aber mit

AutoItWinSetTitle.

Ich meld mich wenn ich probiert habe.

LG

Danke.

Hab ich probiert (zumindest in der Firma, PC ist in der Domäne).

Das Fenster wird sooft geöffnet, als ich Verzeichnisse im Explorer markiert habe (bei 3 markierten).

Das funktioniert aber nicht immer gleich. Bei 12 markierten Verzeichnissen wird (meistens) 1 Fenster

geöffnet, manchmal mehr als eines. Sehr eigenartig.

LG

Zitat von Bitnugger

Ich verstehe hier nur Bahnhof, Koffer klauen... erkläre das bitte mal genauer.

Zudem wäre ein Minimal-Script mit ein paar Kommentaren nicht übel, damit man besser verstehen kann, was du da vor hast.

Es geht darum das ein Script nur EIN mal gestartet wird. Wenn ich im Explorer mehrere Verzeichnisse markiere und über das Kontextmenü (rechte Maustaste) mein Programm starte, wird dieses sooft aufgerufen, als ich Verzeichnisse markiert habe. Das ist unerwünscht, da ich über

Local $hExplorer = WinGetHandle("[REGEXPCLASS:^(Cabinet|Explore)WClass$]") 

If Not $hExplorer Then 

MsgBox(BitOR($MB_ICONERROR, $MB_SYSTEMMODAL), $sName, "Dieses Programm läßt sich nur aus dem Explorer aufrufen!", 0) 

Exit 

EndIf 

Local $oShell = ObjCreate("Shell.Application") 

For $oWindow In $oShell.Windows() 

If $oWindow.HWND() = $hExplorer Then ExitLoop 

Next 

ein Objekt erhalte, das alle im Explorer markierten Verzeichnisse enthält, die im Programm in einer for_next-Schleife der Reihe nach abgearbeitet werden.

Diesen Mehrfachaufruf habe ich versucht durch _Singleton bzw. AutoItWinSetTitle in den Griff zu bekommen. D.h. es soll nur eine einzige Instanz des Programmes gestartet werden, das Programm beim Aufruf prüfen obs schon läuft und sich in dem Fall beenden.

Dabei bin ich auf die obig erwähnten Probleme gestoßen, da anscheinend mit oder ohne Domäne das Verhalten von _Singleton sowie auch von AutoItWinSetTitle anders ist. Natürlich kann der Fehler auch woanders liegen, die Domäne hat sich aufgedrängt, da die PCs ansonsten gleich konfiguriert sind.

LG

Mittels ausgiebiger Recherche versuche ich ein Programm, aufrufbar aus dem Kontextmenü, zum laufen zu bringen. Im Explorer, rechte Maustaste auf ein Verzeichnis (bzw. -baum), bendef. Ausdruck (das ist das Programm um das es geht) .. funktioniert. Wenn ich allerdings mehr wie ein Verzeichnis im Explorer markiere, habe ich das Problem, das für jede Markierung einmal das Programm gestartet wird (das ist nicht notwendig, da ich im Programm selber die

ev. markierten Verzeichnisse behandle, das funktioniert auch schon perfekt).

Also: kein Poblem ... _Singleton ... dachte ich.

Status:

2 PCs, beide Win7/64

daheim:

_Singleton funktioniert NICHT, Programm wird mehrmals gestartet

gelöst mit AutoItWinSetTitle, das funktioniert, Programm wird nur einmal gestartet.

If WinExists($sName) Then Exit

AutoItWinSetTitle($sName)

Firma:

_Singleton funktioniert, AutoItWinSetTitle funktioniert nicht, Programm wird mehrfach gestartet

If _Singleton($sname, 1) = 0 Then Exit

Ich habe hier und auch im Internet schon ziemlich alles durchforstet. Bis auf die Möglichkeit einen Registry-Key zu schreiben (mit Zeitmarkierung) und

auf diesen zu prüfen habe ich alles durch.

Fakt scheint: _Singleton und AutoItWinSetTitle funktionieren beide nicht zuverlässig.

Der Unterschied zwischen den PCs: daheim keine Domäne, in der Firma schon. Vielleicht hängt es damit zusammen.

Also werde ich wohl auf die Domäne abfragen und dann je nach Gegebenheit _Singleton bzw. AutoItWinSetTitle verwenden.

LG