Yesterday I had one of this moments where a small click changes the world of the person next to you. And at the first moment, you don’t know why.

So what happend? While working in the commandline, full directory-paths appeared on the screen, without having been typed in by me. Some of you might say: “That’s normal, it always was with windows command-line, this is not MS-DOS. ”

For those who don’t know the feature I am talking about, I will give a short explanation: In command-line (and Powershell) it is possible to use the <TAB>-Key to complete the currently written folder-path or file-name. If there are more the one possible completition available the first one will be used. If you know press <TAB> a second time, it will change the completition to the next one.

Hopefully this will help some of you out there 😉

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 😉

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.

Yesterday the team from Microsoft Dynamics NAV Blog posted this cool new feature i would like to share with you:

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

To sum it up:

1) Install the attached MSI-File to install the needed DLLs.

2) Add a BLOB-Field (Bitmap as subtype) for the QR-Code to the desired table.

3) Use the attached NAV-functions to generate the QR-Code and import it into BLOB

4) As with all Bitmap-BLOB-fields,  insert the image into the desired reports (calcfields is essential 😉 )

That’s all you need for QR-Codes on reports.

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.

Looking for new impressions of NAVTechdays 2011 I found this new question and answer in the FAQ:

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)

That are really great news and I am looking forward to it.

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

As some of you may already have discovered, there are some new challenges coming with NAV 2009 when upgrading or merging reports.

In my eyes the best way to merge NAV-Objects was and still is using text-comparsion. This still works with Reports, even if they contain RDLData. But you can damage the RDLData of an object in a way that won’t allow you to properly edit it in Visual Studio again. The most common error I received while merging reports was one ore more lines in the design containing not the same amount of columns as the rest. This could happen if you add one field to an existing line, and another line where you forget to add a new empty field for the data to match.

I designed a small example to show you what I mean.

Initial Layout:

Developer A’s Layout:

A new line was added.

Developer B’s Layout:

A new field was added to the tablebox (this means that it was added to all lines).

The new field was merged with exisiting fields in all rows where it isn’t needed.

This error can easly be found and corrected, as long as there are only a couple of tables, lines and fields.

But what to do if there are so many fields, that you can not find the wrong line of code?

Since report design in RDLData is not too different from HTML, I wrote a small tool to sum up the columns per row. This tool now allows to find the part of the object-text-file causing the trouble.

This is the result of a fine working report:

How to read:

This reports’ RDLData show one table (with the name “Table1”) containing seven rows.

The first row starts in line 121, the last row starts in line 314. Each row has two columns. In four cases this means two cells / two textboxes, whereas in three cases there is only one cell / textbox with colspan of 2 (this is a merged tablecell in Visual Studio).

Coming back to my example I ‘ll show you the result of a 3-way-text-merge using a common tool (in this case I used Beyond Compare)

As you can see, the table-structure is totaly messed up. After successfully importing and compiling the object in NAV you will get an error when you try to edit the layout.

What I do now is looking at the result of the tool’s analyse:

The largest row contains of 4 columns, so I should change the other rows to the same amount of columns. The easiest way of doing this is inserting the ColSpan-tag to the first tablecell-element of each row. In the first row this would be <ColSpan>2</ColSpan>. In the second row it would be <ColSpan>3</ColSpan> and in the third row I only have to change <ColSpan>3</ColSpan> into <ColSpan>4</ColSpan>, and so on.

As some of you may have noticed this is too much effort in this case. The faster way is to remove the ColSpan-Tag from the row starting in line 330 and only add/edit the tag to the rows with currently 2 columns.

After doing this you will be able again to edit the layout in Visual Studio, which I highly recommend after having randomly added colspans.

The Sourcecode of this tool will be uploaded after a short code-review, which will be done within the next days.

Update: FindMissingTableCellsInRDL