Beiträge von mumpel

Hallo!

Bei mir auf meinem Tablet (Microsoft Surface 3 Pro, Windows 10) im IE ist das "Fenster" zur Anmeldung durchsichtig. Da kann ich nur raten wo die Eingabefelder sind. Könnt ihr da noch nachbessern? Danke!

Gruß, René

Danke! Bei der Word-Funktion haben sich, wenn ich das richtig erkenne, nur zwei Zeilen geändert. Aus "SaveAs" wurde "SaveAs2" (die Standard-Speichermethode die man in Word-VBA nutzen sollte/muss),. Und eine weitere Fehlerprüfung ist hinzugekommen (If @error = 0x80020006...), welche bei Fehler wieder das alte Speichern-Format (SaveAs) setzt.

Zitat von autoiter

(...) Ersetze mal deine Excel.au3 in deinem Include Ordner (...)

Danke! Fehlermeldung erfolgt nun nicht mehr. Nur der Start dauert noch sehr lange, im Vergleich zum Start bei deaktivierten COM-Add-Ins.

Zitat von autoiter

(...) PS: Ein ärgerliches Problem (...)

Eine Frage ist aber noch ungeklärt. Weshalb tritt das Problem nur bei bestimmten COM-Add-Ins auf? Gibt es dafür eine Erklärung? Mir wäre dieses Problem übrigens garnicht aufgefallen wenn es heute kein Office-Update gegeben hätte. Denn mit jedem Office-Update aktivieren sich die COM-Add-Ins von selber wieder, und ich muss sie wieder deaktivieren.

Zitat von autoiter

(...) In meiner Version ist die angemerkte IsObj-Prüfung genau an der Stelle enthalten (...)

Hast Du das selber gemacht? Oder bekommt man aktualisierte UDF zum Herunterladen?

Dazu müsste man m.E. erstmal herausfinden weshalb das Problem nur dann auftritt wenn das Foxit-Add-In aktiv ist. Sind alle COM-Add-Ins deaktiviert tritt das Problem ja nicht auf.

Hier der Bericht aus der Komnsole:

>"C:\Program Files (x86)\AutoIt3\SciTE\..\AutoIt3.exe" "C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "C:\Users\Mumpel\Desktop\Office Admin Tool\Office Administration Tool.au3" /UserParams    
+>20:31:08 Starting AutoIt3Wrapper v.17.224.935.0 SciTE v.3.7.3.0   Keyboard:00000407  OS:WIN_10/  CPU:X64 OS:X64  Environment(Language:0407)  CodePage:0  utf8.auto.check:4
+>         SciTEDir => C:\Program Files (x86)\AutoIt3\SciTE   UserDir => C:\Users\Mumpel\AppData\Local\AutoIt v3\SciTE\AutoIt3Wrapper   SCITE_USERHOME => C:\Users\Mumpel\AppData\Local\AutoIt v3\SciTE 
>Running AU3Check (3.3.14.2)  from:C:\Program Files (x86)\AutoIt3  input:C:\Users\Mumpel\Desktop\Office Admin Tool\Office Administration Tool.au3
+>20:31:08 AU3Check ended.rc:0
>Running:(3.3.14.2):C:\Program Files (x86)\AutoIt3\autoit3.exe "C:\Users\Mumpel\Desktop\Office Admin Tool\Office Administration Tool.au3"    
--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
"C:\Program Files (x86)\AutoIt3\Include\Excel.au3" (227) : ==> Variable must be of type "Object".:
$oExcel.Windows($oWorkbook.Name).Visible = $bVisible
$oExcel.Windows($oWorkbook.Name)^ ERROR
->20:31:13 AutoIt3.exe ended.rc:1
+>20:31:13 AutoIt3Wrapper Finished.
>Exit code: 1    Time: 4.931

Ich kann den Code anordnen wie ich möchte. Die Fehlermeldung bleibt. Mit dem folgenden Code bleibt Excel offen, aber auch die ursprüngliche Fehlermeldung.

Global $oExcel = _Excel_Open()
   Global $__g_oTemplateCOMErrorHandler = ObjEvent("AutoIt.Error", "__Excel_COMErrFunc")
   $oExcel.adgojk5dtrj()
   If @error Then MsgBox(16,"Fehler", "Fehler aber Script läuft weiter!")
   Local $oWorkbook = _Excel_BookOpen($oExcel, @ScriptDir & "\Office Administration Tool.xlsb", 0, True, $sEndCD, $sEndCD)
   $__g_oTemplateCOMErrorHandler = Null
   $oExcel.adgojk5dtrj()
   If @error Then MsgBox(16,"Fehler", "Diese Msgbox wird nie angezeigt werden.")
   Local $sReadOn = RegRead("HKEY_Current_User\Software\VB and VBA Program Settings\RMH_Installationen\AdminTool\", "OnStart")
   Local $sReadNew = RegRead("HKEY_Current_User\Software\VB and VBA Program Settings\RMH_Installationen\AdminTool\", "NewStart")

(P.S.: An meinem VBA-Code liegt es nicht. Würde sonst auch einen Fehler ausgeben wenn Add-Ons deaktiviert sind)

Der Code von @Zeitriss macht genau das Gegenteil von dem was er machen soll. Mit dem Code wird Excel abgeschossen (auch wenn ich "Excel_Close" weglasse) und das Script beendet. Aber die ursprüngliche Fehlermeldung kommt vorher trotzdem noch. Die Zeile die als fehlerhaft angegeben wird stammt aber nicht von meinem Code. Das Problem betrifft nicht Excel, sondern ein Add-On (wie im Eingang bereits erwähnt), welches aber nicht durch mein Script aufgerufen/eingebunden wird.

Ich verstehe trotzdem nicht wie und wo ich das bei mir einbauen muss.

Local $oExcel = _Excel_Open()
   Local $oWorkbook = _Excel_BookOpen($oExcel, @ScriptDir & "\Office Administration Tool.xlsb", 0, True, $sEndCD, $sEndCD)
; Hier soll es trotz Fehler weitergehen

In Google finde ich aber nichts.

Und alle Versuche scheitern. Es klappt einfach nicht, es kommt immer die Meldung von AutoIt.

Das Folgende ahbe ich eingebaut. Aber egal an welche Stelle ich das setze, es funktioniert nicht.

Local $oError = ObjEvent("AutoIt.Error", "__Excel_COMErrFunc")
   If $oError Then MsgBox(0,0,"Test")

Ich kenne die Bezeichnung "UDF" nur unter "User definied function" (Benutzerdefinierte Funktion) in VBA.

Das heisst ich muss nur die Zeile  Local $oError = ObjEvent("AutoIt.Error", "__Excel_COMErrFunc")  und die leere Funktion einfügen und bekomme keine Fehlermeldung mehr?

Zitat von alpines

(...) Mach mal die UDF auf (...)

Ich soll bitte was aufmachen?

Ich nutze Local $oExcel = _Excel_Open(), also keine Objekte wie in dem von Dir verlinken Beispiel. _Excel_COMErrFunc wird von Intellisense nicht aufgelistet.

Danke! Weshalb finde ich in Google keine Beispiele?

Hallo!

Nun arbeitet mein Script so wie es soll. Leider musste ich feststellen dass das Script beim Starten von Excel einen Fehler auswirft ("... Variable vom Typ Objekt" erwartet (...)"). Schuld daran ist in meinem Fall ein fehlerhaft programmiertes Add-On ("Foxit PDF Creator COM Add-inn"). Den Fehler wirft aber nur das AutoIt-Script aus, Excel selber nicht (Excel startet ohne Murren, und alles in Excel funktioniert wie es soll). Dadurch bricht das AutoIt-Script natürlich ab. Wie kann ich solche Fehler sauber und korrekt abfangen, wobei das Script weiterhin alles abarbeiten soll? Excel im abgesicherten Modus zu starten ist keine Option. Es gibt zwar @error, aber so richtig anzuwenden verstehe ich das nicht.

Danke!

Gruß, René

Bei den Office-Dateien hätte man mit "RunAs" ohenhin ein Problem. Denn für "RunAs" ist in der Registrierungsdatenbank standardmäßig kein Kommando hinterlegt. Den RunAs-Schlüssel muss ich immer manuell eintragen und mit dem zugehörigen Officeprogramm (den Pfad dorthin) versehen. Bei mehreren Dateitypen ganz schon viel Zeit erforderlich, und auf einem Rechner der mir nicht gehört kann ich das nicht einfach ungefragt per Script setzen. Man kann also nur das Officeprogramm per RunAs scriptgesteuert starten, eine Office-Datei dagegen nicht wenn auf dem Zielrechner kein RunAs-Kommando in der Registrierungsdatenbank gesetzt ist.

Zitat von AspirinJunkie

Edit: Geht ja noch viel einfacher:

Gilt das auch für Excel und dem Aufruf der Exceldatei, inklusive Übergabe der Kennwörter? Oder ist das nur für die PDF-Datei gedacht?

Die Quick&Dirty-Lösung interessiert mich auch, irgendwann muss ich ja mal anfangen zu lernen.

Gibt es eine andere Möglichkeit abzufragen ob der angemeldete Benutzer über Administratorrechte verfügt (und wenn ja Excel mit Adminrechten zu starten, und wenn nicht das Script zu stoppen) ohne dass das AutoIt-Script selber Adminrechte benötigt? Je sicherer das Script umso besser. Nur auf Administratorkonten soll das Tool zu öffnen sein.

Zitat von AspirinJunkie

(...) könnte aber Schaden verursachen. (...)

Das kann eine PDF-Datei auch auf eingeschränkten Konten....

Zitat von AspirinJunkie

(...) Sieht für deinen Fall dann z.B. so aus (...)

Danke! Funktioniert. Gibt es hier keine Danke-Schaltfläche?

Kann man #RequireAdmin nicht killen, also auf "Nothing" setzen wenn es zur weiteren Scriptlaufzeit nicht mehr benötigt wird oder den weiteren Scriptablauf stört? Also anstatt es ganz zu Anfang zu setzen setz man #RequireAdmin nur zur Statusbfrage und nach der Statusabfrage "abschalten".

Zitat von AspirinJunkie

(...) Nur bei Vorliegen des Sonderfalles (...)

Dann lag gestern irgenwie dieser Sonderfall vor.

Zitat von AspirinJunkie

Anders gefragt: Warum braucht das Skript unbedingt Adminrechte?

Weil Excel mit Administratorrechten gestartet werden muss, denn nur dann hat Excel auch volle Zugriffsrechte auf die Registrierungsdatenbank. Ohne Admin-Rechte hat kein Programm vollen Zugriff, schon garnicht auf die Policies. Und wenn ein User keine Administratorrechte hat, das ist z.B. auf Intranet-Rechnern häufig der Fall (muss auch so sein), soll er das Tool erst garnicht starten dürfen.

Zitat von AspirinJunkie

(...) Mit sehr großer Wahrscheinlichkeit hast du den Leuten hier aber die Zeile "#RequireAdmin" vorenthalten (...)

Hatte ich beim Test nicht drin. Es hat mit und ohne #RequireAdmin nicht funktioniert.

Zitat von AspirinJunkie

Das Problem ist der geschützte Modus des Acrobat Reader.

Danke! Und das soll einer wissen? Kann man den Status irgendwie auslesen, um dem Anwender eine alternative Anzeigemöglichkeit zu bieten? Ich könnte zwar darauf verzichten die Anleitung automatisch anzeigen zu lassen, aber dann liest sie wieder keiner und jeder beschwert sich nur.