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

9Feb/160

Report Design in Visual Studio – Versionen

Hier eine Auflistung der benötigten Versionen und die Links zu den Anleitungen von Clausl.

 

NAV Version Visual Studio
 2009  2005 & 2008 (ab SP1 stabil)
2009 R2 2008
2013 2010 SP1
2013 R2 2012
2013 R2 > CU2 2013
2015 2013
2016 2013

 

Free Visual Studio Designer for editing Reports in Dynamics NAV 2013 and other options

Free Visual Studio designer for NAV 2015 and NAV 2013 R2

10Jun/120

Clausl ist zurück: Und er sagt uns wie man mit Web Developer Express Reports entwickeln kann

Die unter euch die etwas mit dem Namen Clausl anfangen können wissen vermutlich inzwischen, dass er Microsoft und den Dynamics-blog verlassen hat.

Es hat allerdings nicht lange gedauert bis er ein neues Blog gestartet hat: Clausl and Dynamics NAV

Und gleich der erste Eintrag ist etwas, mit dem ich persönlich nicht mehr vor NAV "8" gerechnet habe.

Um es auf den Punkt zu bringen - er bechreibt wie man mit dem Web Developer Express Reports für NAV 2013 entwickeln kann.

http://mibuso.com/blogs/clausl/2012/05/31/free-visual-studio-designer-for-editing-reports-in-dynamics-nav-2013-and-other-options/

Great Idea

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: