WinCC Flex Abfrage ob Excel geöffnet ist

[Neuling74]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,
nach langer Zeit habe ich auch mal wieder Fragen.
Folgende Ausgangssituation:
WinCC Runtime Advanced TIA V17 auf Desktop PC.
In meiner Applikation laufen einige Skripte, um Excel Dateien auszulesen, zu beschreiben und zu speichern. Alles gut soweit.
Nun kommt es vor, das der Kunde eine Excel Datei geöffnet hat und meine Skripte daher nicht sauber bzw. gar nicht ausgeführt werden. Ich denke es liegt daran, das bereits eine Instanz von Excel geöffnet ist.
Nun meine Fragen:
1. Ist es möglich in dem Skript abzufragen ob Excel geöffnet ist?
2. Kann ich im gleichen Skript Excel schließen bevor ich eine Datei einlesen möchte?
3. On Error Resume Next -> wo im Skript muss es stehen, damit das Skript "abgebrochen" wird, bzw. mit einer Fehlermeldung weiterläuft? Systemmeldungen sollen angezeigt werden, kommen bei mir aber nicht.
4. Ist die Anweisung On error resume next im gesamten Skript wirksam? Oder muss ich es mehrfach ausführen?

Fragen über Fragen!

Mit VB Skripten kenne ich mich nicht soooo gut aus. Habe zwar alles ans laufen bekommen, aber so wirklich glücklich bin ich damit noch nicht(wegen oben genanntem Problem).
Wer kann mir da weiterhelfen?

 

[Larry Laffer]

Hallo.
im Bereich FAQ hier im Forum haben wir für dolche Sachen einen eigenen Thread in dem zugegebener Maßen sehr viel drin steht :
https://www.sps-forum.de/threads/protool-winccflex-tia-daten-lesen-schreiben-mit-vb-script.15348/

Ich denke, du solltest dir den Teil anschauen, der direkt mit einer Excel-Applikation Kontakt aufnimmt (den habe ich auch mal erstellt).
Bevor du nun irgendetwas kopierst erstellst du dir erst einmal ein Excel-Objekt und schickst diesem dann ein Close - quasi präventiv. Es kann jetzt aber sein, dass dieser Befehl einen Fehler bringt wenn Excel nicht geöffnet ist - das mußt du ausprobieren ...

"On Error resume next" ist im ganzen Script aktiv. Das müßtest du aufheben wenn du es anders haben willst.

Was mir an deinem Scipt aufgefallen ist :
Du hast da an 2 Stellen (oder öfter) eine While-Schleife auf einen Timer. Das hält natürlich das Script ggf. an - stoppt aber auch alles andere. Willst du das ? und was ist der wirkliche Sinn davon ?

 

[Neuling74]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Larry,
danke erstmal für die Antwort.
Die While Schleife mit Timer dient lediglich dazu, etwas zu warten bevor es weitergeht im Skript. Das habe ich mal gemacht, weil ich sehen wollte ob alle Teile des Skriptes vernünftig abgearbeitet werden. Dann habe ich mir Variablen gesetzt und auf dem Monitor anzeigen lassen. Kann eigentlich raus, war ich nur zu faul zu

Werder mir den Thread mal ansehen.

Steht das "On Error resume next" denn an der richtigen Stelle? oder muss es woanders hin?

 

[Larry Laffer]

Ab da wo es steht wirkt es.
Wenn ich mir aber dein Script ansehe dann hast du ja am Anfang eine Err-Abfrage mit der du dann eine Systemmeldung ausgeben willst. Diese wird nie arbeiten, da du an der Stelle keinen Fehler haben wirst.
"On Error resume next" bedeutet, dass der Befehl mit Fehler einfach ignoriert wird und mit dem nächsten Befehl weitergemacht werden soll. Willst du eine Meldung ausgeben so musst du einen Sprungbefehl zu einer Marke an den On Error koppeln - also z.B. "On Error goto Fehlerausgabe".

Zu beachten ist hier aber, dass nichts angefangenes beendet wird - also offnene Dateien bleiben offen etc. - darum mußt du dich dann explizit kümmern ...

 

[Larry Laffer]

Noch etwas dazu :
ich denke mal, dass du wenn du nicht mit FileSystemObject sondern wie im Beispiel mit ExCel.Applcation als Object auf die Tabelle zugreifst und du die Tabelle in der Datei korrekt ansprichst (wie in dem Beispiel von mir) es dir auch egal sein kann ob dein Kunde Excel bereits offen hat. Du "sprichst" dann ja mit DEINER Tabelle.
Beachte auf jeden Fall aber, dass wenn du mit Excel "sprichst" dies u.U. etwas dauert - dein Script läuft also ggf. ein wenig länger weil Excel nicht immer sofort antwortet und auch nicht so zügig ...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

"On Error resume next" bedeutet, dass der Befehl mit Fehler einfach ignoriert wird und mit dem nächsten Befehl weitergemacht werden soll. Willst du eine Meldung ausgeben so musst du einen Sprungbefehl zu einer Marke an den On Error koppeln - also z.B. "On Error goto Fehlerausgabe".

Das hast Du falsch in Erinnerung.

"On Error resume next" bewirkt, daß das Skript bei Runtime Errors nicht abgebrochen wird und auch keine Runtime Error Systemmeldung ausgegeben wird. Ab der Stelle, wo die Anweisung steht.

Will man eine Fehlermeldung haben, dann kann/muß man nach dem eventuellen Fehler den Wert der Err.Number-Eigenschaft abfragen. Wenn der Wert = 0 ist, dann war kein Runtime Error. Wenn der Wert <> 0 ist, dann war ein Fehler: Err.Number und Err.Description geben Auskunft, welcher Fehler genau. Dann muß man entscheiden, ob man eine Fehlermeldung haben will (und diese z.B. mit ShowSystemAlarm explizit erzeugen) und ob/wie das Skript abgebrochen werden soll (z.B. Exit Sub). Will man das Skript fortsetzen, dann sollte man mit der Methode Err.Clear die Err.Number löschen (auf 0 setzen). Err.Clear wird automatisch ausgeführt bei den Anweisungen On Error Resume Next, Exit Sub, Exit Function

"On Error goto Fehlerausgabe" gibt es nicht in VBS.

Eine typische Auswertung von Runtime Errors mit Fehlermeldung sieht so aus:

On Error Resume Next 'ab hier eigene Runtime Error Behandlung

... tue irgendwas

If Err.Number <> 0 Then 'war ein Runtime Error?
    ShowSystemAlarm "Fehler Nr. " & Err.Number & " " & Err.Description
    'Err.Clear 'Err.Number löschen, normal überflüssig, nur nötig falls kein Exit Sub
    Exit Sub
End If

...

On Error GoTo 0 'ab hier wieder Standard Fehler-Behandlung aktiv

Harald

 

[Larry Laffer]

@harald:
wie auch immer - ich hatte aber auch geschrieben, das "On Error resume next" den laufenden Fehlerbefehl dann überspringt.
Was du nicht erwähnt hast (wenn der Goto ja wirklich nicht funktionieren sollte) ist, dass die Behandlung dann immer NACH dem auftretenden Fehler erfolgen muss (und nicht irgendwo) ...

 

[PN/DP]

Will man eine Fehlermeldung haben, dann kann/muß man nach dem eventuellen Fehler den Wert der Err.Number-Eigenschaft abfragen.

 

[Neuling74]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich danke Euch für die Antworten und die Tipps. Werde mal sehen ob es funktioniert wenn ich das mit Excel.Application mache.
Kann allerdings dauern. Im Moment komme ich an die Anlage nicht dran.
Vielen dank bis hierher.

Eines noch, die Fehlerbehandlung müsste ich dann also immer dort machen, wo ein Fehler passieren könnte? Habe ich das richtig verstanden? Oder kann ich dann die Fehlerbehandlung an das Ende des Skriptes schreiben? Da finde ich noch nicht durch.

 

[Larry Laffer]

Nein ... du hast doch Haralds Kommentar dazu gelesen - immer dort wo du auf einen Fehler reagieren möchtest ...

 

[Heinileini]

Eines noch, die Fehlerbehandlung müsste ich dann also immer dort machen, wo ein Fehler passieren könnte? Habe ich das richtig verstanden? Oder kann ich dann die Fehlerbehandlung an das Ende des Skriptes schreiben? Da finde ich noch nicht durch.

Das darfst Du selbst entscheiden und verwalten.
Ich hatte mir angewöhnt, um z.B. eine eigene FehlerBehandlung im Fall der Fälle anzuspringen/ zu durchlaufen, 'On Error GoTo Hell' zu schreiben und das Lable 'Hell:' fand sich bei mir dann immer ganz am Ende des Skriptes (aber noch vor 'End Sub') und wurde normalerweise nicht durchlaufen, weil davor 'Exit Sub' programmiert war.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

'On Error GoTo Label' geht nicht in VBS

 

[Heinileini]

'On Error GoTo Label' geht nicht in VBS

Sch....ade! Damit sind die Möglichkeiten, aus den ohnein sparsam(st)en Mitteln noch etwas Brauchbares zu machen, aber arg eingeschränkt!?

 

[312C]

Nun meine Fragen:
1. Ist es möglich in dem Skript abzufragen ob Excel geöffnet ist?

Falls jemand das so oder für ein anderes Programm mal braucht: Das funktioniert mit der WMI: