Jason Buss' Blog : Basics, Customizations, SalesLogix LAN Client

Using Picklist data revisited

Jason Buss — Wed, 12 Aug 2009 11:00:00 GMT

Back in January, I posted about the SalesLogix picklist data structure, and outlined how to use the data found in the picklist table to populate other controls such as comboboxes and listboxes. You can find that article here.) If you are performing customizations to version 7.2 or later of SalesLogx, this processes can be greatly simplified by using Application.Picklist instead of directly querying the database.

By using Application.Picklist, you no longer need to understand how SalesLogix stores picklist data. This also serves to clean up your code, since you don't have to look at the picklist table.

As an example, here is code populating a ListBox control with the values from the "Contact Type" picklist.

Dim x
Set objList = Application.PickLists.Item("Contact Type")
ListBox1.Items.Clear
For x = 0 To objList.Count - 1
ListBox1.Items.Add(objList.Item(x))
Next
Set objList = Nothing

That's all there is to it. Much simpler than looking at the picklist data directly via a query. Remember though, Application.picklists is ONLY available on implementations of SalesLogix version 7.2 or greater.

Thanks for reading!

Using SQL views to incorporate external data into SalesLogix customizations

Jason Buss — Wed, 05 Aug 2009 11:17:00 GMT

Did you know that you can include SQL views in SalesLogix? This can be a very handy method to include data that is not normally part of SalesLogix. It is important to note, that these changes are not sync-aware. However if you are running SalesLogix LAN in a network only environment, this can be a helpful way to include data from external sources.

First of all, we need a view. This could be anything, as long as the view is created in your SalesLogix database and is owned by the SYSDBA user. For this example, I'll add a simple view of accounts/primary contacts from another SLX database in Query analyzer:

create view vAccountViewTest as

    select
        a.accountid,
        a.account,
        c.lastname,
        c.firstname from

        SalesLogix2.sysdba.account a
    inner join
        SalesLogix2.sysdba.contact c

    on a.accountid = c.accountid

    where c.isprimary = 'T'

Once this view is created, it will show up in the database manager:

If you get the properties of that view, you simply need to "Enable" the view for use in SalesLogix:

Now that the view has been enabled, you can use it in SalesLogix, just as you would use any other table in the system, for example, in a datagrid:

That's basically it! I hope you found this post helpful.

Using the Forms collection in the SalesLogix LAN client

Jason Buss — Wed, 24 Jun 2009 17:56:00 GMT

From time to time, you may find that you want to reference a control or script on a form other than the one you are currently on. This can be done easily using the Forms collection in SalesLogix.

The first thing we need to do is to loop through all open forms, checking for the desired form. For this example, we'll look for the Contact Detail form. (Note: we're looking for the value contained within the "Name" property of the form we are looking for.):

    Dim frm
    Dim x

    For x = 0 to Application.Forms.Count - 1
        If Application.Forms(x).Name = "frmContactDetail" Then
            Set frm = Application.Forms(x)
            Exit For
        End If
    Next

Once this code runs, we should have an object (frm) containing a reference to that form. If the form is not found, the code will return null, which we should look for before trying to manipulate anything

If Not frm Is Nothing Then
End If

Any references should be done within that IF statement. To access properties, you just need to include the form object (frm.{control}.{property}). For scripts, you'll need to access the forms Scripts collection (frm.scripts.{sub or function name})

That's all there is to it. All in all, pretty easy, right?

Keep in mind, this does require that the form you want to reference actually be open. If you want access to information to information on an uninitiated form, you'll need to access the appropriate tables directly.

Hope you find this post helpful. Thanks again for reading

User feedback using the Animate Control

Jason Buss — Wed, 13 May 2009 09:52:00 GMT

In my last blog post, I described how to use the Progress Bar control to provide feedback to a user when running time intensive processes. In addition to the Progress Bar control, the Animate control can also be used.

Animate Control

The Animate control is very simple to use. A number of animations are inlcuded to cover standard operations such as moving or coping and deleteing items, and some other additional animations.

After adding the control to the form, choose one of the standard animations from the "CommonAVI" property of the form. I also set the visble property, and the Active property to false at design-time, so that I can turn both properties on in code to make visible and start the animation.

I've used my code example from last week, and included a call to a control named "Animate1" on the form.

Sub UpdateAccounts

Dim rs

Set rs = CreateObject("ADODB.Recordset")
With rs, pos

        pos = 0

         Set .ActiveConnection = Application.GetNewConnection
         .CursorLocation = adUseClient
         .CursorType = adOpenStatic
         .LockType = adLockOptimistic
         .Open "select * from Account where status <> 'Open'"

         ProgressBar1.Max = .RecordCount
         ProgressBar1.Position = pos

         .MoveFirst

         Animate1.Visible = True
         Animate1.Position = True

         While Not (.Bof or .Eof)

             .Fields("modifyuser").Value = Application.BasicFunctions.CurrentUserID
             .Fields("modifydate").Value = Now
             .Fields("status").Value = "Open"

             .Update

             pos = pos + 1
             ProgressBar1.Position = pos

             .MoveNext
         Wend
         .Close

         Animate1.Visible = False
         Animate1.Active = False

End With
Set rs = Nothing

End Sub

In addition to the available preset animations, you can also use the Animate control to disaply an AVI file instead. To do this, you'll want to set the "CommonAVI" to aviNone, and then enter the path and file name for the AVI file you would like to display. The Animate and Visible properties will function the same regardless of the animation source.

(the clock.avi under c:\windows is a simple avi displaying a running count from 1 to 10.

That's all there is to it. The Animate control is a very simple way to spruse up your views when performing time-consuming updates. Thanks for reading!

Providing interface feedback - Progress Bars

Jason Buss — Thu, 07 May 2009 11:14:00 GMT

When performing lengthy updates in the SalesLogix client, it's a good idea to provide the user with some degree of feedback so that it doesn't appear as though SalesLogix has locked up. The Progress Bar control, can be used for this purpose:

Progress Bar

The main properties in this control you will want to set are the "Max" and "Position" properties. "Max" defines the upper limit of the bars position. "Position" defines the current position of the bar. Basically, we just need to set "Max" to the count of records modified, and then need to increment the "Position" value by one for each record we update.

In this simple example, I'm simply running through the Account table, and setting the status value from each record to "Open" when it doesn't already have that status.

Sub UpdateAccounts
Dim rs

Set rs = CreateObject("ADODB.Recordset")
With rs, pos

        pos = 0

         Set .ActiveConnection = Application.GetNewConnection
         .CursorLocation = adUseClient
         .CursorType = adOpenStatic
         .LockType = adLockOptimistic
         .Open "select * from Account where status <> 'Open'"

         ProgressBar1.Max = .RecordCount
         ProgressBar1.Position = pos

         .MoveFirst

         While Not (.Bof or .Eof)

             .Fields("modifyuser").Value = Application.BasicFunctions.CurrentUserID
             .Fields("modifydate").Value = Now
             .Fields("status").Value = "Open"

             .Update

             pos = pos + 1
             ProgressBar1.Position = pos

             .MoveNext
         Wend
         .Close

End With
Set rs = Nothing
End Sub

That's all there is to it. Users will now be able to visually follow the progress of the update. I hope you found this code sample helpful!

Adding items to the Opportunity Snapshot (LAN)

Jason Buss — Wed, 29 Apr 2009 12:51:00 GMT

The opportunity snapshot on the Opportunity Detail view is a handy place to display summary information, but customizing it can be a bit confusing. The Snapshot is simply a browser control, displaying HTML which is being generated by a method on the Opportunity detail screen. You can see the HTML code in that method (LoadSnapShot), but it is so broken up and pieced back togther to add variable data, that it can be a little tough to navigate. Hopefully this basic rundown helps explain how the snapshot is put together, and how simple it can be to add new information.

First, let's take a look at the conditions involved in generating the snapshot (Opportunity Detail view, LoadSnapshot method). Primarily, the Opportunity status is checked to determine which version of the snapshot is to be displayed. I've cleared out the html in this code, so we can see how things are setup based on status.

The first thing checked is to see if the current status is either Open or Inactive (I've cleared out localization code as well to make this more readable):

If strStatus = "Open" Or pklStatus.Text = "Inactive" Then

In this area, they set up the header information for the HTML
    If Not blnMCEnabled Then
Here they display pricing information, depending if Multi Currency is enabled or not.
    Else
    End If

Finally, they show summary information for the opportunity which is not reliant on currency. This is usually fields like Days Open, Current Stage, etc... This is repeated for both Closed statuses as well as a catch all for any other status value.

ElseIf strStatus = "Closed - Won" Then
'Header Info
    If Not blnMCEnabled Then
'MultiCurrentcy enabled
    Else
'MultiCurrentcy disabled
    End If
'Summary Information
ElseIf strStatus = "Closed - Lost" Then
    If Not blnMCEnabled Then
    Else
    End If
Else 'The code below is a "default" if the user addes a picklist value that doesn't equal the above conditions out of box.
    If Not blnMCEnabled Then
    Else
    End If
End If

That's all there is to the code in terms of WHERE you want to edit, but there is a lot of broken up HTML to navigate at that point; However, If you search for label values in the Snapshot code, and do a little copying/pasting, it's not do difficult to add some additional information to this area.

I'm going to add a "Total Margin" field in the Value section of the snapshot. Total Margin will be defined as (TotalSales - TotalFixedCost) / TotalSales. We'll want to calculate margin based off of both SalesPotential for Open Opportunities, and ActualAmount for Closed Opportunities.

First of all, we need to get the total cost value. I'm going to add this code near the top of the LoadSnapShot method on Opportunity Detail. This will give me a variable name dTotalCost containing the total cost value for all products on the current opportunity:

Dim dTotalCost

    Set objCostRS = objSLXDB.GetNewRecordSet
    strSql = "select sum(p.fixedcost) as totalcost from opportunity_product o inner join product p on o.productid = p.productid" & _
             "Where o.opportunityid = '" & strCrntOppID & "'")
    objCostRS.Open strSql, objSLXDB.Connection

    If objCostRS.RecordCount <> 0 Then
        dTotalCost = objCostRS.Fields("totalcost")
    Else
        dTotalCost = 0
    End If

objCostRS.Close
Set objCostRS = Nothing

Now that we have cost, we have to calculate the margin. I do this in two places actually. First right outside the first If statement that checks the opp status, and I also set it inside the If statement if status is "Open". I do this because margin will be based off of the Actual Close Amount if the Opp has any closed status, and off of Sales Potential if the status is Open or Inactive.

(My added code is in bold, you will probably find this right around line 370 on the Opp detail form code)

            If IsNull(objRS.Fields("WSALE").Value) Then 'DNL
               lngWeighted = 0
            Else
               lngWeighted = objRS.Fields("WSALE").Value 'DNL
            End If

            If cDbl(intActualAmount) = 0 Then
                dMargin = 0
            Else
                dMargin = (cDbl(intActualAmount) - cDbl(dTotalCost)) / cDbl(intActualAmount)
            End If

            Application.BasicFunctions.GlobalInfoSet "CurrentStatus", strStatus 'DNL
            If Application.Translator.Localize(strStatus) = Application.Translator.Localize("Open") Or Application.Translator.Localize(pklStatus.Text) = Application.Translator.Localize("Inactive") Then 'DNL

               If lngSalesPotential = 0 Then
                    dMargin = 0
               Else
                    dMargin = (cDbl(lngSalesPotential) - cDbl(dTotalCost)) / cDbl(lngSalesPotential)
               End If

Now that we've calculated the Margin value, we need to insert it into the snapshot. Because of how the snapshot is being built, we'll need to add it in eight different places, twice for each Opportunity Status (Open or Inactive, Closed Won, Closed Lost, other). If you know that multicurrency functionality is not an important aspect of your database, you can add it only once for each status).

                  vHTML = vHTML + "<td class=indent>" & Application.Translator.Localize("Sales Potential = ") & FormatCurrency(lngSalesPotential, 2)
                  vHTML = vHTML + "</tr><tr>"
                  vHTML = vHTML + "<td class=indent>" & Application.Translator.Localize("Weighted = ") & FormatCurrency(lngWeighted, 2) 'Calculated Field
                  vHTML = vHTML + "</tr><tr>"

You can justcopy the last two lines here, and change the copied line to use our new margin values to add it to the snapshot.

vHTML = vHTML + "<td class=indent>" & Application.Translator.Localize("Margin = ") & FormatCurrency(dMargin, 2) 'Calculated Field
vHTML = vHTML + "</tr><tr>"

You'll then want to go through the code and add this new line in each of the MultiCurrency sections for each status.

Adding a single new value is simple enough, but if you try to get more complicated with it, keep a close eye on <td> and <tr> tags before and after any code you enter to avoid breaking the Snapshot all together.

I hope this post is helpful in explaining the basics of how the snapshot is put together, and encourages people to experiment with modifications to this area. Thanks for reading!

Building new Main Views in SalesLogix LAN - Part 1

Jason Buss — Wed, 01 Apr 2009 11:51:00 GMT

For my next few blog posts, I'll go through the steps required to create a new main area in SalesLogix.

We'll be creating a new area in SalesLogix that I'll call SLXProjects. When we're finished, we'll have a fully functional project management system. I'll be going through this just a few steps at a time, to make this as understandable as possible... If you have any questions on any of these posts, please feel free to add comments to the post.

First, we need to create the main data structure. I've created a table named 'SLXProjects', containing fields for Name, Project, Leader, IsActive and AccountID.

Next, I'll create the detail view for this area, containing the fields I added in the new SLXProjects table (We'll clean up this view later). This view should be saved under the System Family.

Next, we need to create a new Main View. This view will act as the container for the detail view for this area, as well as any tabs that we will create.

On the main view, select the details section, and set the "View Name" property to the the detail view we created.

So, at this point, we have created our new table, main view and detail view. In the next article, we'll go through creating the Toolbar and Menu plugins and creating tabs for our new area, as well as finishing setting up the detail view.

Thanks for reading, and Stay tuned!

Form types in the SalesLogix LAN Client

Jason Buss — Wed, 25 Mar 2009 10:40:00 GMT

I wanted to take this blog post to briefly outline the different types of Forms available to you in the SalesLogix LAN client, mostly for anyone who is new to creating views and customizing SalesLogix.

Essentially, there are three types of Forms: MainView forms, Data Forms and Manage Forms. (I suppose you could include Legacy Views as well, but if you are still using legacy forms, it may be time to reconsider your customizations!)

MainViews

MainViews are forms which define the "Main" areas of SalesLogix, such as Account, Contact, Tickets etc..

The form contains sections for the various sections visible in SalesLogix (Details, Middle, Tabs and Groups), which are set up to display other Views build for that table in SalesLogix. I'll get into the details of creating a MainView in a future posting.

Data Forms

Simply put, a Data Form is a form based off of a particular table in SalesLogix. Most often, these views are used to create tab views in SalesLogix.

When creating a new data form, you are presented with the Select Main Table dialog, which allows you to choose which table the form is based on. Fields from whichever table is selected (including joins) will be available when setting the Text property of any control you may add to the form.

When creating a form, there are options to create an Account, Contact, Opportunity, etc. forms, but essentially these are data forms as well. SalesLogix simply provides a set of common view types. There is no difference between creating an Account Form, or a Data Form and selecting "Account" in the Select Main Table dialog.

Manage Forms

A manage form is basically a form which is not related to a specific table in the database. Almost any control on this type of form must be populated via code in some way (ADO is a great option, here's somthing to get you started ). The SQL property of Datagrid controls can be set on Manage forms to display information from tables, however you would have to set the bindid and refresh the grid to show desired information. Typically, I use manage forms called from either a toolbar button or menu item to set custom system-specific data in SalesLogix.

I'll get into details of creating each of these types of forms in my next blog post. For now, I hope this gives you an idea of what is available in the LAN client and I also hope that you will take some time to experiment with what is available. Thanks for reading!

SalesLogix Basics 5 - SplitterPanel Control

Jason Buss — Wed, 25 Feb 2009 11:21:00 GMT

The SplitterPanel control in SalesLogix gives you the ability to partition a view into sections, and gives you the ability to resize the panels at run-time by dragging the splitter line on the control.

For this example, I've created a simple contacts view at the account level which contains a grid on the left, with a number of controls on the right specific to the selected contact in the grid. This is very similar to the standard history view where history details are displayed on the right for each selected history item

The control is fairly easy to use, and I won't go thorugh all the properties here, but there are two things that you need to know in order to use the control effectively. First of all, you cannot copy and paste controls onto the right side of the SplitterPanel. To get controls on the right side of the control, you need to add them directly from the toolbox. Any control that you try to copy and paste will end up on the left side of the panel instead.

Second, the controls "Size" property controls the default size of the left side of the panel. The right side fills the remainder of the space available.

To build the view in this sample I added a datagrid with a contact fields, and added some random contact fields on the right side of the splitter to be populated each time a row is selected. Nothing special about the grid setup. It's just bound to the contact table via AccountID. The other fields are not bound, but will be populated programatically on the OnRowSelect event of the grid.

The code to populate the fields goes like this:

'Including Script - System:SLX Database Support
option explicit

Sub DataGrid1RowSelect(Sender)
    Dim sContactID

    sContactID = DataGrid1.GetCurrentField("contactid")

    txtAssistant.Text = GetField("Assistant", "Contact", "contactid = '" & sContactID & "'")
    txtBirthday.Text = GetField("Birthday", "Contact", "contactid = '" & sContactID & "'")
    txtSpouse.Text = GetField("Spouse", "Contact", "contactid = '" & sContactID & "'")
    txtSpouseBirthday.Text = GetField("SpouseBirthday", "Contact", "contactid = '" & sContactID & "'")
End Sub

That's all there is to it. I hope you find this example helpful! Thanks for reading!

SalesLogix Basics 4 - ADO Recordsets in SalesLogix LAN

Jason Buss — Wed, 11 Feb 2009 13:25:00 GMT

By using ADO, you have a powerful resource for reading and storing data in SalesLogix. In this basics article, I'll outline the main components involved in constructing and using an ADO recordset in general, and specifically with SalesLogix . If you've never worked with ADO before, this simple example will give you what you need to incorporate ADO into your own customizations.

Example:

Set rs = CreateObject("ADODB.Recordset")
With rs
         Set .ActiveConnection = Application.GetNewConnection
         .CursorLocation = adUseClient
         .CursorType = adOpenStatic
         .LockType = adLockOptimistic
         .Open "select * from c_test where c_testid = '" & labelID.Caption & "'"

         If .RecordCount = 0 Then
            .AddNew
            .Fields("c_testid").Value = Application.BasicFunctions.GetIDFor("c_test")
            .Fields("accountid").Value = CurrentID
            .Fields("createuser").Value = Application.BasicFunctions.CurrentUserID
            .Fields("createdate").Value = Now
         End If

         .Fields("modifyuser").Value = Application.BasicFunctions.CurrentUserID
         .Fields("modifydate").Value = Now
         .Fields("field1").Value = edit1.Text
         .Fields("field2").Value = edit2.Text
         .Update

         .Close
End With
Set rs = Nothing

Connection

The basic steps for using an ADO Recordset are:

Create and ADO connection to the database
Open the database connection
Create an ADO recordset
Set connection options for the recordset.
Open the recordset
Extract/Modify the data you need from the recordset
Update the recordset (if modified)
Close the recordset
Close the connection.

*These first two steps are handled by SalesLogix so we don’t need to worry about them within the SLX Environment. I’m including them here just to list all the steps in working with a ADO Recordset

Create an ADO connection to the database

set conn=Server.CreateObject("ADODB.Connection")

conn.Provider="Microsoft.Jet.OLEDB.4.0"

In this code, we have created a connection object and are using the JET OLEDB provider to connect to an Access database

Open the database connection

conn.Open "c:/webdata/northwind.mdb"

This code uses the connection object to open the access database, “Northwind”.

Create an ADO recordset

Set objRS = CreateObject(“ADODB.Recordset”)

Set objRS.ActiveConnection = Applcation.GetNewConnection

Here we have created the basic ADO recordset object, and set it to use a connection from the SLX connection pool.

Set connection options for the recordset

Cursors are used to control a few different things, namely record navigation, visibility of changes in the database, and updatability of data.

Cursor Location:

The cursor location can be set to use either the Server or Client cursor service. Basically, this controls weather or not processing is done on the server or on the individual client machine. Server-side cursors are used by default.

Enumerated values:

adUseServer (default)
adUseClient

Cursor Type:

The cursor type controls how you can cycle through the records returned in the recordset as well as visibility of any changes you make.

Enumerated values:

adOpenForwardOnly (Default)

Uses a forward-only cursor. Identical to a static cursor, except you can only scroll forward through records. This can improve performance when you need to make only one pass through a recordset.

adOpenKeySet

like a dynamic cursor, except that you can’t see records that other users add, although records that other users delete are inaccessible from your Recordset. Data changes from other users are visible.

adOpenDynamic

Additions, changes and deletions by other users are visible, and all types of movement through the Recordset are allowed.

adOpenStatic

Additions, Edits and Deletes from other users are not visible.

Lock Type:

The lock type specifies the type of locking when editing values in the recordset.

Enumerated Values:

adLockReadOnly

Recordset is read-only

adLockPessimistic

The provider locks records immediately after editing.

adLockOptimistic

Records are locked only when Update is called

adLockBatchOptimistic

Records are locked when updated is called. Required for batch updates.

objRS.CursorLocation = adUseClient

objRS.CursorType = adOpenStatic

objRS.LockType = adLockOptimistic

Open the recordset

Here we are opening the recordset, using the SQL query provided.

objRS.Open “Select * from TestTable where 0=1”

Extract/Modify data from the recordset

Values are returned using (in this case set to a variable strValue):

strValue = objRS.Fields(“FieldName”).Value

Values can also be set by using:

objRS.Fields(“FieldName”).Value = “New Value”

Update the recordset

objRS.Update or objRS.UpdateBatch

The update command applies changes made to the recordset. Until this is called, the changes are not permanent. Closing the recordset before calling update would cause the changes to be lost.

Close the recordset

objRS.Close

Set objRS.Nothing

This statement closes the recordset when you are done. Setting the object = “Nothing”, aka “Destroying” the object, frees up the resources used by the recordset object.

Close the connection

This step is not needed when using recordsets in SalesLogix. The connections would be closed when closing the database.

Batch Updates Example:

By using the locktype of adLockBatchOptimistic and UpdateBatch, you can loop through a number of updates, and commit them all at once.

Set rs = CreateObject("ADODB.Recordset")

With rs

         Set .ActiveConnection = Application.GetNewConnection

         .CursorLocation = adUseClient
         .CursorType = adOpenStatic
         .LockType = adLockBatchOptimistic

         .Open "select * from c_test where Value = '" & labelID.Caption & "'"

          While not (.Bof or .Eof)

              .Fields("modifyuser").Value = Application.BasicFunctions.CurrentUserID
              .Fields("modifydate").Value = Now
              .Fields("field1").Value = edit1.Text
              .Fields("field2").Value = edit2.Text

              .MoveNext

         Wend

         .UpdateBatch
         .Close

End With

Set rs = Nothing

I hope you find this example helpful. Thanks for reading!

SalesLogix Basics 3 - Radio Buttons VS Radio Group controls

Jason Buss — Thu, 08 Jan 2009 11:20:00 GMT

For this basics article, I just wanted to outline the differences between the Radio Button and Radio Group controls, and when you would want to use one vs. the other.

Both controls provide a similar sort of interface to end users, allowing them to select one out of many available options. Differences in how the information is saved, however, could determine which method is used.

Using a radiogroup control, you would only need a single field in the database to hold the resulting value. In addition, the value stored is the actual string displayed in the group itself. In this example, I create a field called "GroupOptions". When this record is saved, the value of "Test1" is stored in the database.

To set up the radiogroup control, you just need to add each option to the "Items" property of the control. If you set the "Columns" property of the control, then the options will be split evenly between however many columns are defined.

With radio buttons, you would need a field for each option. A value of either "T" or "F" is stored for the option selected. For this example, I've created 4 fields; "GroupOption1", "GroupOption2", "GroupOption3" and "GroupOption4". When this record is saved, a value of "T" would be stored in the "GroupOption1" field, while "F" is stored in the "GroupOption2" - "GroupOption3" fields.

Radio buttons only allow one selection within whatever control container the radiobuttons are contained. In order to group these specific options together, I've used a panel control as a control container. Do do this, you just need to drop the panel control on the form, then drop the RadioButton controls on that Panel control. Each radiobutton is a seperate control.

So those are the main differences between those controls. To summarize:

Radiogroup:

Only one control needs to be defined
Only one field needs to be added to the database
Literal value is stored in the database

RadioButtons

A field for each option must be added to the database
You must add a control for each field
If you want to set up multiple option groupings on a form, and additional control container must be used (such as a panel control)
"T" or "F" is stored in the database for the option selected.

Thanks for reading!

SalesLogix Basics 2 - Basic Scripting/Control Events

Jason Buss — Mon, 29 Dec 2008 15:44:00 GMT

It's simple enough in the SalesLogix LAN client to slap a bunch of bound controls on a form, but if you want to perform any sort of action on that data, chances are you are going to be writing code on various events available to you.

As a simple example, I'll build a simple account level form, using code to return a count of contact records associated to that account

An event in simply a user or system initiated action. The form itself has a number of events. In this example, I'm using the form's WhenChange event to display the current last modified date for the account, and to set the default text on the button. The WhenChange event fires every time a form is associated with a new ID record, such as moving in between account records.

'Including Script - System:SLX Database Support
option explicit

Dim AccountID

Sub AXFormChange(Sender)
    SetControlDefaults
End Sub

Sub SetControlDefaults
    AccountID = txtCurrentID.Text
    dteLastModifiedDT.Text = GetField("MODIFYDATE", "ACCOUNT", "ACCOUNTID = '" & AccountID & "'")
    txtCount.Text = "Calculate"
End Sub

On the WhenClick event of the button, I call a function using the SLX Database Support script's GetField function to return a count of the contacts for the current account, and set the Button's Caption property to display that value.

Sub cmdGetCountClick(Sender)
Sender.Caption = GetCount(AccountID)
End Sub

Function GetCount(sAccountID)
GetCount = GetField("count(*)", "contact", "accountid = '" & AccountID & "'")
End Function

Obviously, this is a pretty simple example and there are many more things you can do via code in SalesLogix. There are many good VBScript language references available online, and it wouldn't hurt to find a good ADO reference as well. I'll be providing other simple code snippets in future articles, so please keep reading!