A familiar problem with upgrades from SalesLogix LAN to Web is many of the foreign keys may have some invalid values.  The legacy LAN client allowed one to put basically anything in there without much validation since we were playing with raw SQL, but the NHibernate platform used in the new client is not as forgiving.  Therefore you may find yourself with this type of errors:

System.Web.HttpUnhandledException: Exception of type ‘System.Web.HttpUnhandledException’ was thrown. —> System.Reflection.TargetInvocationException: Property accessor ‘Ticket’ on object ‘Sage.SalesLogix.Entities.TLXProjectExpense’ threw the following exception:’No row with the given identifier exists[Sage.SalesLogix.Entities.Ticket#            ]‘ —> NHibernate.ObjectNotFoundException: No row with the given identifier exists[Sage.SalesLogix.Entities.Ticket#            ]

What happened here is the original developer chose an empty string instead of a NULL to indicate the absence of a value – it works fine on the LAN client but the web client tries to actually load a ticket with an id of “            “.  The solution recommended so far is to clean out those values as you find them… obviously not very practical in an upgrade where you could have dozens of foreign key relationships to check one by one.

Thankfully all the information we need to get around the problem is already stored by SalesLogix and collected in the entity model – so all we have to do in theory is crawl through the relationships defined in the App Architect and run an update for each one of them.  It is actually quite easy as Sage prepared some neat (albeit undocumented) API to examine the model metadata.  For example this is the code I used to load the project model and iterate through the relationships:

IProject project = ProjectUtility.InitProject(ModelPath);
OrmModel model = project.Models.Get<OrmModel>();
foreach (OrmRelationship relationship in model.Relationships)
{
  // ...
}

It took me a few hours to write the app, mostly because I had set out to learn a few more things about WPF at the same time – the logic for the check and update itself was pretty easy. The one caveat is there are a few relationships that are a bit “odd” and can’t get fixed right (for example the M:1 relationship from targetresponse to MKTGSVC_RECIPIENT is on TargetResponseId which we can’t null out)

For now it is usable as a standalone app… Eventually I would like to make it as an App Architect extension and add a few features (most importantly the ability to drill down to see the actual data for the invalid records)

For the source code I made it available as part of the OpenSlx project on GitHub, but the binaries can be downloaded here if you want to give it a try (obviously be sure to backup the DB beforehand etc – the “no warranty” disclaimer is there for a reason!) One big caveat there before I forget – if you have problems with invalid Seccodeid in the Secrights table, etc, you may have to do some cleanup before and/or after running the script as it will null them out which will crash the client.

For data entry screens keyboard shortcuts are an incredibly useful way to make the form faster and more user friendly.  Users who bang at the screen all day will learn the shortcuts surprisingly fast and thank you for saving their wrists.  Of course this should be used together with other techniques such as proper keyboard focus management and ensuring there is no auto-postback causing an undue delay.

With the jQuery library included with SalesLogix it is pretty easy to set up, here is an example of how I am using it to trigger certain buttons when Ctrl+N, Ctrl+R etc are pressed:

$(document).keydown(function (e) {
    if (e.which == 'N'.charCodeAt(0) && e.ctrlKey) {
        if ($("#<%# btnNextFax.ClientID %>").is(":visible"))
        // this check is to prevent them from slamming repeatedly on Ctrl+N
            $("#<%# btnNextFax.ClientID %>").click();
        return false;
    }
    if (e.which == 'R'.charCodeAt(0) && e.ctrlKey) {
        if ($("#<%# btnRefresh.ClientID %>").is(":visible"))
            $("#<%# btnRefresh.ClientID %>").click();
        return false;
    }
    if (e.which == 'D'.charCodeAt(0) && e.ctrlKey && $("#<%# btnDeleteSelected.ClientID %>").is(":visible")) {
        // short delay so that the handler is over by the time the prompt shows up
        setTimeout(function () { $("#<%# btnDeleteSelected.ClientID %>").click(); }, 100);
        return false;
    }
    if (e.which == 'A'.charCodeAt(0) && e.ctrlKey && $("#<%# btnSelectAll.ClientID %>").is(":visible")) {
        $("#<%# btnSelectAll.ClientID %>").click();
        return false;
    }
});

It’s important to remember to only register the handler once… and if you register in a dialog smartpart you need to make sure to undo it (otherwise it will try to trigger the button again even once the dialog is hidden)!  This can be done calling $(document).unbind(‘keydown’, myfunction)  (in that case you have to make sure you keep a reference to your handler). 

For the past 2 year or so we have been using a 3rd party control library provided by DevExpress.  I have come to really, really like them – they allow for some really cool effects with minimal work, usually have fairly decent performance, are easy to work with and not too buggy.

For example this is the DevExpress date picker:

I think it’s better looking and easier to use than the SalesLogix one.  It also does not suffer from the bug that the stock SalesLogix DateTimePicker control has with dates that are stored in local time.

This is a neat cascading grid effect:

It also support grouping, exporting to Excel, customization of the layout by end user, all with very little effort.

If you use the controls on a mainview, or in a frame, then it is very straightforward – just drop them on the page.

If you use the controls in a tab or a dialog there is a little trick to consider – used like that, the controls will not be able to automatically load the supporting javascript, so you may get some errors.  It can also happen if the control is initially hidden on your view and shown conditionally on a postback.

To get around it there are 3 options:

• If you have control on the mainview of the page, you can add a call to this page to load the DevExpress scripts.  Since that will be called on the initial load it will be able to load the scripts at that time and they will remain available when the DevExpress control finally appears, on the dialog or whatnot.  The scripts will be cached after the first time so the performance hit should be minimal.
• Otherwise, you can use a module to accomplish the same effect.
• Finally you can load the control in an Iframe tag.  This also offers the advantage of better performance for “callback” operation (expanding the grid rows, for example), but requires a bit of effort to make sure the frame is sized correctly.

For the second approach, this is the code I used in the module:

public class DevExpressScriptLoader : IModule
{
    /// <summary>
    /// Have the browser load the DevExpress scripts automatically.
    /// Otherwise, if they are on a tab, and the tab is not initially loaded, the DevExpress contols will fail.
    /// They will be cached anyway so not a big performance hit.
    /// </summary>
    private void LoadDevExpressScripts()
    {
        if (HttpContext.Current != null &&
            HttpContext.Current.Handler is Page)
        {
            DevExpress.Web.ASPxClasses.ASPxWebControl.RegisterBaseScript((Page)HttpContext.Current.Handler);
        }
    }

    public void Load()
    {
        LoadDevExpressScripts();
    }
}

The main part is the call to “ASPxWebControl.RegisterBaseScript”, and if you choose to go with the first approach it is the only line needed.

Building it as a module lets you include it easily for all pages of the site – under the Portal / Modules section of the Application Architect.

For a framed approach I found the following function useful – it provides a “sizeParent” function which can then be called from the contained frame:

_frame.Attributes["onload"] = "var frm = document.getElementById('" + _frame.ClientID + "');frm.contentWindow._sizeParent = function(h) { $('#" + _frame.ClientID + "').height(h); };";            

You can change the “SeedValue” of a lookup (used for additional query filter) by simply assigning it from the code behind, during a postback or during the initial page load.

If you want to assign it from client script, you need a few extra steps. First of all, the current seed value can be set simply by assigning it:


luProj._currentSeedValue = newAccId;
luProj._seedValue = newAccId;


I have no idea why there are 2 values. It looks like just setting “currentSeedValue” works right now but I just set them both to be safe.

This works fine if there is no initial seed value on the lookup. However, if the value was set from the code behind, it will actually get hard-coded in the lookup object. The most effective way I have found to get rid of it is overriding the “show” method to remove the optional parameter it accepts:


if(!luProj._oldshow){
luProj._oldshow = luProj.show;
luProj.show = function() { return this._oldshow(); }
}


Don’t forget that if there is a postback, the value you set from the client side will be lost. So either register your script to get called again, or add logic on the server to add the seedvalue on the postback (as usual, the motivation for not having the server do it in the first place is to avoid the postback delay, loss of keyboard focus, etc)