Been tumbling with a problem for the last few days.
A form in our Dynamics AX module for Preventive Maintenance Control was not behaving.
The form has "explicit" filter fields that the user can see without having to activate the form filter (CTRL+F3), for setting up filters most commonly used in an easy way.
And this is working ok. However at this customer site, the form has been adjusted so that the user can have the form refreshed automatically periodically, and when the users at the customer site were making use of the "explicit" filter combined with the AX's normal filtering (CTRL+F3), the form simply threw away the normal form filtering.
I discovered a subtle but very important difference between writing
<formtable>_ds.executeQuery(); (which was the way our code was doing it)
The difference is that research will retain the filter ranges in the forms query as they are right now.
.executeQuery will NOT.
It is mentioned in the Developer's Guide, but I guess the responsible programmer hadn't noticed that one.
Developer's guide states:
"research vs. executeQuery
If you want to refresh the form with records that were inserted in a method or job that was called, then you should use research.
If you want to change the query to show other records, perhaps based on a modified filter, then you should use executeQuery."