Beiträge von Reinerm

Halllo

Wird bereits im englischen Forum behandelt.

WebDriver UDF - Help & Support (IV)

Nach Korrektur meines Setups ( siehe eng. Forum) funktioniert der Aufbau einer Session wieder.

Danke Reiner

Moombas

1 ist die E-Mail-Adresse (Benutzerkonto) in Outlook der folder beginn im Array bei 2 . Das Array wurde auch immer richtig angezeigt und Index für den Zugriff war auch immer korrekt.

water

Ja, das Problem ist erstmal gelöst. Vielen Dank für die Hilfe und Motivation dran zu bleiben.

Auch noch mal ganz herzlichen Dank für das Udf. Es ist phantastisch!

Vielleicht hat noch jemand eine Idee warum es unkompiliert abstürzt.

Nach dem Kompilierern in eine Exe ist der Fehler weg.

Es scheint ein Bug in SciTE (Version 4.2.0 Sep 3 2019 19:04:05) zu sein, oder???

Ich habe noch weiter versucht den Fehler zu finden und konnte folgende Stelle in OutlookEX.au3 lokalisieren:

In der Funktion _OLFolderAccess

(HINWEIS: Die Zeilennummern unten, welche ich in die Konsole schreibe , sind nicht mehr Original)

        If $aFolders[0] > 1 Then ; Access subfolders
            _ArrayDisplay($aFolders) ; Zu Testzwecken 
            ConsoleWrite("XXXZeile  974") ; Zu Testzwecken 
            For $iIndex = 2 To $aFolders[0]
                ConsoleWrite("XXXZeile  976") ; Zu Testzwecken
                If $aFolders[$iIndex] <> "" Then
                   ConsoleWrite("XXXZeile  978 Ix=" &$iIndex & "T"& $aFolders[$iIndex] ) ; Testzwecken
                    $oFolder = $oFolder.Folders($aFolders[$iIndex])
                    If @error Or Not IsObj($oFolder) Then Return SetError(4, $iIndex, "")
                EndIf
            Next
        EndIf
    EndIf
    ConsoleWrite("XXXZeile  985") ; Zu Testzwecken
    $aResult[1] = $oFolder
    $aResult[2] = $oFolder.DefaultItemType
    $aResult[3] = $oFolder.StoreID
    $aResult[4] = $oFolder.EntryID
    $aResult[5] = $oFolder.FolderPath
    Return $aResult
EndFunc   ;==>_OL_FolderAccess

Wenn der Fehler auftrat, dann nach der Zeile 978 bei Index 2 oder 3 auf.
Das $aFolder Array wurde immer korrekt angezeigt.

Index 2 und der richtige Eintrag dazu wurde auch in der Konsole geschrieben vor dem Abstutz.

Ich kann mir dies nicht erklären zumal es manchmal 20x sauber durchläuft und dann wieder nicht...

Sorry hatte mich verschrieben..war spät

error 3 extendet 4

Bisher konnte ich kein Loop finden, welches den falschen Array-Index benutzt. Ich suche aber weiter.....

Ich rufe vor dem Erstellen der neuen Kalenderdaten _OL_ItemFind auf, um alle vorherigen Einträge des Tages zu erfassen und Sie anschließend zu löschen. Ich habe meine Fehler Analyse erweitert und festgestellt, dass bei dem Befehl _OL_ItemFind ab und zu ein Fehler auftritt. Err 0 / Extendet 4. Hier kommt auch die Analysemeldung von _OL_ErrorNotify(2)

Der Befehl lautet:

$aItems = _OL_ItemFind($oOutlook, "*\Kalender\Dienst", $olAppointment, "[Start] > '" & $dDateStart & "' AND [Start] < '" & $dDateEnd & "'", "","", "EntryID,Subject,Location", "", 1)

Das Datum (format) ist

$dDateStart: 15-04-2022 00:00 $dDateEnd: 16-04-2022 00:00

Ist $olAppointment ein interne Variable? Diese habe ich nicht definiert.

Oh
ich hatte den vorherigen Post nicht gesehen. Da schau ich Heute Abend gleich mal nach ....muss jetzt weg.

Vielen Dank bis hierhin. Ich melde mich später..... .

Frage?

Ich darf doch das OutlookObjekt öffnen und danach mehrere Kalendereinträge (ca 50 in ca. 1min) eintragen und danach erst das Objekt schließen, oder? Oder sollte man vor und nach jeder Aktion die Verbindung neu anfordern?

Eine Com Fehlermeldung erscheint.

Nein, das Programm wird an dieser Stelle beendet, ohne Fehlermeldung.

Du bringst mich auf eine Idee, Ich lass mir mal die Fehlermeldung in die console schreiben ……. Da ich sie im Moment nur in meiner GUI Anzeige……

Es wurde kein Fehler in die console geschrieben

Ich schreibe gerade ein Script, welche sich Daten aus einer Webseite holt und diese dann in Outlook einträgt.

Das Script läuft 5-10x ohne Probleme, dann wieder Abstutz mit dem Fehler ... ended.rc:-1073741819.

Zum Testen des Scripts verwende ich immer die gleichen Webseiten, so ergeben sich immer die gleichen Einträge, aber das Verhalten ist für mich unberechenbar. Nun habe ich mir an verschiedenen stellen in die Console schreiben lassen wo sich das Script gerade befindet und konnte ermitteln, dass es z.B. im Befehl _OL_ItemCreate oder im Befehl _OL_ItemFind abstürzt.

Func sendAppointment($sSubject,$sStart,$sEnd,$sVenue,$sProdNr,$sRemark,$sLinkToSP)
Local $sBody
Local $oItem
Local $sBody = $sSubject & @CRLF &$sVenue& @CRLF & @CRLF & $sProdNr & @CRLF & $sRemark  & @CRLF &"ProNet:"& @CRLF &$sLinkToSP & @CRLF& @CRLF  & "Sync (RM):"& $sToDay


ConsoleWrite(" INFO from function SendAppontment: Start (" &$sStart&"-"&$sEnd &" "&$sSubject&") --  " )


$oItem = _OL_ItemCreate($oOutlook, $olAppointmentItem, "*\Kalender\Dienst", "", "Subject="& $sSubject, "Start=" & ConvertsDate($sStart) , "End=" & ConvertsDate($sEnd) , _
"Location= " & $sVenue ,"ReminderSet= false","Body=" &$sBody ,"RequiredAttendees=" & $oOutlook.GetNameSpace("MAPI" ).CurrentUser)


If @error <> 0 Then
addNewGUIInfo("Termin in Outlook eintragen",1,1)
addNewGUIInfo("ist fehlgeschlagen")
addNewGUIInfo("Funktion: createAppointment")
addNewGUIInfo("@error:" & @error & ", @extended = " & @extended)
addNewGUIInfo("Outlook-Server ist nicht erreichbar")
addNewGUIInfo("-----------------------------------------")
;$stopFlag = True
;SetError(1)
Endif
ConsoleWrite(" End "& @CRLF)
EndFunc; sendAppointment

Konsole:

INFO from function SendAppontment: Start (2022/03/29 09:00:00-2022/03/29 16:42:00 Titel.. ganztags) -- #2 End

INFO from function Delete OutlookDay: Start (2022/03/30 00:00:00) #2 (30-03-2022 00:00 -- 31-03-2022 00:00) #3 End

INFO from function Create Appointment: Start

INFO from function SendAppontment: Start (2022/03/30 09:00:00-2022/03/30 16:42:00 Titel.. ganztags) --

!>16:08:47 AutoIt3.exe ended.rc:-1073741819

Ich verwende:

Win 10 mit Outlook 2016

OutlookEX in Version 1.7.00 .

SciTE 32-bit Version 4.2.0

Hat jemand einen Tip was ich noch testen kann oder woran es liegen könnte

Danke Reiner