WSShell durch DotNet ersetzt - andere Funktionalität

11. September 2017 15:30

Hallo Zusammen.

Ich habe unter NAV 2009 einen Aufruf über WSSHell mit einem WaitForRetrun Paramter:
Code:
WSHShell.Run('"' + Dateiname + '"',WindowsStyle,WaitForReturn);


Ziel der Übung ist es, ein Word Dokument nach Schließung von Word in die DB zurückzuschreiben - so weit so gut -> NAV 2009 kein Problem.

Nun aber NAV 2017 wo ja bekanntlich kein WSSHell mehr unterstützt wird. Also gut - dachte ich mir - machst du halt DotNet.
Code:
      WordApplication := WordHelper.GetApplication(ErrLoc);
      IF ISNULL(WordApplication) THEN
        ERROR(WordNotFoundErr);

      // Open word and wait for the document to be closed
      WrdHandler := WrdHandler.WordHandler();
      WordDocument := WordHelper.CallOpen(WordApplication,FileName2,FALSE,FALSE);
      WordDocument.ActiveWindow.Caption := parRec.Dateiname;
      WordDocument.Application.Visible := TRUE;
      WordDocument.ActiveWindow.WindowState := WdWindowState.wdWindowStateNormal;

      // Push the word app to foreground
      WordApplication.WindowState := WdWindowState.wdWindowStateMinimize;
      WordApplication.Visible := TRUE;
      WordApplication.Activate;
      WordApplication.WindowState := WdWindowState.wdWindowStateNormal;

      WordDocument.Saved := TRUE;
      WordDocument.Application.Activate;

      NewFileName := WrdHandler.WaitForDocument(WordDocument);
      IF WindowIsOpen THEN BEGIN
        Window.CLOSE;
        WindowIsOpen := FALSE;
      END;
      CLEAR(WordDocument);
      CLEAR(WordApplication);


Problem an dieser Stelle: Das WaitForDocument sorgt für einen Freeze des gesamten NAV :cry: unter NAV 2009 konnte man das Word Dokument offen lassen (bspw. was nachschlagen) und dann das Word Dokument weiter bearbeiten.
Das Verhalten des NAV 2017 Windows Client an dieser Stelle ist mir aber ein Rätsel. Selbst wenn ich mehrere Fenster geöffnet habe, erhalten alle dieses FREEZE, warum?

Mr.Nav.

Re: WSShell durch DotNet ersetzt - andere Funktionalität

11. September 2017 15:47

Hallo,

hast du dir schon mal die CU 5054 "Word Management" und die darin verwendeten Funktionen angeschaut?

Gruß Fiddi

Re: WSShell durch DotNet ersetzt - andere Funktionalität

11. September 2017 16:43

Hier sind diverse Links:
www.msdynamics.de/viewtopic.php?f=66&t=27043
https://saurav-nav.blogspot.de/2015/08/nav-2013-later-how-to-run-batch-file.html

Re: WSShell durch DotNet ersetzt - andere Funktionalität

12. September 2017 11:49

OK habe mir den Code angesehen und versucht mich daran zu tasten ..

Derzeit sieht es wie folgt aus:

Code:
ProcessLoc := ProcessLoc.Process;
ExecName := 'C:\Program Files (x86)\Microsoft Office\Office16\WINWORD.exe'; (hier soll aber dann noch der filename rein)
//ExecName := FileName2;
ProcessLoc.StartInfo.UseShellExecute := FALSE;
ProcessLoc.StartInfo.FileName := ExecName;
ProcessLoc.StartInfo.CreateNoWindow := TRUE;
//ProcessLoc.WaitForExit; -> der Wait Befehl liefert leider eine Fehlermeldung, dass dieser keinem Prozess zugeordnet ist.
ProcessLoc.Start(ProcessLoc.StartInfo);


Obiger Code sollte zunächst erstmal nur Word öffnen um das Prozedere zu testen ... leider wird kein aktives Fenster angezeigt (nur über den TaskManager ist das geöffnete Word sichtbar!?)

Jemand eine Idee?

Re: WSShell durch DotNet ersetzt - andere Funktionalität

12. September 2017 13:50

CreateNoWindow klingt irgendwie nach "mach kein Fenster auf"... das sollte dann schonmal einer sein. Der Dateiname ist in StartInfo.Arguments mitzugeben.

Re: WSShell durch DotNet ersetzt - andere Funktionalität

12. September 2017 15:38

OK da ist natürlich was dran :lol:

Ich bin jetzt soweit, dass über mein Prozess das Word Dokument geöffnet wird:
Code:
      ProcessLoc := ProcessLoc.Process;
      ExecName := 'C:\Program Files (x86)\Microsoft Office\Office16\WINWORD.exe';
      param := STRSUBSTNO(' /q /t "%1"',FileName2);

      ProcessLoc.StartInfo.UseShellExecute := FALSE;
      ProcessLoc.StartInfo.FileName := ExecName;
      ProcessLoc.StartInfo.Arguments := param;
      ProcessLoc.StartInfo.CreateNoWindow := FALSE;
//      ProcessLoc.EnableRaisingEvents := TRUE;
      ProcessLoc.Start(ProcessLoc.StartInfo);


Da nach dem schließen des Word Dokumentes ein Import in ein BLOB erfolgen soll, fehlt mir jetzt allerdings noch die Möglichkeit dem Prozess zu sagen das er "warten" soll bis Word geschlossen wird.
Der "WaitFoExit" Befehl kann hier anscheinend nicht verwendet werden!?

Re: WSShell durch DotNet ersetzt - andere Funktionalität

13. September 2017 06:14

Hallo,

ich fürchte aus der Nummer kommst du nicht raus, wenn du nach dem Beenden von Word in deinem Programmfluss weiterarbeiten möchtest. Warten auf das Programm heißt im RTC nun mal warten auf das Programm. leider! :-?

Ansonsten könntest du natürlich irgendetwas mit Aufgabenwarteschlange oder geplantem Report versuchen, der die geschlossene Datei versucht wieder zu importieren. Aber auch das ist wahrscheinlich nicht stabil zum Laufen zu bekommen.

Es ist ehrlich gesagt auch etwas heikel, wenn man in NAV noch alles machen kann/könnte (auch den Status der aktuellen Funktion ändern), während man in einem externen Programm arbeitet, das einen definierten NAV Status voraussetzt.

Gruß Fiddi

Re: WSShell durch DotNet ersetzt - andere Funktionalität

13. September 2017 08:31

fiddi hat geschrieben:Hallo,

ich fürchte aus der Nummer kommst du nicht raus, wenn du nach dem Beenden von Word in deinem Programmfluss weiterarbeiten möchtest. Warten auf das Programm heißt im RTC nun mal warten auf das Programm. leider! :-?


Das erkläre mal Kunden :mrgreen: ich zitiere "Es lief doch unter NAV 2009 auch" :roll:

Egal bleiben wir Lösungsorienteirt :lol:

Ich hätte da noch zwei Ansätze weiß aber eben nicht - aufgrund fehlender DotNet Kenntnisse - ob möglich.

1.) Über den sog. WaitForReturn Parameter (ging ja früher bei WSSHell auch) dem Code beibringen das er warten soll.
2.) wenn 1. keine Option ist, kann man evtl. über "RaisingEvent" was machen á la: ich lasse eine schleife laufen bis eine Rückmeldung da ist!?

Re: WSShell durch DotNet ersetzt - andere Funktionalität

13. September 2017 08:50

Mr.Nav hat geschrieben:2.) wenn 1. keine Option ist, kann man evtl. über "RaisingEvent" was machen á la: ich lasse eine schleife laufen bis eine Rückmeldung da ist!?


Vielleicht hilft dir als »unterbrechungsfreie Schleife« das integrierte PingPong Addin. Das könntest du auf die Page einbauen, welche die Word-Datei startet. Das PingPong Event rufst du dann z.B. jede Sekunde auf. In dem Event machst du deine WaitforDocument Prüfung.

https://msdn.microsoft.com/en-us/library/jj551782(v=nav.90).aspx
http://www.dynamics.is/?p=1311

Re: WSShell durch DotNet ersetzt - andere Funktionalität

13. September 2017 09:00

vandyke hat geschrieben:
Mr.Nav hat geschrieben:2.) wenn 1. keine Option ist, kann man evtl. über "RaisingEvent" was machen á la: ich lasse eine schleife laufen bis eine Rückmeldung da ist!?


Vielleicht hilft dir als »unterbrechungsfreie Schleife« das integrierte PingPong Addin. Das könntest du auf die Page einbauen, welche die Word-Datei startet. Das PingPong Event rufst du dann z.B. jede Sekunde auf. In dem Event machst du deine WaitforDocument Prüfung.

https://msdn.microsoft.com/en-us/library/jj551782(v=nav.90).aspx
http://www.dynamics.is/?p=1311


Danke für den Lösungsansatz. Leider ist der Aufruf mit dem Prozess in einer Codeunit ausgelagert, wodurch ich irgendwie dem DotNet Process (System.Diagnostics.Process.'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089') diese Info mitgeben muss. :cry:

Re: WSShell durch DotNet ersetzt - andere Funktionalität

13. September 2017 11:50

Der RTC hat das übrigens auch in Version 2009 nicht gemacht. Es geht hier um eine Funktion des CC.
Der Windows Client verhält sich bei modalen Aufrufen immer so. Ist die Page die du öffnest modal?

Was hältst du von vernünftigem Pragmatismus? Das der Windows Client gleichzeitig offene Sitzungen nicht von der Lizenz abzieht, würde ich im Bedarfsfall den Benutzer ein zweites NAV öffnen lassen.

Re: WSShell durch DotNet ersetzt - andere Funktionalität

13. September 2017 13:41

m_schneider hat geschrieben:Der RTC hat das übrigens auch in Version 2009 nicht gemacht. Es geht hier um eine Funktion des CC.

Da muss ich dir leider wiedersprechen !!! Habe es gearde im NAV 2009 RTC probiert *** einfach magisch ***

m_schneider hat geschrieben: Was hältst du von vernünftigem Pragmatismus? Das der Windows Client gleichzeitig offene Sitzungen nicht von der Lizenz abzieht, würde ich im Bedarfsfall den Benutzer ein zweites NAV öffnen lassen.

Das wäre zumindest mal ein Workaround :-D werde ich mal probieren.

Danke.

Re: WSShell durch DotNet ersetzt - andere Funktionalität

13. September 2017 16:36

Mr.Nav hat geschrieben:
m_schneider hat geschrieben:Der RTC hat das übrigens auch in Version 2009 nicht gemacht. Es geht hier um eine Funktion des CC.

Da muss ich dir leider wiedersprechen !!! Habe es gearde im NAV 2009 RTC probiert *** einfach magisch ***

Mit WSHShell vielleicht... Ich habe einfach eine modale Seite geöffnet (Aktivität erstellen) und das ganze System ist gesperrt.