Sheet customization, BAQ Grid, Event handling / subscription, C# design

Before I run head-long with a C# customization design, as if that oncoming light is just the open-end of the tunnel, I thought to post it up and plead for a peer review. I assembled quite a bit of related information from posts on this site and then did my own thing. I am concerned, with limited experience, that I might have dumbed it down too far and the design is just not scalable nor safe. So here goes…

What I wanted was a couple of Grids on the Engineering Workbench’s material detail tab, that could grab Part Plant and Suggested Revision details for the engineer to review without jumping to other screens.

When I added the Part Plant Grid, I discovered that it would be super easy because there was already binding and Gomez-ism ‘Epimagic’ that was on the Sheet. Just plug and chug there. However, I did not determine similar ‘Epimagic’ available for a Grid that could retrieve ‘all’ Revision records for the Part. So I decided to use a BAQ, and the Event handling in C# to populate the Grid when the user is adding or changing the Part.

In the Script Editor, I subscribed to the TextChanged event on form Load, I then introduced a method to take Part as a parameter and fire the BAQ, and finally the Results are put to the Grid. Like so,

// **************************************************
// Custom code for EngWorkBenchEntryForm
// **************************************************

extern alias Erp_Contracts_BO_EngWorkBench;
extern alias Erp_Contracts_BO_ECORevSearch;
extern alias Erp_Contracts_BO_BomSearch;
extern alias Erp_Contracts_BO_PartRevSearch;
extern alias Erp_Contracts_BO_Part;
extern alias Erp_Contracts_BO_Customer;

using System;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Windows.Forms;
using Erp.Adapters;
using Erp.UI;
using Ice.Lib;
using Ice.Adapters;
using Ice.Lib.Customization;
using Ice.Lib.ExtendedProps;
using Ice.Lib.Framework;
using Ice.Lib.Searches;
using Ice.UI.FormFunctions;

using Ice.BO;

public class Script

	public void InitializeCustomCode()


	public void DestroyCustomCode()


	private void txtPart_TextChanged(object sender, EventArgs e)
	EpiTextBox txtMtlPart = (EpiTextBox)csm.GetNativeControlReference("c75de9d3-8ea7-4b05-b08b-8eed8d7c4796");
		if (txtMtlPart.Text == "" || txtMtlPart.Text == null)
		// Msgbox
		//MessageBox.Show( "MtlPartNum is blank.", "Failed to execute", MessageBoxButtons.OK, MessageBoxIcon.Warning);
		// Setup the dynamic query and execute
		DynamicQueryAdapter dqa = new DynamicQueryAdapter(oTrans);
		QueryExecutionDataSet qeds = dqa.GetQueryExecutionParametersByID("zRevision_HWM");
		qeds.ExecutionParameter.AddExecutionParameterRow("PartNum", txtMtlPart.Text, "nvarchar", false, Guid.NewGuid(),"A");
		dqa.ExecuteByID("zRevision_HWM", qeds);
		grdRevision_HWM.DataSource = dqa.QueryResults.Tables["Results"];

	private void EngWorkBenchEntryForm_Load(object sender, EventArgs args)
		// Add Event Handler Code
		EpiTextBox txtMtlPart = (EpiTextBox)csm.GetNativeControlReference("c75de9d3-8ea7-4b05-b08b-8eed8d7c4796");
		txtMtlPart.TextChanged += txtPart_TextChanged;

One thing I would really like to change is the TextChanged for something like LoseFocus, so that the user can populate the entire Part and then tab-out which would make typical data entry sense. I’ll have to go double check what other Events are available on the TextBox. Obviously now, it makes an attempt to fill that Revision Detail grid after every key-press.

I am also aware of the design where you set him up as an BAQDataView, which then exposes your Grid columns (Collection) and probably turns on a better user experience. I started out down this path, but either some of the syntax between versions was not consistent or my lack of experience I just wasn’t placing methods and declarations in the right places. I’d like to revisit this though, because I do appreciate the functionality that gets turned on.

But for now, what does this current design leave off in terms of application safety?