a customer wants to a customized "LedgerTransAccount" Form
They want to have a checkbox to activate the "Transaction Origin". If the checkbox is marked true the grind on the form should show fields for "Module" and LedgerAccount of the Transaction Origin.
So it must be something dynamic because you do not know how many fields you have to add
How can I realize s.th. like this?
*This post is locked for comments
Thanks Martin.
Currently, we are thinking of developing this with ASP.NET using ODATA to pull in the data we need, as we need user interaction ( hence cannot take the report approach) and also the user needs a view of all the SOs and the distinct Items corresponding to those, in order to decide on the SO fields to update.
Please let me know if any other design approach is possible ( if any ) inside D365 FO.
My opinion is still the same - I wouldn't do it. I would use one of the alternative design I mentioned in my reply, which are better suited for relational databases and AX UI.
Martin,
I had a similar requirement of adding columns dynamically onto the Form Grid, and also filling the Grid at runtime.
Basically i need to show a set of sales orders and all distinct items in that sales order ( as columns) so that the user gets to know what quantity of a particular item the sales order contains.
With that view, the user needs to be able to multi select the rows and update the sales order fields.
My question here is, with the form extensibility features of D365 for finance and operations, is it possible to get a workable solution for this.
Thanks,
Swetha K Desai
My initial thought was that a scroll bar would be invoked and since most of the items use only a handful of colors it would be OK. However there is an option for all colors and I agree with you it would be unusable.
Thanks so much for the prompt reply Martin, it has helped in my decision to steer the user to a report solution.
Bill
There is no way how to make a grid with hundred columns that will be usable. It would be way too wide and complicated.
Instead of showing a long list of columns (especially if it's dynamic), show another grid, or a list, with rows. Therefore instead of adding (revealing) X columns to a grid at runtime, you'll show another linked grid with X rows, as usual in Dynamics AX.
If it's for reporting purpose, a report really may be a better choice. Matrices, cubes and so on give you options that you don't have with AX forms.
Did you end up getting this to work? I'm looking at a similar challenge where there could be hundreds of results (colors) returned from a query that need columns built in the grid. There also could be new results derived so I'm thinking that making columns visible/not visible will not be an option.
I've been looking at the SysTableBrowser form and supporting class. The form (a derivative of InventStatistics) already uses a temporary table so we'll see how that goes. Otherwise I might be selling a report!
Thx for the hint. I still didn't manage to get it running but I can try to find a way out of this. (joining by the way doesn't work (error))
Add another field to your TempDB table of type RefRecId, named RefRecId if you want. Put the RecId of the main record in the form in RefRecId, and then make RecId to RefRecId a relation in the AOT between the two tables, and enable the Join on the TempDB table data source on the form. Then each record in the TempDB table will point back to exactly one record in the form.
Hi Brandon
Sounds pretty good to me but how can I "connect" the entries in the tmpTable to the record in the grid?
Actually I fill the tmpTable with the data but I do not know how I can link the tmpdata with grid line 1, line 2, etc.
I've done something like what I think you're suggesting. It's never pretty.
Basically, I created a temp table with a series of numbered fields, i.e. Item1, Text1, Item2, Text2, Item3, Text3, etc. The problem up front with this approach is that you just have to decide on a maximum number of fields to support and live with it. Don't even think about adding fields to a temp table during runtime.
Adding the temp table as a data source to your form is easy. Deciding how many of those fields to hide or show is also pretty easy. You'll probably add them all as fields in the grid up front, and just change .visible() as needed on each field in response to your "show" checkbox.
Populating the data is a whole other issue. Pivoting rows into columns is just coding.
It's certainly possible to actually add fields to a grid at runtime, and they can be bound to fields or data methods. I don't see the advantage of adding them at runtime when it's just easier to show/hide them dynamically. I'm also not sure how you could add a variable number of controls to the grid bound to a display method, since you can't specify parameters for the data method. You could do it with many different data methods (display methods), but it's messy.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,235
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (