Dynamics AX Blog - Beiträge vom November 2015

In diesem Blog-Beitrag habe ich schon einmal beschreiben, wie man in Dynamics AX das Label eines Dialogfeldes auslesen kann, das folgende Beispiel macht das gleiche in Dynamics AX 2012.

static void getDialogFieldLabel(Args _args) 
{ 
     Dialog dialog = new Dialog(); 
     DialogField df_Project; 
     DialogField df_AmountMST;
 
     str getLabel(DialogField _df) 
     { 
         formStringControl fsc; 
         
         fsc = _df.fieldControl(); 
         
         return fsc.labelText(); 
     } 
      
     df_project   = dialog.addField(extendedTypeStr(ProjId), "Mein Projekt"); 
     df_AmountMST = dialog.addField(extendedTypeStr(AmountMST)); 
     
     dialog.run();

     info(getLabel(df_project)); 
     info(getLabel(df_AmountMST)); 
}

Vor kurzem benötigte ich in einem View, dessen Datenquelle eine abgeleitete Tabelle (im Beispiel EcoResDistinctProductVariant) enthielt, die TableId dieser Tabelle als Feld. Also erstellte ich ein neues Feld, wählte die Tabelle aus und das Feld TableId aus dem DropDown.

Der View

Eigenschaften des Feldes TableId1

Leider brachte dies nicht das erwartete Ergebnis, wenn ich den View öffnete, wurde das Feld immer mit NULL ausgegeben.

Mit setPrefix() kann man in die Infolog-Meldungen ganz einfach Verschachtelungen erzeugen.
Was ich bisher noch nicht kannte ist, daß man solche Prefixes direkt in die Meldung integrieren kann, indem man die eigentliche Meldung um die gewünschte Überschrift und das Steuerungszeichen für einen Tabulator erweitert.

static void inlinePrefix(Args _args)
{
    setPrefix("Inhaltsverzeichnis");
    info("Kapitel 1\tSeite 1");
    info("Kapitel 1\tSeite 2");
    info("Kapitel 1\tSeite 3");
    info("Kapitel 2\tSeite 4");
    info("Kapitel 2\tSeite 5\tAbschnitt 1");
    info("Kapitel 2\tSeite 5\tAbschnitt 2");
    info("Kapitel 2\tSeite 6");    
}

Das Infolog des obigen Jobs sieht wie folgt aus:

Eine häufige Anforderung im Projekt-Alltag ist es, Journale verschiedenster Art per Code zu erstellen. Darüber habe ich auch schon den einen oder anderen Beitrag verfasst.

Vor kurzem hatte ich eine ähnliche Anforderung, allerdings sollte dabei das Journal nicht gleich gebucht werden, sondern es sollte nur sichergestellt sein, daß diese Journale nicht unabsichtlich von anderen Benutzern verändert werden.

Und genau für diese Anforderung ist der folgende Code gedacht:

JournalTableData::updateBlockServer(
    prodJournalTable, 
    JournalBlockLevel::None, 
    JournalBlockLevel::InUse, 
    false);

Statt wie im Beispiel die Tabelle ProdJournalTable zu serren, kann auch die InventJournalTable auf diese Art & Weise gesperrt werden.