Resolving Ignition 7.7.4 Create Data Type NullPointerException

The fault shows up in the Designer tag browser. You select a group of tags, right-click, choose Create Data Type from Selected, and a dialog titled Error loading tags appears with a java.lang.NullPointerException in the details. No data type editor opens.

The pattern is specific:

• Select only plain tags, and the command works. A new data type editor opens as expected.
• Add even one instance of an existing data type (UDT) to the selection, and the command throws the exception every time.

The reported case ran Ignition 7.7.4 (b2015033012) on Java 1.8.0_45 under Windows 7. The data types and the plain tags sat together in the same folder.

Skip the Fixes That Waste Time

A Designer exception makes people start with the client environment. For this fault, those fixes fail. Here is why each one does nothing:

• Reinstalling or downgrading Java. The stack trace breaks inside Ignition classes (com.inductiveautomation.ignition.common.sqltags...). The JVM frames below that are only Swing event dispatch, which is the mouse click reaching the menu handler. The JRE did not fail. Changing the Java version will not change the result.
• Restarting the Designer or the Gateway. The exception is deterministic. It depends on what you selected, not on stale state. A restart gives you the same exception with the same selection.
• Clearing the Designer launcher cache or re-downloading the client. The cached jars are the same 7.7.4 code. You get back exactly the code that failed.
• Deleting and recreating the UDT instances. A fresh instance is still an instance. The failure depends on the tag being a UDT instance, not on a corrupt instance.
• Editing the source data type definition. The parent definition is not what breaks. The walk over the instance members during type creation breaks.

That is not the fault. Start here instead: look at what is in the selection.

Read the Stack Trace: Where It Breaks

The top four application frames tell the whole story. Read them from the bottom up:

The mechanism works like this:

• A plain tag carries its own configuration. Copying its attributes into a new definition is a flat operation.
• A UDT instance is different. Many of its member properties come from its parent type. They are not stored locally on the instance.
• The addTagMembersDeep routine descends into the instance members and tries to set each attribute on the new definition.
• At least one attribute resolves to null during that deep copy. setAttribute does not guard against the null, so the action fails before the editor opens.

The whole operation happens in the Designer before anything is written to the Gateway. The failed attempt leaves no partial data type behind. Check the folder anyway before you retry. The verification section covers that check.

Match the Symptom to the Cause

The last two rows describe possible behavior in builds after 7.7.4. The next section explains why.

Decide Whether Nesting Should Work on Your Build

This is a known defect in 7.7.4. Two different intended behaviors exist on record for the fix, and they lead to different workflows:

1. Block it. Creating a data type from a UDT instance is disallowed. The menu item should be grayed out and unselectable whenever the selection includes an instance. A bug report was filed to add that interlock in a future release.
2. Make it work. For the simple case, meaning a folder of plain tags plus instances of an existing type, the command should succeed. The failure is a minor defect in the member copy. With that defect corrected, the operation behaves correctly. This fix was targeted for 7.7.5 final, pending confirmation.

Do not guess which behavior your build has. Decide it this way:

• On 7.7.4, neither behavior is present. The command throws. Use the workaround.
• On 7.7.5 or later, read the release notes for a tag or UDT entry that covers Create Data Type from Selected. Then run the test in the verification section on a scratch folder. The result tells you which path your build implements: grayed out, nested correctly, or flattened.

Work Around It on 7.7.4

Build the parent type without the instances in the selection. Then add the nested type members inside the editor. Nested data types are supported in the data type editor. The only broken piece is the shortcut that builds a type from a selection that contains an instance.

1. Record which UDT instances were in the original selection. Note each instance name, its data type, and any parameter values it uses. Parameters often drive OPC item paths.
2. In the tag browser, select only the plain tags. Leave every UDT instance out of the selection.
3. Right-click and choose Create Data Type from Selected. The data type editor opens.
4. Name the new data type. Define any parameters that the nested members will need, such as device name or base address.
5. Inside the new definition, add a member that is an instance of the existing data type. Add one for each instance you recorded in step 1. Use the same member names so paths and bindings stay predictable.
6. Bind the parameters of each nested instance to the parameters of the new parent type, or set them explicitly. Do not leave them at defaults, or the nested members may point at the wrong addresses.
7. Save the data type.
8. Create one instance of the new parent type in a test folder. Point it at a live device and confirm it before you replace the original loose tags.

Pitfall: the original plain tags and instances stay where they were. Create Data Type from Selected builds a definition. It does not convert the existing tags in place. Any window bindings, alarms, or history that reference the old paths must be repointed when you swap in the new instance. Do this during a planned change, not on a running production project.

Fix It With an Upgrade

If you need the one-click path with instances in the selection, upgrade the Gateway. The Designer is served from the Gateway, so the Designer version follows the Gateway version.

1. Take a Gateway backup before you upgrade.
2. Upgrade to 7.7.5 or a later release. Confirm in the release notes that the Create Data Type from Selected defect is listed as fixed.
3. Relaunch the Designer so it picks up the new client jars.
4. Run the verification test below before you rely on the command in a live project.

Do not upgrade a production Gateway only to fix this. The workaround produces the same data type structure. The upgrade is a convenience. Schedule it with your normal patch cycle.

Verify the New Data Type

Run this test on a scratch folder. The failure is deterministic, so one clean pass per build tells you everything.

1. Create a scratch folder. Add two plain memory tags and one instance of an existing data type.
2. Select all three and run Create Data Type from Selected.
3. Read the result:
   • Error loading tags with the NPE: the defect is still present. Use the workaround.
   • Menu item grayed out: your build blocks this operation. Use the workaround. This is intended behavior, not a failure.
   • Editor opens: continue to step 4.
4. In the editor, expand the member that came from the instance. Confirm it is a nested instance of the original type and not a set of loose copied tags. A nested member keeps inheritance, so later edits to the original type reach it. Flattened copies do not.
5. Save the type. Create one instance and confirm every member shows good quality and the expected value.
6. Change one property on the original (child) data type. Confirm that the change appears in the nested member of the new instance.
7. Delete the scratch folder and the test type.

For the manual workaround path, run steps 4 through 6 against the type you built by hand. The inheritance check in step 6 is the one that catches a member added as a copy instead of as an instance.

FAQ