The issue we're talking about here is this:
The user settings are stored in the SysLastValue container (SYSLASTVALUE.VALUE). You may have looked at the structure of the sysLastValue data via the usage data form (from user options) before, it just looks like a load of numbers, and it's hard to relate them back to the form. Well I found that the data in the container is basically the form control IDs, stored in a structure to match the structure of the form design.
When I make a change to the form's design in the AOT, for example I add a field to a grid, then this can push all of the existing control IDs up by one, a control that was previously 12301, is now 12302. Now because we use these IDs to match to the layout held in SysLastValue - you can understand how a change to the design in the AOT invalidates the SysLastValue data.
So attached is an xpo (scroll to the bottom) which can rebuild SysLastValue data for a form where the control IDs have changed. You set which form you want to rebuild data for, then it instantiates an instance of that form and then for each record in SysLastValue which relates to that form it iterates through and converts the IDs in SysLastVaue if it finds that they are different from the current form design.
Warning! This code will update the usage data in an unrecoverable way so please take great care when using it - test it first and take a copy of the SysLastValue table before updating it for real. It would be pretty awful to try to help users by recovering their usage data for them and end up making it worse, so please be careful.
Few points about using it:
What I expect the process for a developer to be is: