Greetings All.
This is how I approached the issue (and I apologize ahead of time for the length of this post, but I tend to like details because I walk away with a better understanding - so I prefer to explain things with that in mind).
Initially, I merely wanted to see what controls were available on the “NonConformance” form and I had assumed that a simple call to the “Controls” collection of the form object would show me ALL of the controls. That did not seem to be the case (at least in the manner I started coding the solution):
The results did not line up well with my expectations, as I had assumed I would see something related to the “Request Move” checkbox… and certainly more than 12 total hits.
My only recognition of “Sonoma” is that its a well-known county in California… or a race track also located in California… or that it’s a clothing line that typically distributes to JCPenney, so I tried to stick with results that seemed to be logical:
- windowDockingArea2
- windowDockingArea1
Ok. So, I decided to look for possible controls contained within those specific controls:
Gee… 1 control listed for “windowDockingArea2”. Again, not what I had expected.
I decided to go a bit deeper, taking a lead from Ken Nash’s example above:
… and deeper:
… and deeper:
Ok. Well, here, I started to get a clue that the nine (9) hits might correspond with the nine (9) tab panels contained within the “NonConformance” form module. But, I needed to validate that, so I went a bit further:
Great. Now I’m getting the actual names for the panel controls. Yet, I still need to work within the panel object to iterate through the controls on that level:
Terrific. Now I’m down to the group controls level. At this point, I made the assumption (based on the object tree on the form customization view) that the checkbox control would reside within the just-discovered group controls, but I noticed that Epicor did not maintain standard nomenclature for the groups. So, I merely looked at each group name and created a conditional statement against those names. Before adding that code, I knew that I did not have to continue looking for specific control names once my existing code arrived at the “dockableWindow” control level, because this level represents the tab panels (all I need to do is hunt through those panel controls). So, I went back to modify the code a bit, as explained here:
I replaced that code with the conditional statement that identifies only the “Material Reporting” group and included the logic necessary to isolate and modify the properties of the “Request Move” checkbox:

In any event, this works.
Efficient code? Nope - never said it was. But based on my level of skill and knowledge, this is how I approached it.
I will also concede that there are support issues with this approach, especially if Epicor decides to change their naming conventions for controls contained within the “NonConformance” form module. That’s a large drawback in this solution that you’d need to be aware of – because that would force you to edit the code with the updated nomenclature.
I was hoping to implement something like what Daryl Hewison had illustrated, but I didn’t see how iteration below the form level (where my code found only 12 controls in the collection) would have gone deeper.
If you decide to use this sort of approach, just be aware that there is vulnerability should you upgrade to a different version of Epicor. But - if you’re documenting your customizations well, then you’ll be aware of the need to review this type of customization against any possible nomenclature changes initiated by Epicor in future versions.
[By the way, we’re limping along here on v10.1.400.14]