Assuming we are talking about SalesLogix LAN 7.5.4, under what circumstances would you use a .NET Extension Form vs using a Standard SalesLogix script form?

For example:

1) Would you always use a .NET form in preference to a standard SLX form?

2) If you just had a few data bound text fields to put on a Contact tab, which would you use?

3) What about if you had a more complex form?

Most of my work to date has been using standard SalesLogix forms, so this is currently my default choice purely because that is what I am most familiar with.  There's obviously not going to be a single 'right answer' to this question so it's your personal opinions I am looking for.

In my opinion, it is best to stick with SalesLogix forms unless you run into a Limitation that forces you to go to a .Net form (and even then, I would only use a .Net form for the specific instances where needed).

There are many advantages in doing so (e.g. Keeping all the SLX Code in a Single Repository (the Plugin Table), reduces the issues with Deployment of .Net extensions, makes it easier for others to customize if you are not around and the .Net project Code cannot be found, etc.

Echoing Raul....we've never used a .Net form on the LAN....so far no need. Even using Ryan Farley's SubLogix and .NetExtensionHelper libraries, although extremely helpful (Thanks Ryan!) don't ease the pain of not having a meaningful .Post method for a databound form.....no CRUD for a data grid, etc.

It's kind of like when all the C#ies wrote up stuff about the demise of the C# Code Snippet (obsolete) on the SLX Web side....and we were all told at Boot Camp in November that they are back in vogue\encouraged. If SLX LAN C# .Net was so cool, wouldn't Sage have developed a few dozen forms by now in C# .Net, developed extensive helper libraries and methods, come up with a SubLogix, use LINQ, etc. DevLogix VI would be out by now (or is that SLXMobile....?).

Why aren't we coding this stuff in MVC, MVVM, XAML....... instead of vbScript Classes, SQL Stored Procs, SQL Views, SQL Table\Scalar functions, SQL Triggers.....

And we've already run into a few cases (both Web and LAN) that you have to scramble to find the project code.....

We've done some Wild Stuff on the LAN.......and never have used .Net Extensions.....

My opinion is, surprise, probably a bit different than most.

For me, if my form is a simple data bound form then without question use a native SLX form. For most other things, I prefer using .NET extensions. Mainly because I want to be able to use source control, unit testing, separate business layers, and a more modern development environment (Visual Studio). Personally, I feel I am more productive this way and produce far better code. Tools like Sublogix and NetExtensionsHelper make this far easier as RJ mentioned. Honestly, you can throw some code together using Sublogix for reads/updates/inserts/etc far faster and more effeciently than stringing together SQL statements and ADO code. I like having access to the .NET Framework, but also my own libraries that I can reuse more easily. You absolutely can do some crazy complex stuff on SLX forms, but honestly at some point you're digging yourslf into a hole because you can't as easily manage the complexity of what you've built so it's far more difficult to return to and extend or make changes to later on.

All this is of course to be taken with a grain of salt and be smart about things. It really all about picking the right tool for the job. It's silly to use a .NET Extension when a simple SLX form will do the job easily. However, weighing in what I enjoy working with, and the tools I have available, make .NET Extensions tip the scale a bit in their favor for me.

Ryan

There is a weird bug in .net version of saleslogix extension that tabs won't work in it. I guess this also defines or restrict it on the selection of .net versus vb script.