Events lifecycle question including ValidateInputsEventArgs

Events lifecycle question including ValidateInputsEventArgs

tim.collins29V9X
Enthusiast Enthusiast
418 Views
2 Replies
Message 1 of 3

Events lifecycle question including ValidateInputsEventArgs

tim.collins29V9X
Enthusiast
Enthusiast
  1. How can I get the ID of the control that triggered the ValidateInputsEventArgs event?  At the moment I have an infinite loop when I set the "messages" field with the new error messages which triggers a validate event which updates the "messages" field, and so on. I also can't report on which field has the problem.
  2. I have some errors that are not based on single fields, such as "your bicyle has 4 wheels please fix either the vehicle type or the number of wheels".  However, I do not see a way to compute this just once. I have to do it over and over and over for each ValidateInputsEventArgs and that doesn't seem right.
  3. What is the difference between ValidateInputsEventArgs and ValidateInputsEvent ?  So far I have not managed to discover the explanation during my random wanderings over the documentation.
0 Likes
Accepted solutions (1)
419 Views
2 Replies
Replies (2)
Message 2 of 3

BrianEkins
Mentor
Mentor
Accepted solution
  1. Unfortunately, it's not currently possible to know which input was edited and was the cause of the ValidateInputs event being fired. The ideal would be for the ValidateInputsEventArgs object to support a property that returns the edited input. I don't know of any workaround except to possibly store all of the command input values and then check the current values against what you have stored and assume whatever is different caused the change. That would be a bit of a pain to do.
  2. I'm not sure I fully understand the issue here, but the ValidateInputs event is simple in that it's notifying that something changed, allowing you to determine if the current state of the inputs is valid or not. Maybe, you always say the inputs are invalid until they reach at least a certain state and then you start checking them and reporting them as valid.
  3. All events have an argument where an EventArgs object is passed into the event. This provides access to the information you'll want to access in relation to that event and in some cases, where you can set data to be passed back. In the case of when the ValidateInputsEvent event is fired, a ValidateInputsEventArgs object is passed in as the argument. This has several properties, but the most important is the areInputsValid property that you set to indicate if the inputs are valid or not, which results in the OK button being enabled or not.
---------------------------------------------------------------
Brian Ekins
Inventor and Fusion 360 API Expert
Website/Blog: https://EkinsSolutions.com
Message 3 of 3

tim.collins29V9X
Enthusiast
Enthusiast
Thanks Brian. It's too bad the event doesn't carry the input ID of the control.

I fixed my infinite loop bug by only updating the text box with the error message only when it is changed. This will work so long as I don't get a message with a timestamp in it.

The dozen or so redundant validate events can be ignored. Not pretty but I will stop fighting it.