AutoProjectFile Verhalten beim Update LL25 -> LL27

Deutschsprachiges Forum
1

Hallo,
in Version LL25 funktioniert die Kombination

LL.AutoProjectFile = Environment.GetFolderPath(Environment.SpecialFolder.Templates) + "\\*.lst";
...
LL.Print();

noch in unserem .NET Projekt.
Nun versuche ich auf LL27 umzusteigen und bekomme eine ArgumentException: Illegal Character in Path.
Wenn ich nur den Pfad ohne “\\*.lst” angebe wird es die Exception “No Project exists with the specified file name.”
Hinzu kommt, dass es auf meinem Gerät funktioniert (Dialogfenster zur Dateiauswahl) aber auf einem blanken Windows nicht (Windows virtuelle Sandbox). Damit lässt es sich leider auch schwerer debuggen.
Ich habe verschiedene Pfade ausprobiert mit dem Verdacht, dass es sich um andere Schreibrechte auf der Testmaschine handelt, bisher leider ohne Erfolg.
Gibt es bekannte Einschränkungen auf virtuellen Maschinen? Kann ich das AutoProjectFile auf einem anderen Weg anlegen? Oder bin ich auf einer ganz falschen Spur ? :wink:
Ich freue mich auf Anregungen. Vielen Dank und
Beste Grüße
Silas

Pfad + *.lst
Pfad + *.lst428×551 24.8 KB

2

Es spricht nichts gegen eine Verwendung von virtuellen Maschinen. Bei unseren Tests verhält es sich so, wie Sie es von Ihrem System schildern. Es öffnet sich ein Dateiauswahl-Dialog. Haben Sie einmal geprüft, was Environment.GetFolderPath(Environment.SpecialFolder.Templates) auf der Maschine zurück gibt? Ein Debwin-Logfile könnte ggf. mehr Informationen liefern:

  1. Beenden Sie die Anwendung.
  2. Starten Sie das Debug-Tool “Debwin4.exe” aus dem LL-Installationsverzeichnis (Ordner “Verschiedenes”).
  3. Wählen Sie in Debwin4 “Capture List & Label Log”.
  4. Starten Sie nun die Anwendung und führen Sie die Schritte bis zum Auftreten des Verhaltens erneut durch.

Nein, genau so ist es anzuwenden. List & Label versucht die Datei zu öffnen, auf die AutoProjectFile zeigt.

3

Danke für die schnelle Antwort!
Der Pfad verhält sich auf beiden Systemen wie gewünscht:
C:\Users\WDAGUtilityAccount\AppData\Roaming\Microsoft\Windows\Templates
C:\Users\silas\AppData\Roaming\Microsoft\Windows\Templates
Auch wenn ich einen anderen Ordner nutzte tritt der gleiche Fehler auf z.B. bei:

string tempPath = Path.GetTempFileName();   // temp Datei schreiben
MessageBox.Show(tempPath);
tempPath = Path.GetDirectoryName(tempPath); // Pfad ohne Datei
Process.Start(tempPath);                    // temp Datei anschauen
LL.AutoProjectFile = tempPath + "\\*.lst";

Danke für den Hinweis auf das Debwin4 Programm. Beim Vergleich von LL25 und LL27 unterscheidet sich das Verhalten nach dem Block Examining property…
LL25: >LlSelectFileDlgTitleEx(1,0000000000000000,'',0x00000002,0000000025309AC0=''C:\Users\WDAGUtilityAccount\AppData\Roaming\Microsoft\Windows\Templates\WONDER 3.0 Reporting\*.lst'',16384,0000000000000000)
LL27: >LlGetUsedIdentifiersExV(1,'C:\Users\WDAGUtilityAccount\AppData\Roaming\Microsoft\Windows\Templates\WONDER 3.0 Reporting\*.lst',0x00000008,0000005F78FFE620)

Vielen Dank und viele Grüße

4

Es scheint aber auch zwischen LL27 auf einer Virtuellen Maschine (Sandbox) und meinem Rechner Unterschiede zu geben:
LL27 Sandbox (Illegal characters in path.):

>LlGetUsedIdentifiersExV(1,'C:\Users\WDAGUtilityAccount\AppData\Roaming\Microsoft\Windows\Templates\WONDER 3.0 Reporting\*.lst',0x00000008,00000094463FE850)

LL27 Lokal (Geht):

>LlSelectFileDlgTitleEx(1,0000000000000000,'',0x00000002,000002A3692C89B0=''C:\Users\silas\AppData\Roaming\Microsoft\Windows\Templates\WONDER 3.0 Reporting\*.lst'',16384,0000000000000000)

Vielleicht hat es was mit dieser Neuerung zu tun? Das V am Ende von >LlGetUsedIdentifiersExV könnte etwas mit Virtuell sein?

Vielen Dank und viele Grüße

5

Hallo,

interessanterweise sind hier zwei verschiedene Funktionen im Spiel. Zum einen LlGetUsedIdentifiers, welches die im Projekt verwendeten Felder/Variablen abfragt. Das funktioniert korrekterweise nicht, weil *.lst keine gültige Projekt-Datei ist. Hier muss eine Projekt-Datei angegeben werden. Zum anderen wird LlSelectFileDlgTitleEx aufgerufen, das ist der Dateiauswahl-Dialog und hier ist *.lst erlaubt. Scheinbar wird auf der Sandbox und lokal auf dem Gerät nicht die identischen Schritte ausgeführt (fälschlicherweise sogar eine andere Anwendung?)?

Das “V” hat keine weitere Bedeutung und ist nur ein interner Funktions-Aufruf, welcher keinen weiteren Einfluss auf den Druck/Export hat.

6

Hi,
Die Anwendung ist frisch kompiliert auf beiden Systemen die selbe. Ich würde gerne einheitlich den LL Dateiauswahl-Dialog nutzen können. Kann ich Ihnen die *.log4 Dateien zukommen lassen? Vielleicht sehen Sie mehr?
Auf einem anderen Laptop verhält sich die Anwendung wie auf meinem Entwickler Gerät, an der Installation von LL scheint es also auch nicht zu liegen.
Vielen Dank und beste Grüße
Silas

7

Guten Tag,

lassen Sie uns doch am besten das gesamte Logfile (auch wg. etwaiger sensibler Inhalte) im Rahmen eines Support-Cases über das Supportportal zukommen. Da können wir auch weitere Informationen und/oder Dateien austauschen und zielführend gemeinsam an der Lösung arbeiten. Vielleicht könnten Sie auch direkt zwei Logfiles zur Verfügung stellen:

  • Eines, bei dem das gewünschte Szenario erfolgreich funktioniert
  • Eines, bei dem es aktuell noch zu einem unerwartetem Verhalten kommt

So könnten beide Szenarien anhand der beiden Logfiles genauer untersucht und miteinander vergleichen werden. Abschließend können wir dann das Ergebnisse bei Bedarf hier noch einmal gesondert veröffentlichen.

Besten Dank und ein schönes Wochenende,
Daniel Stein

8

Kleines Update, falls jemand ein ähnliches Anliegen hat:
Workaround Vorschlag vom Support:
Registry Key löschen:
"HKLM\system\CurrentControlSet\Control" Wert “ContainerType” > 0
Dann erkennt LL27 nicht, dass es auf einer VM (Sandbox) läuft.
Vielen Dank und schöne Grüße

1 Like