How-to: Tree lookups in Dynamics AX reference group controls, part 2

This is something that keeps coming up on different projects, so I’d like to share how I usually do this.  There are some examples out there which try to describe a very generic solution which can be used in almost any case.  However, such solutions very quickly become very complex.  To keep things simple, I have tried to keep this example fairly specific but adaptable to a wide range of circumstances.  Specifically this example is using a fixed hierarchy structure with a fixed number of levels, each of which will be represented by a different table.

Last time I introduced the data model that will sit behind the tree lookup.  This time I’ll show how to build the tree on demand to improve performance, and then how to build the actual tree lookup form.

Continue reading “How-to: Tree lookups in Dynamics AX reference group controls, part 2”

How-to: Tree lookups in Dynamics AX reference group controls, part 1

This is the first part of a multi-post series that explains how to do a tree lookup in a reference group control on an AX form.

It’s simple, just look at those trees up there…

Oh, seriously…

This is something that keeps coming up on different projects, so I’d like to share how I usually do this.  There are some examples out there which try to describe a very generic solution which can be used in almost any case.  However, such solutions very quickly become very complex.  To keep things simple, I have tried to keep this example fairly specific but adaptable to a wide range of circumstances.  Specifically this example is using a fixed hierarchy structure with a fixed number of levels, each of which will be represented by a different table.

I’ll show how to build the lookup, how to load the tree items on demand to speed up the loading times as well as how to properly select and return the selected record.  I’ll also show some suggestions for how to build the reference group properly so it is easy for the user to understand the information presented to him/her and to understand what to do.

This first part of the series shows how to set up the tables and their relationships.

Continue reading “How-to: Tree lookups in Dynamics AX reference group controls, part 1”

Retrieving Double fields from ADO.NET in CIL code

I recently wrote about how to retrieve DateTime fields from ADO.NET.

If your code is running in CIL, there are some more gotchas, as some conversions that work just fine in X++ will fail when running in CIL.

If you try to retrieve a Double value from ADO.NET and assign it to a record buffer field, the code may run just fine in X++ but when running in CIL you may get this error message:

Error executing code: Wrong argument types in variable assignment.

To work around this, use a local bounce variable of type System.Double, then assign that to the record field like this:

System.Double clrDouble;

...

clrDouble = reader.get_Item( "UNITPRICE" );
item.Price = clrDouble;

There are likely to be other data types causing problems in CIL mode, so I’ll keep posting as I come across them.

Arduino traffic lights simulator, part 4

Welcome back.

This time I will show the basics of how to connect a push button to the traffic light simulator circuit and how to read it from within an Arduino sketch.  If you haven’t read parts 1, 2 and 3 yet, I recommend you do so first as it will make it easier to follow the examples.

For this demonstration, we’ll use a simple push button like this.  They have four pins, connected together two by two.  Usually the two pins on either side are connected together, and pushing the button will connect them to the two pins on the other side.  If you’re in doubt, use a multimeter to check which pins are connected together.

Additional parts needed this time:

Continue reading “Arduino traffic lights simulator, part 4”

Arduino traffic lights simulator, part 3

In the previous two parts, I have shown how to build a 2-way traffic light and how to write a sketch to control it.

This time we’ll rewrite the sketch to use state tables.

In microcontroller programming, we are often dealing with a set of well defined states.  State tables describe what each state means, rules for transitioning between the different states, for what is allowed and what is expected.  Keeping this in a set of tables helps keep the code simple by avoiding a big, tangled mess of if-else statements.  This, in turn keeps the code smaller so we can do more with the rather limited memory on the microcontroller.

Continue reading “Arduino traffic lights simulator, part 3”