In http://slxtraining.net/2009/09/how-do-i-add-two-datagrids-to-a-form-that-are-correlated-dependent-datagrids/ we talked about how we needed to get a hold of the NativeControl to do things like .SelectedIndex . We needed to get the nativecontrol because the SalesLogix control did not expose the properties we needed. The SalesLogix developers are smart people. Being wise they leveraged what was already available to them from ASP.NET and the .Net framework. So most of the controls in the web client are wrapped .Net controls. Wrapping the control means that you need to expose all the same properties of the base control and then add on any features you want to add. They are doing a pretty outstanding job and this is why I needed the nativecontrol in that old post.

No longer. We now have that ability in SP2. As of the Release Candidate you have an enhanced version of the form being passed in a Code Snippet Action Item. Really the form isn’t enhanced, but the controls also have been augmented to better replicate what their base implements. This is a great step forward and part of the evolution of the product.

Why does this matter? What is the point?

It matters because at some point SalesLogix will be a multi-platform offering. This means you will write code once in Application Architect and it will output in more than one format. It already does this in a variety of ways such as SData, but we are talking different formats like Pocket PC or BlackBerry. So in my case a datagrid for the web is different than a datagrid for the Pocket PC. Just barely, but I suspect in the future the code I write using the enhanced controls in SP2 will work against either (when that time comes). What we are doing now is setting ourselves up for that time. The short term benefit is easier code and shorter development times. The long term benefit is shorter development time porting our code to a new platform.

If you abstract the way a form is coded against then our ultra-smart SalesLogix developers can recode what you do towards a new platform. So you interact with ImySLX form and do things like form.controlname.method and they turn that into the appropriate code for the appropriate client platform. Right now most of that is web, but we need to learn it and get used to it and then take advantage of it.

Really what I am looking at now is the new ImySLX interface and what it offers. The developer of the code is very helpful (we do not mention names intentionally by request) and details should be forthcoming. This interface is a start on the web version of Application.Basicfunctions.xxxx you can do perhaps 10 things with it now, but this is just the ground work for what is to come.