UI Pull not passing Active flag to adapter pull components resulting in hanging data
travispotterBH opened this issue · comments
Description:
As discovered by @dengh0
Using the daily alpha
In Grasshopper and Excel, the pull method appears to be actioning before the Boolean toggle has been applied to the method. See images below.
I am unsure if this is specific to this daily alpha or others versions as well.
Steps to reproduce:
Build a file adapter, pull request and attempt to pull in both grasshopper and excel.
Expected behaviour:
It is expected that the pull method would only action once the boolean toggle is marked as "True."
Test file(s):
I'm transferring this to Excel_UI as I don't think it is a BHoM_Adapter issue.
Sorry I realised this is actually happening in both Excel and Grasshopper - somehow I misinterpreted the image. Might be a File_Adapter issue then, in which case I'll transfer this to File_Adapter. I'll have a look.
I'm transferring this to File_Toolkit because the issue is happening in two UIs so isn't just an Excel_UI issue unfortunately @alelom .
@travispotterBH in your GIFs you only use the File Adapter, which is why I'm suspecting it's actually a problem with that adapter, but to confirm, could you try with another adapter as well to see if the behaviour is across multiple adapters or just the File adapter?
So after testing I am now convinced this is a BHoM_UI issue.
The issue is that the Pull component is not triggered when the boolean value is set to False.
The first time you create the File_Adapter and Pull component, all works fine:
Then, you do your first Pull by toggling to true, and the Pull action is triggered. An output is stored in the output of the component. Then, if you toggle to false again, the Pull component in BHoM_UI is not triggered again: it should be triggered so it can clean out the previously pulled output:
So, actually, when the boolean is set to false, the back-end File_Adapter logic is not triggered at all, and neither the front-end logic of BHoM_UI's Pull method, which should clean the output by returning a new List<object>() (line 104).
The output you see is that of the previously triggered Pull invokation.
I'm in agreement with your logic and reasoning/investigation there @alelom - I'll transfer this to BHoM_UI instead 👍
On my investigation just now, I've identified the culprit to be this method in the Pull.cs component within BHoM_UI:
protected override bool ShouldCalculateNewResult(List<object> inputs, ref object result)
{
return (bool)inputs.Last() == true;
}
When we toggle that to false we decide we shouldn't calculate a new result, which means the old result is returned for the same adapter. It's a speed saver by the looks of it, caching the output so that you can turn off the adapter pull (e.g. if you've pulled from a large file or open model) but keep your results without losing them.
So on that basis, this actually looks like a by design issue that can be confusing but makes sense when you consider the original development case (large models being pulled from live models rather than files). In that case, having a Revit pull set up for example, and then moving an object in Revit, would retrigger the pull immediately because they're connected with sockets. For a large model, that could be minutes of Grasshopper (or Excel) locking up when the move in Revit might be small, or even a mistake and needs to be undone. In this case, turning off the pull (active == false) but caching the output allows the output to continue to be used without the pull being retriggered until the user is ready.
So in this case I'm inclined to suggest we either need to maybe improve some documentation to make that more obvious, or do a bigger workshop on the desired outcome of the scenario, or leave it as is.
Following review, this has been deemed to be accepted behaviour, and better communications with users is the solution. Issue closed as no work to be undertaken.