Hijacking a Native Control

I am working on the PO Entry. We want to have the PrintAs to stay “As New” UNLESS the user chooses to print “As Changed”. Basically, we don’t want to form to change the option. So I am trying to hijack a native control, but there is something I am not doing correctly, because the Click functions are NOT getting hit. Here is what I have done.

Please help.

So I created a 2 global private object of Ice.Lib.Framework.EpiRadioButton type.
private Ice.Lib.Framework.EpiRadioButton erbPrintAsChanged = null;
private Ice.Lib.Framework.EpiRadioButton erbPrintAsNew = null;

I established my click methods

  • In the InitializeCustomCode method
    // End Wizard Added Custom Method Calls
    this.erbPrintAsChanged = (Ice.Lib.Framework.EpiRadioButton)(csm.GetNativeControlReference(“5807999b-6a0f-4175-b3e1-238c61bdb4d2”));
    this.erbPrintAsNew = (Ice.Lib.Framework.EpiRadioButton)(csm.GetNativeControlReference(“34f9b227-e4e8-4373-80b0-a66530397953”));
    erbPrintAsChanged.Click += new System.EventHandler(this.erbPrintAsChanged_Click);
    erbPrintAsNew.Click += new System.EventHandler(this.erbPrintAsNew_Click);
    this.erbPrintAsChanged.MouseDown += new System.Windows.Forms.MouseEventHandler(this.erbPrintAsChanged_MouseDown);

  • In the DestroyCustomCode method
    // Begin Custom Code Disposal
    erbPrintAsChanged.Click -= new System.EventHandler(this.erbPrintAsChanged_Click);
    erbPrintAsNew.Click -= new System.EventHandler(this.erbPrintAsNew_Click);
    this.erbPrintAsChanged.MouseDown -= new System.Windows.Forms.MouseEventHandler(this.erbPrintAsChanged_MouseDown);

I Try to use them:

private void POHeader_AfterFieldChange(object sender, DataColumnChangeEventArgs args)
{
	// ** Argument Properties and Uses **
	// args.Row["FieldName"]
	// args.Column, args.ProposedValue, args.Row
	// Add Event Handler Code
	switch (args.Column.ColumnName)
	{
		case "PrintAs":
			if(args.Row[args.Column.ColumnName].ToString() == "C" && bPrintAsDirty == false)
			{
				//args.Row[args.Column.ColumnName] = "N";
				
			}
			break;
	}
}

private void erbPrintAsChanged_Click(object sender, System.EventArgs args)
{
	// ** Place Event Handling Code Here **
			bPrintAsDirty = !bPrintAsDirty;
			string text = "FieldName: PrintAs has been changed.";
			WriteToLogFile(text,1);
}

private void erbPrintAsNew_Click(object sender, System.EventArgs args)
{
	// ** Place Event Handling Code Here **
			bPrintAsDirty = !bPrintAsDirty;
			string text = "FieldName: PrintAs has been changed.";
			WriteToLogFile(text,1);
}

private void erbPrintAsChanged_MouseDown(object sender, System.Windows.Forms.MouseEventArgs args)
{
	// ** Place Event Handling Code Here **
			bPrintAsDirty = !bPrintAsDirty;
			string text = "FieldName: PrintAs has been changed.";
			WriteToLogFile(text,1);
}
1 Like

This is something I was looking for the other day, so I’m curious as to what all can be done with this.

A few comments - hopefully something helps

  1. How confident are you that you’ve got the correct GUIDs?
  2. When adding a CLICK event handler to a native control, it is run AFTER the system handler (this means, that if the system is doing something that would prevent your code, look at that)
  3. Have you tried a simple MessageBox.Show() to ensure your event isn’t running?
  4. After making those changes, you closed and reopened your form? (the event handler wont be attached until then)

Thanks @Chris_Conn.

  1. I do believe that the GUID is accurate.
  2. Right now I am not doing anything, but trying to identify that my click events are getting triggered. So, I am not concerned with order, YET. But thank you for the heads-up.
  3. I have my own method to log debug info in the methods. Those string are not showing up in the log file though.
  4. I am aware of the Epicor tribal knowledge of re-initializing customizations.

I have done this in E9, this is my first customization in E10. It just doesn’t seem to be responding the same.

I tested this - in fact the behavior is weird (and seems related to that particular control type). I’ll play with it to see what I can come up with.

I have not thought about the idea of the type being the difference. I don’t think I have ever done it on a radio button before, mostly textboxes or checkboxes.

I will play with that also. Thanks @Chris_Conn.

1 Like

@Caleb323, if you are not trying to hijack a radio button, try the code that I have shown. Basically, create an object and then assign csm.GetNativeControlReference([Using the GUID of the native Control]) method. Make sure you cast the return value of that method as the same as the object your assigning to.

2 Likes

I’ll give that a shot.

Thanks for the info!

Sometimes the preview pane can alter the meaning of a post entirely…

My Dad often threatened to put ours in a cast too…

3 Likes

lol

Well… I tried multiple events with no success. I tried to delay the setting of my event handler (in case the default form startup was overwriting) with no luck.

We may need to dig into Ice.Lib.Framework.EpiRadioButton to see what the hell is up.

So I have made a work-around for the radiobutton issue. I started a Case with Epicor to look into this specific issue:

in PO Entry screen, when you finally print a PO, after coming back from the Print Dialog the “Print Order as New” is now changed to “Print Order as Changed”. But, the record is not dirtied. So the user can close the screen and not know that something changed to the record.

My company wants to keep that value “As New” unless the user specifically chooses to select “AS Changed”.

That is why I was trying to hijack the RadioButton. So that I would be able to identify who changed the value, the user or the system.

So instead of hijacking the RadioButtons, I decided to add a ComboBox and bind it to the DB field that the RadioButtons are associated with. I then create a ValueChanged event. this would allow me to identify if the user made the change and show a dialog screen to inform them of the change, per company request.

I create a Data Directive to deal with the change and reverse it if it was a system change.

2 Likes

Thanks! We wanted this automatic function disabled as well.

For others, here is how I did it. The system change is run by the TaskAgent ClientType.
image

1 Like

I had this exact issue. My solution was to set up a UD field for my definition of new/changed and set it based on a BPM. I then tied the report field to that and hid the stock form controls because I didn’t need them, but if I did, I’d simply replace them with a custom control.

As a rule, I don’t overwrite stock functionality unless there’s absolutely no other way. Just hide it from users and use a parallel custom system that’s unlikely to break between patches/sys updates.

Also, to hell with radio buttons. Use a drop down. They’re bigger, easier targets to click on.