Dynamics AX Blog - Axapta 3.0 - Beiträge vom Dezember 2009
RSS-Feed dieser Version
Bearbeiten von Formularfeldern beschränkenHinweis: Zu diesem Thema ist eine aktuellere Version verfügbar Sollen in einem Formular nur bestimmte Felder zur Bearbeitung freigegeben sein, kann man die Eigenschaft allowEdit sämtlicher Felder der DataSource der Tabelle entsprechend umsetzen. Einfacher geht’s mit folgendem Codebeispiel, welches in der init-Methode der DataSource eingebunden wurde und - im konkreten Fall in der Tabelle SalesLine - nur bei einem einzigen Feld die Bearbeitung erlaubt. public void init()
{ sqlDictionary sqlDictionary; ; super(); while select sqlDictionary where sqlDictionary.tabId == tableNum(salesLine) && sqlDictionary.fieldId != 0 { if(sqlDictionary.name != "dataareaid" && sqlDictionary.name != "recversion" && sqlDictionary.name != "recId" ) { salesline_ds.object(sqlDictionary.fieldId).allowEdit(false); } } salesline_ds.object(fieldNum(salesLine, blocked)).allowEdit(true); } Getestet in AX 3.0 |
PageFooter sind nicht immer dort, wo sie sein sollten
04.12.2009Microsoft Dynamics AX (Axapta)
Ich kenne kein einziges AX-Projekt, in dem nicht zumindest einer der Berichte Auftragsbestätigung, Ausgangslieferschein oder Ausgangsrechnung angepasst worden sind. Und deshalb stolpere ich auch immer wieder über das selbe Problem: Man erweitert einen Bericht (Report) um einen PageFooter, der aber nicht auf jeder Seite angedruckt werden soll. |
|
|
|
|
|
|
Schon einmal einen Base Enum in Dynamics AX erstellt? Oder einen bestehenden erweitert?
Ja?! Dabei auch auf das folgende geachtet?
.) Das erste Element eines Base Enums sollte den Wert 0 aufweisen und dieser sollte "Undefiniert", "Kein", "Unbekannt" oder ähnlichem entsprechen. Vor allem wenn man den Base Enum später in Tabellen verwenden möchte, die bereits Daten enthalten.
Selbst wenn man davon ausgehen kann, daß man einen solchen undefinierten Zustand nicht benötigt, sollte man die 0 reserviert halten, sprich der erste "echte" Wert des Base Enums sollte 1 entsprechen.