sUser = GetField("userid", "userinfo", "region = '" & Sender.Text & "'")
If sUser <> lueAccMgr.LookupID Then
  If MsgBox("Would you like to change the account manager to match selected region?", vbOkCancel) = vbOk Then
   lueAccMgr.LookupID = sUser
  End If
End If

In the web client you would want to do something like this:

IUser user = GetUserByRegion(CurrentEntity.Region);
if(user != CurrentEntity.AccountManager){
  if(PromptUserForConfirmation()){
    CurrentEntity.AccountManager = user;
  }
}

But how to implement the “PromptUserForConfirmation” method? You can’t do a modal dialog box from server-side code.

One method would be to implement all of the logic from client side. You can use an ajax call (maybe using sdata) to implement the “GetUserByRegion” in Javascript, and probably in this particular case it would be simple enough to be very feasible.

Sometimes there is a bit too much logic on the server side to be ported over to javascript, or you just don’t want to have to load too much logic on the client (which is often harder to maintain). In that case you can use what I call the “hidden button” trick. This keeps most of the logic on the server and separate the process in 2 steps, using a non-displayed button on the client to allow the script to “resume”. The button on the page would be something like (make sure you do “display: none”, not “Visible=false”, as the latter would prevent the button from being output on the page at all):

<asp:Button style="display:none" runat="server" id="btnConfirmRegionManagerChange" OnClick="btnConfirmRegionManagerChange_Click"/>

The code on the picklist change event would become:

// first postback, executes when the user has just made the picklist change
// (assuming the picklist is set up to autopostback)
// here we run the first part of the logic
IUser user = GetUserByRegion(CurrentEntity.Region);
if(user != CurrentEntity.AccountManager){
  // register a client script to show confirmation prompt and simulate a button click
  ScriptManager.RegisterStartupScript(this, GetType(), Guid.NewGuid().ToString(),
   "if(confirm('Would you like to change the account manager to match selected region?')) " +
     "$('#" + btnConfirmRegionManagerChange.ClientID + "').click();", true);
}

And finally the handler for the btnConfirmRegionManagerChange click would take care of the second part of the process:

// Here we just call the GetUserByRegion method again...
// If there was a lot of processing involved you could cache the result from the previous postback
// into a hidden field or a ViewState variable
IUser user = GetUserByRegion(CurrentEntity.Region);
CurrentEntity.AccountManager = user;

This way you have a bit of extra work, but the basic structure of the code remains the same so it is still easy to follow. I should mention I have not actually tried the code snippets above so if you copy / paste and find any typo please let me know.

Hope this helps!

Also not sure when they added the Windows “Micro” instance – not part of this free tier but at $.03/hr that would be very economic way to run a small site if you need a bit more control than with an ASP.NET host (no, I very much doubt you can run SalesLogix on it, hah). It comes off quite a bit cheaper than MS Azure and I am not too sure what Azure buys you for the extra cost. Will be an interesting competition to watch in the coming months.

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