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(); })" />

Anyway, I might start writing most of the SalesLogix content through that channel so this blog does not look so much like a SalesLogix reference guide

Fortunately it is a reasonably simple problem to resolve since those picklist options are readily accessible from the database.  All we have to do really is wrap the creation of the picklist control with something that will know how to pull that info and set it on the control.  The simplest way to do that would probably be to subclass the control, but I decided to go with a decorator pattern instead (the idea was that this would let me change a bit more of the behavior, for example, replace the stock picklist with a regular dropdown).  So instead of using:

<SalesLogix:PickListControl runat="server" ID="pklType" PickListName="Account Type" AutoPostBack="true"  AlphaSort="true" MustExistInList="true" AllowMultiple="true"  />

I use:

<SSS:SimplePickList runat="server" ID="pklType" PickListName="Account Type" AutoPostBack="true"   />

Behind the scene the SimplePicklist controls reads the attributes from the database and create a Saleslogix picklist control with the proper settings, something like this:

_picklist = new PickListControl();
if ((_storageMode & PicklistStorageMode.Id) != 0)
    _picklist.StorageMode = Sage.Platform.Controls.StorageModeEnum.ID;
else if ((_storageMode & PicklistStorageMode.Code) != 0)
    _picklist.StorageMode = Sage.Platform.Controls.StorageModeEnum.Code;
_picklist.PickListName = _picklistName;
_picklist.AllowMultiples = _attr.AllowMultiples;
_picklist.AlphaSort = _attr.AlphaSorted;
_picklist.NoneEditable = _attr.NoneEditable;
_picklist.Required = _attr.Required;
_picklist.MustExistInList = _attr.ValueMustExist;
_picklist.PickListValueChanged += delegate
{
    if (TextChanged != null)
        TextChanged(this, EventArgs.Empty);
};
parentControl.Controls.Add(_picklist);

This works fine for custom smart parts, how about for QuickForms?  Well, it is possible to change the template there too, but as it is global (will affect nearly every picklist in the client) it is a bit scarier

In the Model\QuickForms\Web\QFSLXPickList.WebControlRenderingTemplate.vm I changed the control to use my “SimplePickList” instead of a PickListControl

## Simple Picklist alternative (to automatically determine the sort etc)
    <SSS:SimplePickList Compatible="true" runat="server" ID="${qfcontrol.ControlId}" #if($qfcontrol.IsReadOnly)ReadOnly="true" #end
#if(!$qfcontrol.Enabled)Enabled="false" #end
#if($qfcontrol.ToolTip != "") ToolTip="<%$ resources: ${qfcontrol.ControlId}.ToolTip %>" #end
#if($qfcontrol.HotKey != "")AccessKey="$qfcontrol.HotKey" #end
#if($qfcontrol.PickListName != "")PickListName="$qfcontrol.PickListName" #end
#if($qfcontrol.HasActionCode || $qfcontrol.AutoPostBack)AutoPostBack="true" #end
#if($qfcontrol.Required)Required="true" #end
#if($qfcontrol.MaxLength > 0)MaxLength="$qfcontrol.MaxLength" #end
#if($qfcontrol.TabIndex > 0)TabIndex="$qfcontrol.TabIndex" #end
#if($qfcontrol.StorageMode != "Text")StorageMode="$qfcontrol.StorageMode" #end
#if($qfcontrol.StyleScheme != "")CssClass="$qfcontrol.StyleScheme" #end
#if(!$qfcontrol.Visible)Visible="false" #end  />

The “Compatible=true” setting is something I added to avoid bad surprises – it forces the list to display as a standard Saleslogix picklist, instead of e.g. a dropdown.

Now because it is a custom control, it requires a change to web.config too, something like this (under system.web/pages/controls):

<add tagPrefix="SSS" namespace="SSSWorld.Slx75.Web.Controls" assembly="SSSWorld.Slx75"/>

I think it works great, but haven’t tried on a production system yet – I am going to save it for a next big project when I can get a resource to QA the entire app!  I do already use the “small” version in production in my custom smart parts, though.  I saved the code under here, if interested feel free to rip it up (though it probably has some extra dependencies so it will require a bit of cleanup).

So although I think the PickListControl should support this out of the box it is nice to see that it is not too hard to add the functionality ourselves.

Sorry for the chopped image, I had to hide the name and was too lazy to re-run on the eval db.

The problem is the popup takes a couple seconds to come up on IE7, sometimes more on slow machines or slow connections – it’s a bit irritating.  After a brief phase of denial (how dare they refuse the New and Improved way, etc) I set to work.  Had to struggle a bit with the combination of available properties but finally got it working.  Configuring lookup is definitely a big pain on the web client!  This is the winning combo:

• Display Mode = DropDownList
• Display Property = UserInfo.UserName
• Lookup Entity Name = User
• Lookup Binding Mode = Object
• In the Lookup Pre Filters, add a filter on “Enabled” (make sure the property is populated as System.Boolean, and set OperatorCode to “=”) and filter value of “true”

The DropDown style lookups are a bit more picky on the parameters than the regular lookup, because they actually use NHibernate parameters instead of inline HQL.  In general I would say it is a good thing to use parameters, though in this case it makes it a bit harder for us to hack around the limitation of the control.

Data binding works fine, the only big problem I have found is that it sorts by first name instead of last name for some reason (which you can’t really see in the screen shot as I removed the last name but you can imagine).