Danjo's two cents NAV, Powershell, Android, C#, Lync, Win8, …

31Jan/120

CMD Vervollständigung

Gestern hatte ich einen dieser Aha-Effekte, der Erstaunen bei einem selbst oder seinem Gegenüber auslöst während der andere etwas für ihn alltägliches tut.

Was genau ist also gestern passiert? Während ich in der Windows-Kommandozeile geschrieben habe, wurden dir Pfade und Dateinamen wie von Zauberhand eingefügt. Einige von euch werden jetzt sagen: "Das kenne ich schon. Was ist daran denn neu? Wir arbeiten ja nicht mit MS-DOS."

Für die jenigen unter euch die nicht so antworten, werde ich kurz erklären was passiert ist: In der Kommandozeile (und natürlich auch in Powershell) ist es möglich die Ordner- und Dateinamen nur anzufangen zu tippen und automatisch vervollständigen zu lassen. Das funktioniert in dem man die ersten Buchstaben noch eintippt und anschliessend die <TAB>-Taste drückt. Gibt es hierbei mehrere mögliche Vervollständigungen, so wird die erste verwendet. Um jetzt aber eine der anderen Möglichkeiten zu bekommen, drückt man noch einmal die <TAB>-Taste und die Ergänzung wechselt zur nächsten Möglichkeit, ...

In der Hoffnung damit einigen da draussen die Tipparbeit zu erleichtern 😉

 

 

20Jan/120

Microsoft veröffentlicht QR-Codes in Berichten für NAV5SP1, NAV2009SP1, NAV2009R2

Gestern hat das Team des Microsoft Dynamics NAV Blogs folgenden interessanten Beitrag gepostet:

http://blogs.msdn.com/b/nav/archive/2012/01/19/qr-codes-for-microsoft-dynamics-nav.aspx

Um das ganze kurz zusammenzufassen:

1) Die angehängte MSI ausführen um die benötigten DLLs zu registrieren.

2) In der gewünschten NAV-Tabelle ein BLOB-Feld (mit Subtyp Bitmap) hinzufügen.

3) Mit Hilfe der angehängten Funktionen kann nun ein QR-Code erzeugt und in das BLOB-Feld importiert werden.

4) Jetzt kann der QR-Code, wie jedes andere Bitmap-BLOB auch, in Reports eingefügt und angedruckt werden (CALCFIELDS nicht vergessen 😉 )

Und das war es dann auch schon.

18Jan/120

NAVTechdays 2012

Als ich gerade mal wieder auf der Seite der NAVTechdays 2011 war, bin ich über folgende Neuigkeit in den FAQ gestossen:

When is the next edition of this conference?

A new edition is planned this year.
Last year's conference proved to be very successful, therefore we are not going to change the overall concept. Again it will be dedicated to Microsoft Dynamics NAV developers & consultants, offering lots of technical sessions and interaction with the Microsoft product team.

Please note these details in your agenda for NAV TechDays 2012:
Thursday 27 & Friday 28 September 2012
Metropolis Business & Communication Center, Antwerp (Belgium)

Und jetzt noch einmal das wichtigste auf Deutsch:

Da die Veranstaltung letztes Jahr ein großer Erfolg war, wird sich an dem Konzept nichts ändern. Die NAVTechdays 2012 werden dieses Jahr am 27. & 28. September im Metropolis Business & Communication Center, Antwerpen (Belgien) stattfinden.

12Jan/120

Mergen von Reports mit RDLData (VS-Design)

Wie einige bereits bemerkt haben dürften, gibt es beim Mergen von Reports seit NAV 2009 ein paar neue Herausforderungen.

Meiner Meinung nach ist der beste Weg NAV-Objekte zu mergen nach wie vor der Textvergleich. Dies gilt auch für Reports, sogar wenn diese RDLData beinhalten. Die Gefahr beim Merge von RDLData in Reports besteht darin, dass ein Objekt ohne korrekte RDLData zwar in NAV importiert werden kann, aber nicht mehr editierbar in Visual Studio ist. Der häufigste Fehler den ich beim merge von Reports erhalten habe, war das eine (oder mehrere) Tabellenzeilen nicht die selbe Anzahl an Spalten hatte/n wie die anderen. Das kann zum Beispiel dann passieren wenn ein neues Feld in eine existierende Zeile eingefügt wird, und zeitgleich eine neue Zeile (ohne leeres Feld als Platzhalter für die neue Spalte) ergänzt wurde.

 

Ich habe hier ein kleines Beispiel entworfen um das ganze zu veranschaulichen.

Layout des Ursprungsreports:

Layout nach Entwicklung A:

Eine neue Zeile wurde eingefügt.

Layout nach Entwicklung B:

In der Tabelle wurde ein neues Feld hinzugefügt (das bedeutet, dass es zu allen Zeilen hinzugefügt wurde).

Damit das Feld nur in der benötigsten Zeile zu sehen ist, wurde es in den anderen Zeilen mit den Zellen daneben zusammengeführt.

 

So lange ein Report nur eine Hand voll Zeilen und Felder hat, ist es kein Problem dies beim merge zu erkennen und einen Fehler zu vermeiden. Und auch wenn es bereits passiert ist, geht es relativ schnell die entsprechende Stelle zu finden und zu korrigieren.

Anders sieht es allerdings aus, wenn wir viele Tabellen, Zeilen und Felder haben. Wie soll man hier die richtigen Codezeilen wiederfinden?

Da das RDLData-Design eines Reports gemeinsamkeiten mit HTML aufweist, habe ich ein kleines Tool geschrieben um die Anzahl der Spalten pro Zeile auf zu summieren. Hiermit wird es möglich ohne lange Suche im Text die störende Codestücke zu finden.

Dies ist das Ergebnis des Tools bei einem intakten Report:

Wie liest man das ganze nun:

1 Reihe mit 2 Feldern / Spalten (im Objekt an Zeile 121 zu finden)

1 Reihe mit einem Feld (das aus 2 zusammengefügten Feldern besteht)

Dieser Report beseht aus einer Tabelle (mit dem Namen "Table1"), welche aus sieben Reihen besteht.

Die erste Reihe beginnt im Textfile in Zeile 121, die letzte in Zeile 314. Jeder der Reihen besteht aus zwei Spalten. Vier der Reihen bestehen aus je zwei Zellen / Textboxen, die anderen drei Reihen bestehen aus nur einre Textbox mit einem "colspan" von 2 (was so viel heisst wie zwei Zellen wurden im Visual Studio zusammen gefügt).

 

Um auf mein Beispiel zurück zu kommen, ist hier das Ergebnis eines 3-Wege-merges mit einem Standardeditor zu sehen (in diesem Fall habe ich Beyond Compare verwendet)

Wie deutlich abzulesen ist, wurde die Tabellenstruktur total zerstört. Das Objekt lässt sich zwar importieren und kompillieren, bringt nun allerdings Fehler beim Versuch das Layout zu editieren.

Um dies zu korrigieren, schaue ich mir nun das Ergebnis der Analyse an:

Die "breiteste"  Reihe besteht aus 4 Spalten, dass bedeutet das ich nun die anderen Reihen so anpassen muss das sie die selbe Anzahl an Spalten haben. Der einfachste Weg dies zu erreichen ist es die "Col-Span"-Eigenschaft zu verändern bzw. einzufügen. In der ersten Reihe ist das dann <ColSpan>2</ColSpan>. In der zweiten Reihe <ColSpan>3</ColSpan> und in der dritten Reihe muss lediglich das <ColSpan>3</ColSpan> durch <ColSpan>4</ColSpan> ersetzt werden. Das ganze zeiht sich dann weiter so durch bis zur letzten Reihe.

In diesem Fall ist das natürlich zu viel Aufwand, da recht schnell zu sehen ist das die 4 Spalten ein einmaliger Ausreiser ist und dazu auch noch zusammengefügte Spalten enthält.. Der schnellere Weg ist es hier den ColSpan-Tag der Reihe ab Zeile 330 zu entfernen und die Zeilen mit nur zwei Spalten zu verändern.

Anschliessend kann das Objekt erneut in NAV importiert und im Visual Studio bearbeitet werden (was nach der "blinden" Abänderung der Struktur auch zu empfehlen ist).

 

Hier ist der Link zum VS-Projekt: FindMissingTableCellsInRDL

   
%d Bloggern gefällt das: