locked
How to Change entity field on form during PreUpdate plugin execution when an Exception is raised? RRS feed

  • Question

  • I'll try to explain the best as I can my situation... (sorry If it's too large, but maybe is neccesary for understanding the problem)

    A bit of background: I have a Custom Entity Form, for business-logic usage I have a customized Status field , which is a picklist with Draft and Active values. On the "OnLoad ()" event of the form I check if the custom status in in Active , and then I disable all the fields in the form. So for example I can create the entity(defaulted in Draft for creation) and later do some changes, change the status and after I save it will refresh with all fields disabled. At this point everything is OK.

    Now, I have to do some validations on the form(for which I need a Plugin , cus I need info from other entities). So I have a Plugin registered for the Pre-Update event of the form. Everything ok so far!

    Now there's is the case when the user changes some values, dates, etc in the form and changes its status to "Active" , if the plugin finds that some values are wrong, I throw an exception showing the message.

    The problem is that after the exception pop-up, the form still has the "Active " state that the user attempted to change, and after I close the exception pop-up, the OnLoad () event executes, detects is in active and disables all fields in the form :( (I don't want this cus I need the user to change the values that were wrong, so I need to be able to keep the status in Draft if an error occours)

    ____

    If add a PickList Property with the values I want defaulted(I need it to be back to Draft ) during plugin execution:

    (updating this entity:

    (DynamicEntity)context.InputParameters.Properties["Target"];

    )

    That updates the value correctly... but only if I don't throw the exception (so I can't see the error hapening, and the plugin actually updates the entity).

    Is there a way to be able to update the form from the Plugin and throw the exception after, so that it behaves the way I need?

    Thanks and I hope my situation is not too complicated to understand!!

     

     

     

    Tuesday, July 6, 2010 11:06 PM

Answers

  • It makes sense that the OnLoad code would fire after the preservation of values in a graceful failure.  There is no way for Microsoft to understand how a value came to pass before the form was submitted, so there's no guarantee that applying the adjustment after a refresh, would in fact would be safe.

    In any case, the behavior is nice for most situations in which you would absolutely hate it for losing all your work.  That said, the Developer Toolbar makes an excellent resource for crafty IT staff when it comes to "adjusting" the form back to an operable state without having to abandon the work in favor of using freshly deployed code at the server.


    Dave Berry
    Wednesday, July 7, 2010 4:20 AM
    Moderator

All replies

  • SetState/SetStateDynamicEntity and Update are different messages and can occur at different levels.  However, both SetState and SetStateDynamicEntity call a child-pipeline "Update" message.  So, while your plugin catches the "Update", it doesn't prevent the "SetState"/"SetStateDynamicEntity" messages, unless you push it into the Child-pipeline of the "Update" message.
    Dave Berry
    Tuesday, July 6, 2010 11:14 PM
    Moderator
  • Hmm, My states are just a customized PickList and not the CRM "status" or "state" of the entity. I just have a picklist for my custom field "new_status" which has two values: "Draft" and "Active" cus I need to have this with javascript controlled the way I described above.

    Are you talking about the "real" entity states?, Cus in my case is just simple form fields and javascript what I'm using.

    Thanks.

    Tuesday, July 6, 2010 11:22 PM
  • Understood.  I took it to mean that you customized the natural Status field.  It may be helpful to examine the JS code you have operating at the UI.  I can't ascribe any validity to this thought, but I think CRM preserves the data which was submitted--though the operation failed--when the record refreshes.  Does the "Active" value persist when the record is opened from scratch?
    Dave Berry
    Tuesday, July 6, 2010 11:40 PM
    Moderator
  • Well.. the JS code is really straightforward:

     

    //Check Custom Status, if its active, disable all fields
    if(crmForm.all.new_status.DataValue == 2){ //Status is Active, disable all fields
    crmForm.all.new_status.Disabled = true;
    crmForm.all.new_description.Disabled = true;
    crmForm.all.new_extensionstartdate.Disabled = true;
    crmForm.all.new_extensionenddate.Disabled = true;
    
    //Continues...
    
    }

     

    Yes apparently this data preservation on "operation failed" is what is happening, and is what I need to be able to change it somehow. I could close the window without saving and it will be in "Draft" cus nothing was saved. But I need to enable the user to Edit the form after the Error.

     

    Thanks again.

    Tuesday, July 6, 2010 11:48 PM
  • You can use the OnLoad code to check the "IsDirty" member of the crmForm to prevent locking out the fields.  See:  http://social.microsoft.com/Forums/en-US/crmdevelopment/thread/69e2b45c-77f6-4135-b3f4-331cf67afeb1

    Dave Berry
    Wednesday, July 7, 2010 4:14 AM
    Moderator
  • It makes sense that the OnLoad code would fire after the preservation of values in a graceful failure.  There is no way for Microsoft to understand how a value came to pass before the form was submitted, so there's no guarantee that applying the adjustment after a refresh, would in fact would be safe.

    In any case, the behavior is nice for most situations in which you would absolutely hate it for losing all your work.  That said, the Developer Toolbar makes an excellent resource for crafty IT staff when it comes to "adjusting" the form back to an operable state without having to abandon the work in favor of using freshly deployed code at the server.


    Dave Berry
    Wednesday, July 7, 2010 4:20 AM
    Moderator