At it's core, the table is a simple unbound  table:

It allows you to specify the number of columns/rows and as an option to show gridlines. The table allows you to indicate which types of controls can be hosted within each cell:

A powerful feature of the table is in its ability to vary the input type per CELL. This is done by the developer adding an edit control method that returns the modeled control type that should be represented in that cell

Combined with the capabilities of the individual controls, different visuals and interactive uses are possible.

With the Table control, the developer will be able to:

• Model a table control on a form
• Set number of columns and rows
• Set height and width
• Add supported contained controls for interaction within each cell
• from the AOT, select and right click on the control- select add control
   
• On a cell by cell basis, the control calls the editcontrol method to learn what control to host in the cell

FormControl editControl(int column, int row){

    if ((column == 2) || (column == 4)){

        if (row > 1){

            return intEdit;

        }

        else

            return editline;

    }

    else{

        return editline;

    }

}

static str getResourceString(SysElementName _resName)
{
    resourceNode resourceNode = SysResource::getResourceNode(_resName);
    container stringContainier;

    if (!resourceNode)
    {
        return '';
    }

    resourceNode.AOTload();

    stringContainier= SysResource::getResourceNodeData(resourceNode);
    return conPeek(stringContainier, 1);
}

The string can contain default data, XML, HTML or whatever else your application needs.

You'd think the sizing of a column in a grid would be a fairly straightforward task. In Dynamics AX2012... it is, as you shouldn't ever have to care as the Dynamics framework implements a pretty sophisticated algorithm to attempt to size the columns in the grid to effectively show your data. If you're reading this blog post you are obviously among a very few select human beings.

1) You are enough of a nerd that you want to know how Dynamics AX sizes its columns, only because you want to know all there is to know about Dynamics AX.

2) You stumbled upon this post looking for something else, and you aren't sure why you are still reading this.

3) You are a friend or family member and you are being polite and reading this because I sent you a link.

4) You actually have a problem to solve and can't understand why your changes aren't effective in sizing the grid columns.

If number 1 or 4 apply to you, continue reading, otherwise you have my permission to go walk the dog.

How does it work?

Both the developer/customizer and the end user have the power to explicitly size columns, but without intervention, the Dynamics AX grid control will actually inspect the data that it is about to show, and size the column to make sure that most/all of the data is visible. That's right... the grid will size columns dynamically depending upon the data. If that wasn't enough... if the size of the column isn't wide enough to show the corresponding label... then it will also take that into account. For example if all of the data in a column were a Two -Character US State abbreviation such as "CA" then the grid would initially set it's size to 2 characters wide. However, it also looks at the column label... say for example "State." The grid also accommodates the label and ensures that the grid column width is wide enough to show the label as well. So, in this case the width of a "state" column would be 5 characters wide. As a developer, if you are authoring a control, you can override the algorithm that looks at the data by setting an explicit size on the EDT or Control associated with the data. However, min/max and label will still govern the size. That is, you cannot set an explicit width of 3 characters for a state and expect it to be 3 characters wide, as the grid layout engine will apply the min/max/label rule and make the column 5 characters wide. The assumption is that there isn't a scenario, where by default you want to show a column that is 0 characters wide, nor wider than the maximum width nor one with an truncated label. In the end, the end user is the one who may overrule all. It's his screen, he gets to decide if he needs a description column 20 characters wide, 40 characters wide or 80 characters wide. He does so by simply and interactively sizing the column and it will be "remembered" from session to session.

The following flow chart attempts to explain the algorithm. That's all for now. You may go walk the dog.

 

 1.       Verify that the table that will hold the Foreign Key to the DimensionAttributeValueCombination table is a datasource on the form.

2.       Drag the LedgerDimension field from the datasource to the desired location on form design. This should add a SegmentedEntry control at this location on the form with appropriate DataSource and ReferenceField property values. Alternatively this can be done by adding a SegmentedEntry control to the design and manually setting the DataSource and ReferenceField properties.

3.       Override the following methods on the form.

Code Example: Methods overridden on the form

4.       Override the following methods on the SegmentedEntry control instance in the design.

Code Example: Methods overridden on the SegmentedEntry control instance

5.       override the following method on the datasource field that backs the SegmentedEntry control.

Code Example: Method overridden on the datasource field that backs the SegmentedEntry control

• The Microsoft .NET team has extended the .NET API by introducing a Chart control.
• Microsoft Dynamics Client enables simple use of this control by creating a new X++ wrapper class for the MSChart control: Graphics.
• The Microsoft Dynamics Client has introduced a new companion control for the MSChart control: The Chart Toolbar control.

You can define an X++ method and designate it as an event handler for events raised by your control. In this example, we're adding a form method.
While it's possible to use class methods, it's recommended that you use form methods. 

In this example, we're passing in the ManagedHost instance... if you do this, a screenshot of the control will be taken, if no control is passed, no screenshot is taken.

 2) Hook up the managed event handler

It is recommended that you define all of your event handlers in the init method of the form.

 // Glue code:
Hook the managed controls event to an X++ Event Handler:

   ManagedHost.add_SelectedDateChanged(new ManagedEventHandler(this,'managedEventHandler_RecordDateChanged'));

Note on performance: Task recorder event SysTaskRecorder_Eventing::fireUserSpecified() is a expensive operation. It creates a XmlDocument and takes a screen capture. So we should fire the event
only when task is being recorded and should not call it for normal forms execution. To check if task is being recorded, use SysTaskRecorderEventManager::parmRecording() and if true, then call the
event.

I am not happy with my hippocampus. I'm content with the way it looks - I've had a sufficient number of head X-ray's in my life that it has a nice tan. I'm not happy with it because I fear that I've trained it to be really efficient. In fact, it filters much more than I'd like it to. Instead of filtering, I'd like it to do more long-term storing of data. 

I heard a quote the other day from a supposed industry expert. He said...  "I was literally drowning in a sea of data." After I finished snorting soda out of my nose, I wondered what that person's obituary would read had that event been fatal:

Industry veteran drowns in sea of data. Forensic database experts claim his data flotation device failed to inflate. 

I think what he meant was that he was figuratively drowning in a sea of data. Grammatical issues aside, I think he had a point. Data creation and data consumption are growing at a shocking rate. So much so that we've exceeded our ability to analyze and manage it. Part of the reason why it's so hard to manage is that we have a fixed way of thinking about our data.

I recall a simpler time when reading a book or coming across information in a newspaper when I would be introduced to a historical event or scientific phenomena. Growing up, we didn't own an encyclopedia. (Okay, my mom was a bit of a hypochondriac, and we had a set of medical encyclopedias - but none were applicable to my problem.  In those days, my experience or understanding was limited to my knowledge as of that time and place. My perception of the material was limited by my historical ability to relate it to some other event or logic known to me at the time. Today it's different. The Internet has become a large part of my learning experience. I sat down over the weekend to finish reading Dan Brown's, "The DaVinci Code." It took me much longer to read this book than it would have without the Internet. I found myself setting the book down and picking up my laptop to scan the Internet for information on the historical ramblings of the book. Dan Brown discusses different meanings (real or perceived) in several well known paintings. I had a more fulfilling adventure reading this book, given that I could stop and study the information presented, via the Internet. In the past, my perceptions and interpretations of the book would have been different - limited by my ability to relate the material to past experiences.

Human learning is constrained by our ability to remember facts and details. I was able to experience the book more richly because I had the ability to analyze and research detailed facts that the author outlined. Some of that information had certainly crossed my path before. For example, I've seen DaVinci's "Last Supper," yet I could not recall colors, placement of objects or people in the painting as described. Why is it that some people have "photographic memories." I recently asked my friend Tim a question about Intel architecture. He went to his white board and drew a schematic that he had seen on a web site several months earlier. I went back to my computer and looked up the schematic and discovered that his drawing was perfect, including numeric details. Since I can't recall what I had for supper last night, it's clear to me that I could benefit from a supplemental digital memory.  I've heard futurists describe the next phase of human evolution as one that includes integration with machines. If you can get thoughts of Robocop and the Six Million Dollar Man out of your head, there's room for real discussion here. The evolution of faster processing and larger data stores is historically charted and can be accurately predicted out into the future for several years, demonstrating that the growth of computational power and data store will eventually lead to the ability for a person to store virtually every experience that they have.  If this is so, how will we manage this? How will I interact with this data? In a Virtual Data Reality, does data have pre-determined categories and shape, like real world objects? Who defines this data DNA (self-describing properties and behavior), and how does it get defined? If data has DNA, is it then possible to create natural interaction and association between data?  What kind of software is necessary to manage and interact with self-describing data? Today's relational models have strict and confined definitions of data and cryptic methods of retrieving that data. The gap between object oriented definition of data and relational storage hasn't been bridged in a manner that makes natural association and interaction possible. Object data needs to be managed by the application developer and marshaled to and from a relational store.

To be able to bridge the object/relational gap, a set of tools is needed with which the developer is allowed to think of data in terms of objects. The objects should be defined in terms of not just behavior, but also descriptive attributes (read: metadata).  Storage systems should be able to recognize attributes and create natural association and composition between objects. In this world, the developer should be able to create a person object and that person object should be able to relate to other person objects with similar attributes. The first step in this evolution is to create a development infrastructure in which data can easily be described as objects and then persisted and retrieved as objects without restrictions or knowledge of a particular data repository.

We're working on tools that may someday provide this world for developers. Given our current limitations in processor power and storage, the associations and compositions will be defined by the developer (read: hard wired) providing a limited, but functional set of data relationships.  Additionally, given the current state of object database technology and the need to integrate with existing relational data stores, the developer should be able to create mappings between object and relational data.  When we do indeed have processing and storage bandwidth, the object infrastructure and tools that we provide will be there to provide the fundamental building blocks for a Virtual Data Reality.

I'd like to ramble more and provide more details, but I can't remember what they are... damn hippocampus.

 This posting is provided "AS IS" with no warranties, and confers no rights.