Variants should keep track of the state of the original object, including but not limited to its global variables (ex. HideValidationDialog, StatusCheckSuspended, ...), and access to information as retrieved by methods like IsEmpty, IsTemporary, HasFilters, etc.
See previous discussion on Github, where the proposed solution was for each ISV to implement their own custom table extensions or single instance codeunits in order to keep track of these things for records going through the new price list interfaces.
Comments
> Variants should keep track of the state of the original object
They do, don't they? E.g. a procedure taking a Variant, which is passed a Record, will see the filters on that record, preserved.
I think the problem is only when you then assign that Variant back to a Record, which acts like all 'normal' assignments do, i.e. discards the filters and other stuff (basically, all except fields).
Which brings me to...
> More generally, assigning or copying an object variable to a different object variable should keep track of the internal state.
I don't know about this. Probably lots of existing code relies on the idea that records or other objects, passed by non-VAR or otherwise assigned (since a non-VAR pass is ~= an assignment), do not persist filters and other things. For example, imagine you have a filtered record set, you loop it, and you pass each iteration to another procedure - by non-VAR - and that procedure then does some more stuff with the record like adding filters, etc.... expecting that it was passed in with none
Category: Development
More generally, assigning or copying an object variable to a different object variable should keep track of the internal state.
Category: Development