OBJECT Codeunit 99500 NAV Bug
{
  OBJECT-PROPERTIES
  {
    Date=17.06.10;
    Time=14:30:30;
    Modified=Yes;
    Version List=;
  }
  PROPERTIES
  {
    OnRun=BEGIN
            TestMiddleCase;  // comment this line out and ReverseString works!
            TestReverseString;
          END;

  }
  CODE
  {

    PROCEDURE TestMiddleCase@5128500();
    BEGIN
      MiddleCase('fooo AnD bar');
    END;

    PROCEDURE TestReverseString@5128502();
    VAR
      l_String@5128500 : Text[1024];
      l_Result@5128503 : Integer;
    BEGIN
      l_String :=
        '1101101111011011110110111101101111011011110110111101101111011011' +
        '1101101111011011110110111101101111011011110110111101101111011011' +
        '1101101111011011110110111101101111011011110110111101101111011011' +
        '1101101111011011110110111101101111011011110110111101101111011011' +
        '1101101111011011110110111101101111011011110110111101101111011011' +
        '1101101111011011110110111101101111011011110110111101101111011011' +
        '1101101111011011110110111101101111011011110110111101101111011011' +
        '1101101111011011110110111101101111011011110110111101101111011011';

      IF STRLEN(l_String) <> 512 THEN
        ERROR('Wrong strlen');

      l_Result := TestReverseStringSub(l_String);

      IF l_Result <> 512 THEN
        ERROR('Error: Actual: ' + FORMAT(l_Result) + ' ' + ' Expected: 512');
    END;

    PROCEDURE TestReverseStringSub@5128521(p_String@5128500 : Text[1024]) r_Int : Integer;
    VAR
      l_StringMgt@5128501 : Codeunit 5128519;
    BEGIN
      p_String := ReverseString(p_String);
      EXIT(STRLEN(p_String));
    END;

    PROCEDURE ReverseString@5128509(p_In@5128502 : Text[1024]) Result : Text[1024];
    VAR
      i@5128500 : Integer;
      l_Length@5128501 : Integer;
    BEGIN
      l_Length := STRLEN(p_In) + 1;

      FOR i := 1 TO l_Length - 1 DO
        Result[i] := p_In[l_Length-i];
    END;

    PROCEDURE MiddleCase@1000000000(p_StringToConvert@1000000000 : Text[250]) ConvertedString : Text[250];
    BEGIN
      ConvertedString :=
        UPPERCASE(COPYSTR(p_StringToConvert, 1, 1)) +
        LOWERCASE(COPYSTR(p_StringToConvert, 2));
    END;

    BEGIN
    END.
  }
}

Since we don’t do anything evil here my only advice is to initialize every return parameter with a default value. This seems to fix the bug.

    PROCEDURE ReverseString@5128509(p_In@5128502 : Text[1024]) Result : Text[1024];
    VAR
      i@5128500 : Integer;
      l_Length@5128501 : Integer;
    BEGIN
      Result := ''; // Init return value – this fixes the issue!
      l_Length := STRLEN(p_In) + 1;

      FOR i := 1 TO l_Length - 1 DO
        Result[i] := p_In[l_Length-i];
    END;

Interestingly I didn’t find a smaller sample which reproduces this memory issue.

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

Ziele des internen Dojos

Da wir in der tagtäglichen Arbeit mit Microsoft Dynamics NAV entwickeln, wollten wir das Dojo auch mit Dynamics NAV und der Programmiersprache C/AL abhalten. Als wichtiges Ziel der Veranstaltung haben wir uns vorgenommen nach Test-Driven Development (TDD) zu arbeiten. Da TDD im NAV-Bereich (sicherlich mangelns Tools und Community) noch so gut wie unbekannt und unser selbstentwickeltes Test-Framework noch sehr jung ist, war diese Selbstverpflichtung für einige Team-Mitglieder in dieser strikten Form sicherlich noch Neuland.

Ablauf

Um die Messlatte für das erste Dojo daher nicht allzu hoch zu legen und mehr Fokus auf den Versionsverwaltung (git), die Test-Tools und die Kommunikation bzw. den Prozess selbst zu richten habe ich die relativ einfachen Katas FizzBuzz und DictionaryReplacer vorgeschlagen. Das Team hat sich dann für FizzBuzz entschieden.

Wie beim 1. NET CodingDojo in Hamburg gab es auch in Halle einige Startschwierigkeiten. Es scheint für viele Entwickler aufgrund der jahrelangen Entwicklungspraxis sehr schwer zu sein, tatsächlich zwischen Test und Implementierung zu unterscheiden.

Nachdem jedoch die ersten 3 Tests samt Implementierung geschafft und die explizite Trennung der Test- und Entwicklungsphasen erkannt wurden steigerte sich das Tempo des Teams enorm. So konnten wir dann auch Erweiterungen der Aufgabenstellung diskutieren und umsetzen.

Ich denke unser erstes msu Dojo war ein Erfolg und insbesondere die Wahl der Kata war für die erste Veranstaltung dieser Art ausgezeichnet. Für das nächste Mal wollen wir uns dann natürlich an eine schwierigere Kata wagen.

Randori-Stil

Da seit dem ”Dojo Deluxe” von und mit Ralf Westphal eine Diskussion über die Dojo-Formate aufgekommen ist, möchte ich hier auch noch meine Meinung dazu abgeben.

Da wir uns den Randori-Stil ausgesucht haben, gab es eigentlich vier verschiedene Rollen. Als erstes natürlich den Driver und den Co-Piloten, also eine Person, die die Tastatur bedient und eine die sagt “wo es lang geht”. Übrig bleiben dann in unserer Version noch der Rest des Teams als Publikum und ein Moderator. Da es die erste Veranstaltung dieser Art war, gab es noch sehr viele Hinweise vom Moderator. Bei nachfolgenden Veranstaltungen würde ich mir wünschen, dass der Moderator immer mehr in den Hintergrund rückt und die jeweiligen Co-Piloten deutlich aktiver werden. Das Publikum könnte noch mehr als das Kontrollorgan fungieren und auf Einhaltung der selbst auferlegten Richtlinien pochen. Als wichtigen Punkt für nachfolgende Veranstaltungen würde ich also noch eine klarere Trennung der Rollen sehen und dem Team mehr Eigenverantwortung auferlegen.

Randori-Stil vs. Tutorial

Die Befähigung des Teams den Entwicklungsprozess ohne starke führende Hand selbst zu kontrollieren ist für mich ein Kernziel bei einem CodingDojo. Ich denke hier unterscheidet sich der Randori-Stil (jedenfalls wie ich ihn bisher verstehe) stark von der Variante und den Zielstellungen die Ralf Westphal in seinem Dojo in München abgehalten hat. Wie Ilker Cetinkaya auch schon geschrieben hat ist Ralf’s Dojo-Variante wahrscheinlich näher am klassischen Workshop oder am Tutorial einzuordnen. Daran ist natürlich nichts falsch, ganz im Gegenteil: ich finde solche Workshops mit erfahrenen und charismatischen Sprechern extrem reizvoll. Insbesondere weil man bei einem Workshop aufgrund der intensiveren Vorbereitung des Sprechers in der kürzeren Zeit eine weit höhere fachliche Tiefe erreicht und man im Gegensatz zu klassischen Frontal-Vorträgen auch mehr Rückfragen stellen kann. Ralf hat sich dazu in seinem Blog ja auch intensiv und fundiert Gedanken gemacht.

“Einer weiß etwas und die anderen wollen es von ihm lernen”-Formate wie Ralf sie beschreibt sind also auch aus meiner Sicht sehr nützlich und bilden vermutlich sogar die Voraussetzung für ein Randori. Wenn nicht genug Leute im Raum bereits etwas über die zu benutzenden Techniken oder Methoden gehört haben, dann wird das Dojo bzw. das gemeinsame Lernen und Lehren vermutlich sehr zäh und der Moderator wird zum Hauptakteur. Es ist somit auch völlig einleuchtend, dass Ralf seine Event-Based Components natürlich nicht in einem Randori vorstellen kann. Das wäre dann wohl beim einem leeren FlipChart geblieben und ganz sicher auch eine Enttäuschung für alle Seiten.

Wenn jedoch hinreichend viele Leute bereits Erfahrungen mit der Materie gemacht haben, dann gibt es vermutlich auch unterschiedliche Interpretationen. Diese würde ich aber nicht so drastisch wie Ralf als “Unsicherheit” auslegen, sondern eher als Chance die Varianten gemeinsam zu diskutieren und Unklarheiten auszuräumen. Dabei muss es am Ende aber nicht zwingend einen Konsens geben.

Daher denke ich, dass auch ein Format mit weit weniger Moderation bzw. Anleitung wichtig ist, insbesondere auch um das bisher Erlernte in einer sicheren Umgebung zu testen und echtes TeamPlay zu trainieren. Den Begriff “Dojo” ausschließlich für solche freien Formate zu verwenden, ist wie Ralf beschrieben hat aus historischer Sicht wahrscheinlich eher ungeschickt. Dem stimme ich zu.

Ich denke hier hat Ralf hat meine Twitter-Kommentare evtl. auch etwas überbewertet (140 Zeichen sind natürlich oft auch missverständlich). Ich bin auch nicht dafür, dass alle Entwickler gleichgemacht werden sollen und es überhaupt keinen Lehrer gibt. Ganz im Gegenteil jeder soll sich einbringen, denn selbstverständlich sind immer unterschiedliche Wissengrade im Raum zu finden.

Dass alle etwas beisteuern klappt dann aber nur wenn die erfahreneren Entwickler sich auch mal darauf einlassen einen vorgeschlagenen “Irrweg” mit zu gehen und den Erkenntnisprozess so reifen zu lassen. Abgabe von Kontrolle ist zugegebenermaßen nicht gerade einfach, aber manchmal wird man vielleicht auch als alter Hase noch überrascht werden.

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

If you are interested in this book you can read the complete seventh chapter right here on navision-blog.de:

• Extending the Application using Microsoft Dynamics NAV 2009 (Part I)
• Extending the Application using Microsoft Dynamics NAV 2009 (Part II)

Chapter 6 (“Modifying the System”) is also available for download.

What the book covers

Chapter 1

The purpose of this chapter is a teaser introduction to get you excited about the product, what’s in it in general, and what’s in it as compared to previous versions, to give you a little taste of what’s coming up in the book, and explain what the fuss about this new release is all about.

Chapter 2

The RoleTailored client is the new user interface for users of Microsoft Dynamics NAV 2009, and it is completely different to the pervious versions. We’ll take you through the different components of the interface, introduce the terminology, explore the navigation components and page types, and teach you how to personalize the application to meet your own requirements using the extensive personalization features.

Chapter 3

Microsoft Dynamics NAV 2009 introduces a new paradigm to ERP. Instead of the system being focused on the forms that capture and present data and the functions the user can perform, the system is based around the individuals within an organization, their roles, and the tasks they perform. We cover how Microsoft researched the roles and explore the departments, roles, and tasks that have been identified in the Microsoft Dynamics Customer Model. We also show the reader how to assign the standard roles to users, how to create new roles, and how to allow departmental super users to configure the application for their role so that the change is applied to all users with the same profile.

Chapter 4

Microsoft Dynamics NAV is not a product with a Next-Next-Finish type of installation, and it takes a lengthy project to deploy it successfully. We focus on the six phases of the implementation process, and explain each phase with detailed dos and don’ts for a typical implementation. Based on the Dynamics Sure Step implementation methodology with advice liberally sprinkled throughout, special attention is given to new features of Microsoft Dynamics NAV 2009, and where the new capabilities must be taken into account to make most out of the implementation project.

Chapter 5

Every implementation of Microsoft Dynamics NAV 2009 will require the system to be configured to meet the needs of the business. This chapter tells the implementation consultant how to do this from a core financials perspective and provides valuable information that will allow developers to understand more about the application they are changing. We cover basic accounting for programmers, dimensions, and posting groups, and how to use the Rapid Implementation Methodology (RIM) Toolkit to speed things along.

Chapter 6

Hardly any standard system can fit the needs of a business out of the box. Either the customer must shape their processes to match the system, or the consultant must shape the system to match the processes, and usually the latter prevails. This chapter explains the process of modifying the system, how to design a viable data model, and how to design and develop a functional user interface for both RoleTailored and Classic clients, without writing any code.

Chapter 7

The three-tiered architecture of Microsoft Dynamics NAV 2009 and native Web Services Enablement open up a whole new world of possibilities for NAV implementations. We cover some of the many possibilities for extending the application, allowing the consultant and developer to understand the technologies that are available and their respective design considerations. Our practical examples introduce the NAV programmer to the world of .NET and show how you can use the information available on the internet to develop your own killer .NET add-ons.

Chapter 8

There’s much more to development than programming. It starts with understanding what customer really needs, and usually extends way beyond the system being deployed to a test environment. This chapter focuses on the development phase, and what it takes to get from a concept to a live and working solution.

Chapter 9

After the system goes live, or as it grows, there are periods when new problems may arise, and often their source is far from obvious. This chapter explores the tools and techniques available for detecting problems, pinpointing the source, and helping to remove them from the system quickly and painlessly. It explains how to debug the Service Tier, how to troubleshoot performance issues, what can be done to avoid problems, and how proper planning before design can help to get it right the first time.

Chapter 10

Our sample application focuses on requirements gathering, functional specification creation, solution design, and the eventual build of a prototype. We look at how a business problem can be explored using techniques such as interviewing, use-case modeling, and object-role modeling to create a solution design that can be molded into a working prototype.

If you want to get more information about the book visit: http://www.packtpub.com/implementing-microsoft-dynamics-nav-2009/book

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

“Dieses Release beinhaltet folgende Dateien:

• Klassische fdb Datenbank
• MDF Datenbank für SQL Server
• Onlinehilfe für den Zahlungsverkehr (DEU und ENU)
• Changes.doc für Zahlungsverkehr und Kostenrechnung

Hinweis:
Die Objekte für den Zahlungsverkehr beinhalten auch die SEPA Funktionalität.
Die Onlinehilfe für die Kostenrechnung wird umgehend nachgereicht.”

[Quelle Partnersource]

Weitere Links:

• Deutsche Vollversion von Dynamics NAV 2009
• Update Toolkit
• Launch Portal für Microsoft Dynamics NAV 2009

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

Unter anderem werden auch folgende Themen beschrieben:

• Install and Configure Microsoft Dynamics NAV 2009
• Using the Form Transformation Tool
• Working with Web Services
• Improving Application Performance

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

Weitere Information sind im Launch Portal zu finden.

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

Dummerweise ist der generierte C#-Code, wie das bei generiertem Code eigentlich immer der Fall ist, nicht gerade “optisch schöner” C#-Style und hat auch nur noch wenig mit dem Original-C/AL-Code zu tun – ist aber immerhin lesbar.

Das ist ein wirklich interessanter Ansatz und erlaubt mit etwas Geschick auch UnitTesting für NAV 2009. Dafür werde ich demnächst mal versuchen ein kleines Beispiel zu bloggen.

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

Interessant sind aber auch die schon etwas länger existierenden Artikel, die im NAV Developers Blog veröffentlicht werden. Dort wird z.B. auf die Erstellung von Key Performance Indicators in NAV 2009 eingegangen.

Claus Lundstrøm setzt sich in seinem Blog mit dem Thema Drop Down Windows in NAV 2009 auseinander und hat jetzt auch eine Liste der in NAV 2009 verfügbaren Icons veröffentlicht.

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.

Das “Microsoft Dynamics NAV 2009 Marketing Beta Release” ist ein Paket aus einem Virtual PC-Image von Microsoft Dynamics NAV 2009 (Marketing Beta) und einer Reihe von zugehörigen Dokumenten. Dabei handelt es sich unter anderem um eine Hilfedatei mit “Walk-through scenarios from the User Documentation” und Powerpoints zu Web Services, Reporting und dem Page Designer in NAV 2009.

Mit der Veröffentlichung der Marketing Beta (CTP4) ist nun auch die Zeit der Verschwiegenheitsvereinbarung (NDA) der CTP3 vorbei und es kann ausführlich zu technischen Details von NAV 2009 gebloggt werden.

Ich fange bei dieser Gelegenheit mal mit den zugehörigen Dokumenten der Marketing Beta an und werde in späteren Postings natürlich auch auf die CTP4 selbst eingehen.

Bei dem Hilfedokument handelt es sich z.B. nur um eine Vorabversion der eigentlich NAV 2009-Hilfe, so dass einige Bereiche nur als Platzhalter angelegt sind.

Insgesamt muss man aber sagen, dass die Hilfe (auch jetzt schon) wesentlich umfangreicher ist, als das bisher bei Navision-Hilfen der Fall war. Gerade die Bereiche zum Thema Reporting und Form Transformation sind auch schon sehr detailliert ausgeführt. Dabei setzt man nun z.B: auch verstärkt auf Ablaufdiagramme:

Weiterhin ist geplant die NAV-Hilfe mit ins MSDN zu integrieren, so dass Dokumentationsupdates leichter zur Verfügung gestellt werden können. Ein weiterer netter Nebeneffekt vom MSDN ist natürlich, dass man dann mit der Suchmaschine seiner Wahl die Hilfe durchsuchen kann.

Zu den drei Powerpoints gibt es eigentlich nicht viel zu sagen, außer das sie sich in ihrer Aussagekraft sehr stark unterscheiden. Die PPT zum Thema WebService zum Beispiel zeigt relativ detaillierten Quellcode, während die zum Thema PageDesigner überhaupt keine Informationen enthält. Lustigerweise steht bei letzterer Präsentation “Mircrosoft Confidential” drunter.

Zusätzlich gibt es derzeit noch ein Dokument mit den Systemvoraussetzungen und eins mit den Release Notes bzw. Known Issues der CTP4.

©2010 Rash thoughts about .NET, C#, F# and Dynamics NAV.. All Rights Reserved.