23. Februar 2015 22:18
Hallo an alle,
ich muss an dieser Stelle mal auf einen Umstand hinweisen, der mich beinahe zum Genuss von bewusstseinserweiternden Hilfsmitteln gezwungen hätte ... Kurzum, ich habe mir da selbst ins Knie geschossen.
Sicherlich kennt der ein oder andere von euch das Video
How Do I: Embed Instructions in the User Interface in Microsoft Dynamics NAV 2015.
Hier wird auf die Möglichkeit eingegangen, dem Benutzer das Dynamics NAV-Leben etwas einfacher zu machen. Unter anderem findet man in diesen Video auch eine "Anleitung", Hinweismeldungen des Systems dem Benutzer auszugeben und ihn dann entscheiden zu lassen, ob er die Meldung nochmals sehen möchte oder nicht.
Natürlich dachte sich der Micha, also ich: Das kann ich auch. Etwa so:
Message.PNG
Läuft hervorragend, kommt gut an und macht auch an der ein oder anderen Stelle Sinn. Die obige Meldung erhält der Benutzer beim Anmelden an das System, damit er weiß, wo er wohnt.
Soweit so gut:
Nach der Implementation dieser Funktionalität hatte ich dann versucht, mit STRG+E Daten nach Excel zu übergeben.
Da ging der Spaß dann so richtig los:
- Der Excel hat sich geöffnet und oben im Tabellenblatt auch angezeigt, was er denn eigentlich so vor hätte, nämlich die gerade gefilterten Daten in selbiges zu übergeben. Das wäre der Plan gewesen, aber genau diesem Plan stand oder steht wohl der Befehl
STRMENU entgegen.
Der Excel hat sich listig im Kreis gedreht, d. h. ich hatte keine Eingabemöglichkeit mehr in Excel.
Ich habe dann natürlich sofort das Ereignisprotokoll geprüft, aber zunächst nichts gefunden.
Ich habe natürlich auch den Client neu installiert und das ADD-IN geprüft, erfolglos.
Wäre nicht Fastenzeit, wäre spätestens hier das erste Verzweiflungsbier notwendig gewesen.
Rein zufällig, also wirklich rein zufällig habe ich mir dann im Ereignisprotokoll diese Ereignisse anzeigen lassen:
AdminMes.PNG
und siehe da, ich hatte den Schuldigen gefunden,
nämlich mich selbst. Hier der Code, der alles blockiert hat (aus Codeunit 50033):
Guall1.PNG
Ich dachte eigentlich, das mit "GUIALLOWED" alles geklärt sei, aber da hab ich wohl falsch gedacht und bei längerem, intensiveren Nachdenken wurde mit klar, dass zumindest der STRG+E eine Clientsession im "Background" eröffnet um gegebenenfalls auch die Daten "aktualisieren zu können" (also der Excel).
Nach gutem Zureden und unter Verwendung der neuen Funktion "GETCURRENTCLIENT" habe ich's dann geschafft und der STG+E tut das, was er soll:
Hier der neue Code: Der Übersichtlichkeit wegen mit IF und nicht CASE:
- Code:
IF CURRENTCLIENTTYPE = CLIENTTYPE::Background THEN
EXIT;
IF CURRENTCLIENTTYPE = CLIENTTYPE::Management THEN
EXIT;
IF CURRENTCLIENTTYPE = CLIENTTYPE::OData THEN
EXIT;
IF CURRENTCLIENTTYPE = CLIENTTYPE::SOAP THEN
EXIT;
IF CURRENTCLIENTTYPE = CLIENTTYPE::NAS THEN
EXIT;
IF GUIALLOWED AND IsEnabled(WorkStationCode,'SHOWLOGINMSG') THEN
IF STRMENU(OptionsStringQst,1,MsgText) = 2 THEN
DisableMessageForCurrentUser(WorkStationCode,'SHOWLOGINMSG');
Fazit: (Was habe ich gelernt)
- Der GUIALLOWED fängt nicht alles ab, was man (ich) bis dato erwartet hätte.
- Ich denke durch die Abfrage des Client-Typs ist das ganze Konstrukt sicherer.
- Es ist natürlich nicht die Regel, den Benutzer beim Login mit Nachrichten zu überschwemmen, trotzdem ist dies hin und wieder notwendig. Eine Message schluckt das System ja, und schreibt sie, wie in der Hilfe beschrieben, in das EVENT-Log, wenn der Client eben nicht GUIALLOWED ist.
- Bei STRMENU, was ja, wie man eingangs sieht, auch seinen Scharm hat, tut er sich etwas schwer.
Falls also irgendwer von euch mal ein Excel mit Kreis nach STRG+E erhält --- vielleicht wohnt hier noch was Ähnliches irgendwo versteckt im Code.
Gruß und frohes Schaffen
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.