Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Tuesday, June 05, 2007

Yellow Lock in Dynamics AX 4.01

Alright not to get off the subject about the .Net BC and custom code in .Net using it. But I did come across something, that I guess I have never had to come across before. Anyway we have custom code on a form where we had to make use of the TabChanged() method. This was needed, best thing for the mod, so there you go.

Well when users wanted to move some fields around on the lines level, they could not. When you right clicked, and then clicked on setup, you see Yellow Locks on all the objects in the tree view, under the tab control where the TabChanged() method was modified. So in research of this issue, turns out that this is "Working as Designed" as the *Offical* word from Mcirosoft Dynamics Support.

This means that you can't have your cake and eat it too, for this type of situation. Basically you modify the TabChanged() to TabChange() methods of a tab control, and you lock all fields in place as they exist in the AOT. So for everyone else who might run into this, just be aware this is the issue. The solution, do Not change those two methods, or just accept the users can't change the fields around and change them for the collective whole in the AOT.

Well check back as I continue my talks about the .Net BC and it's use for developing a custom ASP.Net application!

Let me add I realize that for some this has been a known issue since AX 3.0, but when I did my search on the web nothing came up about this. So I thought it worth while for future reference for Someone else to find, just in case someone needs it! :-)

Find a job at: www.DynamicsAXJobs.com

Labels: , , , , , , , , ,

4 Comments:

Blogger Jan B. Kjeldsen said...

Use pageActivated on the tabpage control instead of tabChanged on the tab control.

4:05 AM  
Blogger brandon said...

That is a very good point. But in our instance it means more code to preform the same task.

I am a heavy believer in putting things in the proper place, and less code as possible to achieve the most out of it.

There should be no issue with this, but the design has a flaw, and it is noted. Again though thank you so much for taking the time to leave the note, because you could change your code and you that method instead on each tab page. That would then free this issue up.

-Brandon

8:19 AM  
Blogger gl00mie said...

yet this behaviour is documented. AX3 Dev Guide has a topic Coding for user setup of forms
that states: «If either of the below methods are overridden, the user setup level of “tab controls” cannot be higher than restricted, regardless of the property value.
tabChange
tabChanged

[...]
The following methods on the “tab page control” should be used instead:
pageActivated
allowPageDeactivate
»


AxDeveloperDocs.chm in AX4 has a topic Methods on Form Controls with explicit directions: «Do not override the tabChange or tabChanged methods on Tab controls. Instead, override the pageActivated and allowPageDeactivate methods on Tabpage controls. If you override tabChange or tabChanged, the user setup level for the tab cannot be higher than Restricted. The user cannot fully customize the layout and content.»

Of course it worth stating it once again...

9:21 AM  
Blogger brandon said...

gl00mie,

Thanks for sharing on where else this can be found. I realize that this is other places, but I searched the web, like people do, because the Search on those help files are just not has helpful as most would like.

When I searched the web it was not there. Now it is. And we have you to thank for pointing where in the Help files we can find it.

[Your tone could be a little better, but the information is worth keeping. :-) Smile gl00mie, and turn to sm1ley!]

-Brandon

9:33 AM  

Post a Comment

<< Home


Copyright 2005-2011, J. Brandon George - All rights Reserved