If you have worked with Dynamics AX 2009, 2012, R2 or R3 for a while, at least more than an hour or so, you’ll have noticed that for some reason it tends to open new windows behind everything else.
You click a button to open a form, and then you wait for a while for the form to open. Then you wait some more, and a bit more again. And then you finally notice that the form has actually opened already. AX just decided to play a bit of hide and seek with you and opened it behind everything else.
Brilliant design decision, that…
I don’t like playing hide and seek with Dynamics AX, so I set out to try to find a solution to a problem.
The search lead to hundreds and hundreds of blog posts, most of which are copy/paste of some other blog post saying to change a registry key, and some are even saying how this can be pushed out to the clients through group policies.
The only problem with this approach, of course, is that it doesn’t work. The number of people who actually report this to work is very low. This is something which seems lost on so many authors who just copy/paste answers from elsewhere, without properly testing and verifying the solutions.
The problem appears to be related to the form taking too long to open, so Windows decides to punt it off to the back before it has finished opening. This is related to window ghosting, so disabling this in some way would be key to solving the problem.
Solution
While searching, I also came across another solution which actually seems to work quite well in my case. After I implemented this in our development environment here I haven’t come across a single case of a form opening up in the background, except if I have clicked in the original window again. (Which will cause Windows to bring that window back to the front, standard click-to-front paradigm)
I found the solution at https://blogs.msdn.microsoft.com/axsupport/2014/06/21/forms-opening-up-with-focus-in-background/, and it appears to be an official Microsoft blog post.
The solution is to add a static client method to the Application class to call the DisableProcessWindowsGhosting() function in USER32.DLL. Then, add a call to this function at the end of the Application class’s startupPost() method.
The source is available on Stefan’s post linked to above.
I will not claim that this is a solution that will solve every possible case of the windows opening up behind everything else, as there could be other causes for it. It has worked reliably for me for a few weeks, at least.