Replacing An Exisiting Plugin With An Inherited Control > Developer Forum

Unanswered Active Topics

Forums Search

Subject: Replacing An Exisiting Plugin With An Inherited Control

You are not authorized to post a reply.

Author

Messages

Walter G

Posts:8

07/25/2008 1:31 AM
Hi, We are needing to add some controls to the customer detail form but do not want to add in a new section as a new tab. We need the new controls to be initially visible and therfore decided to create a new plugin section inheriting from Interprise.Presentation.Customer.CustomerDetail.HeaderControl We have added in our new controls onto the control, compiled it, and registered the plugin. We then replaced the existing plugin for the headercontrol on the customer detail form with ours, all ok. When we view a customer though none of the controls in our header control are being populated, such as the customer name. Is there something we have to do in the code in order to get the base class to work as it did before? Hoping for a quick reply as we're a bit stuck. Walter.

John Boaz L User is Offline

Posts:18

07/25/2008 1:54 AM
Hi Walter, You didn't mention if you've bound your new controls to the fields you need in the customer dataset, that could be the reason the data isn't showing up. Also, could you confirm that you haven't changed the dataset of the bound control, or initialized a different instance of it.

John Boaz T. Lee Developer Interprise Solutions

John Boaz L User is Offline

Posts:18

07/25/2008 1:57 AM
Oops, my mistake. What I meant to say is could you confirm that you haven't altered the dataset of the HeaderControl nor initialized a different instance of it.

John Boaz T. Lee Developer Interprise Solutions

Walter G

Posts:8

07/25/2008 9:32 AM
Hi, I haven't changed anything from the standard code that was created from the GAT recipe apart from the code around our added controls. Should we remove the line that instantiates the facade in the constructor? Is this set from the parent control? this.m_TestOverloadSectionFacade = new Interprise.Facade.Customer.CustomerDetailFacade(this.m_TestOverloadDataset); m_TestOverloadDataset is setup as public Interprise.Framework.Customer.DatasetGateway.CustomerDetailDatasetGateway TestOverloadDataset { get { return this.m_TestOverloadDataset; } }

John Boaz L User is Offline

Posts:18

07/26/2008 3:48 AM
Hey, Don't worry about the default constructor because the parent control uses the HeaderControl's overloaded constructor to pass it's instance of the CustomerDetailDatasetGateway and CustomerDetailFacade to the HeaderControl. Could you check to see if m_TestOverloadDataset holds the dataset passed in the overloaded constructor and not a new instance of CustomerDetailDatasetGateway. Also, please make sure that your controls are bound to the appropriate fields in the right table in m_TestOverloadDataset.

John Boaz T. Lee Developer Interprise Solutions

Walter G

Posts:8

07/28/2008 5:12 AM
Hi, Found an easier way instead of changing the bindings and that was to simply call the base overloaded base constructor with the parameters. We would have had to change all the bindings on the control as they all use the base controls DSG, and not the one added to our overriding control. The overloaded constructor in our control also sets the DSG of our control and did not pass anything to the base. We changed this:- public TESTHeaderSection(Interprise.Framework.Customer.DatasetGateway.CustomerDetailDatasetGateway TESTHeaderDataset,Interprise.Facade.Customer.CustomerDetailFacade TESTHeaderSectionFacade): base() To this:- public TESTHeaderSection(Interprise.Framework.Customer.DatasetGateway.CustomerDetailDatasetGateway TESTHeaderDataset,Interprise.Facade.Customer.CustomerDetailFacade TESTHeaderSectionFacade): base(TESTHeaderDataset, TESTHeaderSectionFacade) Can you foresee any potential issues, dont think so myself. Also, is this a problem in your GAT recipe that it does not populate the parameters into the base constructor call?

Ramil D

Posts:218

07/28/2008 6:47 PM
There won't be any issues with your changes. This is not a bug in our plugin section recipe but rather a new perspective in the way developers are inheriting from our existing plugins in a more easier approach. We will take a look at this and investigate if it is the right path to take. Thank you for the feedback.

Walter G

Posts:8

07/29/2008 1:28 AM
Thanks for the help. I will let you know if we come across any issues with our approach.

Ramil D

Posts:218

07/29/2008 2:07 AM
No problem. Thanks for your patience as well.

You are not authorized to post a reply.

Forums > Connected Business Platform > Framework Releated Questions > Replacing An Exisiting Plugin With An Inherited Control