It is on the MSDN code gallery.

I found I was getting the error every time I started Visual Studio in the morning, with Visual Studio hanging for a looong time… but not in the afternoon… crazy uh? The difference is in the morning I connect to my workstation via remote desktop… and usually in the afternoon I am physically at the keyboard. It turns out the delay was caused by the remote desktop clipboard helper… an application called rdpclip.exe. Killing the application solved the problem (though it does prevent pasting via remote desktop, obviously, but I can live without that)

/// <summary>
/// Enable / disable all controls on the form
/// </summary>
/// <param name="islocked"></param>
private void LockForm(Control parent, bool islocked)
{
    foreach (Control c in parent.Controls)
    {
        if (c is IButtonControl || c is SmartPartToolsContainer)
            continue;
        if (c.Controls.Count > 0)
            LockForm(c, islocked);

        PropertyInfo pr = c.GetType().GetProperty("ReadOnly");
        if (pr != null)
        {
            pr.SetValue(c, islocked, null);
        }
        else
        {
            pr = c.GetType().GetProperty("Enabled");
            if (pr != null)
            {
                pr.SetValue(c, !islocked, null);
            }
        }
    }
}

Unfortunately there is a serious usability drawback in the current version – the records are not sorted by default. So if there are more than a handful of them the user still has to click on the search button to get them to sort, which defeats the purpose of getting the lookup to pre-populate.

You can fix the problem in several ways. The first is to add a little piece of javascript in your code behind to force the sort… this is rather unobtrusive and easy to test so if you are only fixing one form it’s probably the way to go:

ScriptManager.RegisterStartupScript(this, GetType(), Guid.NewGuid().ToString(),
            "$(document).ready(function() {" +
            lueLinkOpp.ClientID + @"_luobj.initGrid = function (seedValue, reload) {
                LookupControl.prototype.initGrid.apply(this, [seedValue, reload]);
                this.getGrid().getNativeGrid().getStore().setDefaultSort('CreateDate');
            }
            });
            ", true);

It looks pretty yucky, but hey, it works.

If there are more than a handful of lookups, or if you want the changes to apply also on QuickForms, you’ll probably want to package them into a user control, something like this:

public class FixSlxLookup : LookupControl
{
    /// <summary>
    /// Add the sorting hack.
    /// </summary>
    /// <param name="e"></param>
    protected override void OnPreRender(EventArgs e)
    {
        base.OnPreRender(e);
        if (InitializeLookup && LookupProperties.Count > 0)
        {
            ScriptManager.RegisterStartupScript(this, GetType(), Guid.NewGuid().ToString(),
                @"$(document).ready(function() { setTimeout(function() {
                    " + this.ClientID + @"_luobj.initGrid = function(seedValue, reload) {
                        LookupControl.prototype.initGrid.apply(this, [seedValue, reload]);
                        this.getGrid().getNativeGrid().getStore().setDefaultSort('" + this.LookupProperties[0].PropertyName + @"');
                    };
                }, 500) });", true);
        }
    }
}

Once you place the control in your own assembly, one tiny problem remains – by default the lookup control will try to locate the image for the button in the containing assembly. So you need to adjust that in order to make it look in the original SalesLogix assembly:

/// <summary>
/// Initialize the lookup image if necessary
/// </summary>
/// <param name="e"></param>
protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
    // Fix the image - by default the SLX controls tries to load it from the current type's assembly.
    // since this is a subclass of LookupControl it is not in the "correct" assembly anymore.
    // this fix ensures that the image is loaded from the original assembly
    if (this.ViewState["LookupImageURL"] == null)
        LookupImageURL = this.Page.ClientScript.GetWebResourceUrl(typeof(LookupControl), "Sage.SalesLogix.Web.Controls.Resources.Find_16x16.gif");
}

If you want to have it used in QuickForms you’ll have to adjust the QuickForm template – there is an example of how to do that in a previous article.

The fixed lookup is available as part of OpenSlx, but it just has the 2 above functions so you can simply rip those instead.

• you can take the OpenSlx library, modify it, and redistribute it as part of a customization, without having to publish it (though you would have to make the source code available to the customer, at their request, which is the usual business model anyway). The same apply to ripping out code – you can rip the code and put it into your own customizations, without having to publish those (other than to the user of the code, i.e. the customer – this does not include the actual end users, either SalesLogix users, or their own customers accessing SalesLogix via customer portal)
• you can take the OpenSlx library, unmodified, and include it as part of a proprietary component – you would have to make available any modification you make to OpenSlx, or any derived work (e.g. if you were to create a subclass), but other parts of your package would not be affected
• you can’t take the OpenSlx library, add some controls to it (or fix some of the existing ones), and resell it as a proprietary component – this is the kind of change that I hope would be redistributed
• you can’t rip some code from the OpenSlx library, and include it into your own, proprietary component which you resell as a software package – you have to leave the code separated. However you can rip some code, and include it into your own open source components – they will have to be released under the GPL as well, though

2010-06-27: I changed the license to Apache, so most of the restrictions above do not hold anymore, even though I still hope that you would contribute improvements back to OpenSlx. Without getting into details, this was the only practical way for me to be able to keep contributing to the code.

One of the most boring tasks when creating custom smart parts is setting up the lookups. There is next to no help from intellisense, so it takes a while to get right in the first place, but worse than that, if the user wants to add a column to a lookup you have to go through ALL the forms that have that lookup and add it by hand (this is actually a problem with QuickForms too, not just custom smart part). What a huge usability setback from the LAN client where they can just design their lookups in the Administrator.

In order to (partly) remedy that I created a component called “SimpleLookup” that runs through the Lookup table meta-data and populates the LookupProperties collection accordingly. So basically you create the lookup as:

<OpenSlx:SimpleLookup LookupName="ACCOUNT:ACCOUNT"
   LookupEntityName="Account" ID="lueAssignDistributor"
   LookupBindingMode="String" AutoPostBack="true"
   LookupEntityTypeName="Sage.SalesLogix.Entities.Account, Sage.SalesLogix.Entities"
   runat="server" />

The LookupName part is the important part – you can either put the Lookup Name (as defined in the lookup manager) or the search field (similar to how we used to reference lookups in the LAN client). Now when you want to add a column you can add it in the familiar lookup manager (though it is cached for efficiency so it may still not show up for a few minutes or until the application pool is recycled).

This SimpleLookup is part of a growing collection of components that I am able to make available as open source – it is available on GitHub at http://github.com/nicocrm/OpenSlx, along with a few other pieces like the SimplePicklist I blogged about before. Note that it won’t handle the more exotic lookup definitions (in particular any link used in the lookup must also be defined as a relationship in the Application Architect) so be sure to test the particular configuration.

• Can’t specify the validation group, in case you want the lookup to only be validated in certain cases
• More importantly, can’t specify an error message, so you are left with the default tiny-ish red asterisk. I don’t know about you but I like my error message to be big, bold, and explicit.

So we have this RequiredFieldValidator, part of the standard ASP.NET controls. This is so handy for validating textboxes but if you try to have it validate a lookup you will get this beautiful error message:

Control 'luePurchContact' referenced by the ControlToValidate property of '' cannot be validated.

There is a customvalidator that lets you specify your own validation function, and you can do that. This would look something like:

 <asp:CustomValidator ID="CustomValidator2" runat="server" ValidationGroup="SubmitCredit" Text="*" OnServerValidate="luePurchContact_Validate"
                ErrorMessage="Please select Purchasing Contact"/>

and then in the code behind:

    void luePurchContact_Validate(object source, ServerValidateEventArgs args)
    {
        args.IsValid = (luePurchContact.LookupResultValue != null);
    }

The big problem here is that this requires a postback. Postbacks are slow. You want to avoid them as much as possible. They waste bandwidth, server CPU, client CPU, they look ugly, they cause the control focus to be lost, and they mess up Javascript customizations. They suck. Furthermore, if some controls require a postback to validate, and some don’t, the users will only get a partial validation at a time, which is annoying.

Anyway, Microsoft thought the same thing of postbacks, and they provided an extension to these customvalidators that let you do the validation in Javascript. So the only difficulty is, how do we retrieve the lookup’s value in Javascript? It’s very easy if you know the client id, but ASP.NET has this nasty tendency to mangle those. Not a big deal though, as JQuery is still able to find controls based on the last characters of the id (assuming there is no other control with that same id in the page). This lets me write the following for validation:

<asp:CustomValidator runat="server" ValidationGroup="SubmitCredit" Text="*"
 ErrorMessage="Please select Purchasing Contact"
 ClientValidationFunction="(function(s, e) { e.IsValid = !!$('input[id$=luePurchContact_LookupResult]').val(); })" />

If you are suspicious about another lookup with the same id on another part of the page, use the following instead:

<div id="frmAccCredit">
<!-- 
  "frmAccCredit" would be a unique identifier for the form.
  You can use anything that is going to be unique, and put it at top level of the form.
  This is also handy for designing css rules that should not affect other
  parts of the page.
-->

...
more stuff
...

<asp:CustomValidator runat="server" ValidationGroup="SubmitCredit" Text="*"
 ErrorMessage="Please select Purchasing Contact"
 ClientValidationFunction="(function(s, e) { e.IsValid = !!$('#frmAccCredit input[id$=luePurchContact_LookupResult]').val(); })" />


cd E:\MSSQL\BACKUP\SalesLogix
dir *.trn,*.bak | where { $_.CreationTime.CompareTo([DateTime]::Now.AddDays(-2)) -lt 0 } |% `
{ & 'C:\Program Files\7-Zip\7z.exe' a "$_.zip" $_; rm $_ }


Could replace “.zip” with “.7z” to do a 7-zip compression – it will take a bit less disk space but more cpu. Could also be tweaked a bit to support recursion.

I saved that to E:\MSSQL\Backup\ZipBackups.ps1 and created a schedule task to invoke “powershell E:\MSSQL\Backup\ZipBackups.ps1″. This requires the execution policy to be set on powershell, to allow unsigned local scripts:


set-executionpolicy RemoteSigned


I am still working on getting more familiar with powershell as it can be a nifty tool (and is becoming more and more standard on Windows servers as it is bundled with other packages)

• “NullReferenceException” in the “ExtractValuesFromCell” method – this is caused by the “pseudo” cell added by the SlxGridView. To work around, turn off the “ExpandableRows” flag.
• Blank page with a NullReferenceException in the LookupControl ClientConfiguration.From method: check the provider listed in connection.config. It needs to be spelled “SLXOLEDB”. If it is spelled out “SalesLogix OLEDB Connection Provider”, it will fail (not sure why but on 7.5.2 sometimes the connection is output in that format – I think, because I created the connection in AA, instead of logging into the Admin first)
• Web client crashes when grid.Sort is called – do not call that method from the Sorting handler because it will cause infinite recursion (the Sorting handler can often be empty)
• AA gives ArgumentNullException when Update Properties is clicked: this is an installation problem. Run a repair. In fact, if you get random errors from AA, and they are not specific to one project, running a repair should probably be the first corrective action.

The article is at Back to Basics – Using Direct SQL in Web Grids