Analyzing the task, we find that it readily divides into two parts: provide a mechanism to capture/restore the DataGrid columns’ state and set up the mechanics to persist this information across application executions. This article’s focus will be the first sub-task.

Let’s extend WPF’s DataGrid, adding a two-way bindable property named ColumnInfo which exposes the necessary column state information. When a column’s state is changed, this property will be updated with the relevant information. When the property is changed (i.e. by an outside source such as a view model), the data grid’s columns will adjust themselves as specified by the property’s new value.

Catching Column Changes

To keep ColumnInfo updated with information our grid columns’ current display characteristics, we need to find out when these characteristics change.

Determining when column re-ordering occurs is easy. Simply override OnColumnReordered.

protected override void OnColumnReordered(DataGridColumnEventArgs e)
{
    UpdateColumnInfo();
    Base.OnColumnReordered(e);
}

With this code in place, if the user drags column 1 to the right of column 2 so that the column order changes from “Column 1 | Column 2″ to “Column 2 | Column 1″, our yet-to-be-defined UpdateColumnInfo will be called.

Catching column sort changes (e.g. the user clicks on a column header to sort the grid by that column’s values) requires more work. DataGrid provides an OnSorting override, but this method is called before the sort occurs. We want to inspect the grid after the sort completes but no OnSortCompleted override is provided. Are we stuck?

Thankfully not. Each of the columns has a sort direction dependency property. Let’s  iterate through the grid’s Columns collection and attach a DependencyPropertyDescriptor AddValueChanged handler to each column’s SortDirectionProperty.

At first glance, the following code seems like a good way of implementing this:

protected override void OnInitialized(EventArgs e)
{
	var sortDirectionPropertyDescriptor = DependencyPropertyDescriptor.FromProperty(DataGridColumn.SortDirectionProperty, typeof(DataGridColumn));
	foreach (var column in Columns)
	{
	    sortDirectionPropertyDescriptor.AddValueChanged(column, (sender, x) => UpdateColumnInfo());
	}
	base.OnInitialized(e);
}

However, the above creates a memory leak. The event handler lambda expression passed to AddValueChanged as its second argument captures a reference to this (our data grid). As long as this lambda expression is registered to be called when SortDirectionProperty changes, the captured this reference keeps the grid alive. The garbage collector won’t free up the memory used by our data grid, even if it is no longer being displayed.

We need a way to unregister our handler when the grid is no longer needed. Overriding Dispose (from IDisposable) would seem idea, except that DataGrid (along with most other WPF controls) does not implement IDisposable. Thankfully, FrameworkElement (a parent class of DataGrid) offers an Unloaded event. We will unregister our SorDirectionProperty change handler when this event is raised.

As it turns out, Unloaded is sometimes raised when the control needs to stay around, such as when a user-initiated system theme change occurs. We want our handler to say around as long as the control does, so we need a way to keep our handler are in place after theme changes. FrameworkElement’s Loaded event comes in handy. It’s raised whenever the control is loaded—at the initial load and at reloads after theme changes. Our OnInitialized override looks like:

private bool inWidthChange = false;
protected override void OnInitialized(EventArgs e)
{
    EventHandler sortDirectionChangedHandler = (sender, x) => UpdateColumnInfo();
    EventHandler widthPropertyChangedHandler = (sender, x) => inWidthChange = true;
    var sortDirectionPropertyDescriptor = DependencyPropertyDescriptor.FromProperty(DataGridColumn.SortDirectionProperty, typeof(DataGridColumn));
    var widthPropertyDescriptor = DependencyPropertyDescriptor.FromProperty(DataGridColumn.WidthProperty, typeof(DataGridColumn));

    Loaded += (sender, x) =>
    {
	foreach (var column in Columns)
	{
	    sortDirectionPropertyDescriptor.AddValueChanged(column, sortDirectionChangedHandler);
	    widthPropertyDescriptor.AddValueChanged(column, widthPropertyChangedHandler);
	}
    };
    Unloaded += (sender, x) =>
    {
	foreach (var column in Columns)
	{
	    sortDirectionPropertyDescriptor.RemoveValueChanged(column, sortDirectionChangedHandler);
	    widthPropertyDescriptor.RemoveValueChanged(column, widthPropertyChangedHandler);
	}
    };

    base.OnInitialized(e);
}

In the above code, notice that we also added and removed a change notification handler for DataGridColumn.WidthProperty. This makes sense as one of our goals is to record column width changes. However, instead of calling UpdateColumnInfo, this event handler sets the bool instance variable inWidthChange to true. Why?

WidthProperty is changed almost continuously when the user drags to resize a column.  We’re only interested in the column’s final width when the resizing has finished. Setting inWidthChange indicates that resizing is happening. Overriding OnPreivewMouseLeftButtonUp lets us find out when resizing completes. Before calling UpdateColumnInfo in our override, we check inWidthChange to make sure that the button release corresponds with a resize. We don’t want to call UpdateColumnInfo for non-resize related button releases.

protected override void OnPreviewMouseLeftButtonUp(System.Windows.Input.MouseButtonEventArgs e)
{
    if (inWidthChange)
    {
	inWidthChange = false;
	UpdateColumnInfo();
    }
    base.OnPreviewMouseLeftButtonUp(e);
}

Processing Changes

Our code now calls UpdateColumnInfo whenever a relevant change occurs. UpdateColumnInfo sets the grid’s ColumnInfo property to a new ObservableCollection<ColumnInfo> that containing a ColumnInfo instance for each column in the grid’s Columns collection. The updatingColumnInfo bool will come in handy shortly.

private bool updatingColumnInfo = false;
public ObservableCollection<ColumnInfo> ColumnInfo
{
    get { /* ...  */ }
    set { /* ...  */ }
}
private void UpdateColumnInfo()
{
    updatingColumnInfo = true;
    ColumnInfo = new ObservableCollection<ColumnInfo>(Columns.Select((x) => new ColumnInfo(x)));
    updatingColumnInfo = false;
}

ColumnInfo is a struct holding information on a column’s display characteristics. The convenience constructor uses a DataGridColumn to populate the struct’s values. The Apply method reverses this process, applying the display characteristics described by the struct to the passed-in column.

public struct ColumnInfo
{
        public ColumnInfo(DataGridColumn column)
        {
            Header = column.Header;
            PropertyPath = ((Binding)((DataGridBoundColumn)column).Binding).Path.Path;
            WidthValue = column.Width.DisplayValue;
            WidthType = column.Width.UnitType;
            SortDirection = column.SortDirection;
            DisplayIndex = column.DisplayIndex;
        }
        public void Apply(DataGridColumn column, int gridColumnCount, SortDescriptionCollection sortDescriptions)
        {
            column.Width = new DataGridLength(WidthValue, WidthType);
            column.SortDirection = SortDirection;
            if (SortDirection != null)
            {
                sortDescriptions.Add(new SortDescription(PropertyPath, SortDirection.Value));
            }
            if (column.DisplayIndex != DisplayIndex)
            {
                var maxIndex = (gridColumnCount == 0) ? 0 : gridColumnCount - 1;
                column.DisplayIndex = (DisplayIndex <= maxIndex) ? DisplayIndex : maxIndex;
            }
        }
        public object Header;
        public string PropertyPath;
        public ListSortDirection? SortDirection;
        public int DisplayIndex;
        public double WidthValue;
        public DataGridLengthUnitType WidthType;
}

The struct’s convenience constructor sets SortDirection from the column’s SortDirection property while the Apply method both sets this property and modifies the grid’s SortDescription collection. Why?

SortDirection indicates if the user has clicked on a column header to sort the grid by that column. However, programmaticly setting this property does not sort the grid—it simply sets the sort direction indicator on the column’s header (the little arrow displayed to indicate that the column has been sorted). If we want the grid sorted by this column, we must also update its SortDescription collection.

Changes from the Other Direction

So far, we update ColumnInfo whenever the user makes a relevant modification to the grid. Our data grid also needs to update its display in response to external ColumnInfo changes.

We’d like to be able to two-way data-bind to ColumnInfo, allowing us to connect the grid’s ColumnInfo to our view model the same way we do with ItemsSource.

<local:EnhancedDataGrid ItemsSource="{Binding Items}"
                         ColumnInfo="{Binding Columns}" />

To support two-way data-binding, ColumnInfo must be a dependency property.

public static readonly DependencyProperty ColumnInfoProperty = DependencyProperty.Register("ColumnInfo",
	typeof(ObservableCollection<ColumnInfo>), typeof(EnhancedDataGrid),
	new FrameworkPropertyMetadata(null, FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, ColumnInfoChangedCallback)
    );
public ObservableCollection<ColumnInfo> ColumnInfo
{
    get { return (ObservableCollection<ColumnInfo>)GetValue(ColumnInfoProperty); }
    set { SetValue(ColumnInfoProperty, value); }
}

When this property is changed, we want to apply the changes to the data grid’s display. ColumnInfo’s dependency property definition wires in the necessary event handling.

private static void ColumnInfoChangedCallback(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs e)
{
    var grid = (EnhancedDataGrid)dependencyObject;
    if (!grid.updatingColumnInfo) { grid.ColumnInfoChanged(); }
}
private void ColumnInfoChanged()
{
    Items.SortDescriptions.Clear();
    foreach (var column in ColumnInfo)
    {
	var realColumn = Columns.Where((x) => column.Header.Equals(x.Header)).FirstOrDefault();
	if (realColumn == null) { continue; }
	column.Apply(realColumn, Columns.Count, Items.SortDescriptions);
    }
}

The processing done in ColumnInfoChanged changes column widths and sort directions which will trigger the event handlers we registered in OnInitialized. The bool updatingColumnInfo (set in UpdateColumnInfo) prevents these changes from causing an recursive loop  of event handler calls.

Done!

There we have it—an enhanced data grid which allows us to easily persist user changes to its columns’ display characteristics!

Our EnhancedDataGrid has a few limitations. It does not support dynamic addition or removal of columns, as it add and remove column event handlers only when the grid is loaded and unloaded, respectively. It relies on ((Binding)((DataGridBoundColumn)column).Binding).Path.Path to properly identify the sort-by column(s), an assumption which may not hold true in certain scenarios. Lastly, external sources must replace ColumnInfo with a new ObservableCollection<ColumnInfo> in order to influence the grid’s display. Manipulations made to the existing ColumnInfo collection are ignored. Removing these constraints, if the need arises, is left as an exercise to the reader.

/*
The below example code is offered "as-is" with no warrantees of any kind. Use at your own risk.
*/
using System;
using System.Linq;
using System.Windows.Controls;
using System.Windows;
using System.Collections.ObjectModel;
using System.ComponentModel;
using System.Windows.Data;

namespace EnhancedwDataGridExample
{
    class EnhancedDataGrid : DataGrid
    {
        private bool inWidthChange = false;
        private bool updatingColumnInfo = false;
        public static readonly DependencyProperty ColumnInfoProperty = DependencyProperty.Register("ColumnInfo",
                typeof(ObservableCollection<ColumnInfo>), typeof(EnhancedDataGrid),
                new FrameworkPropertyMetadata(null, FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, ColumnInfoChangedCallback)
            );

        private static void ColumnInfoChangedCallback(DependencyObject dependencyObject, DependencyPropertyChangedEventArgs e)
        {
            var grid = (EnhancedDataGrid)dependencyObject;
            if (!grid.updatingColumnInfo) { grid.ColumnInfoChanged(); }
        }

        protected override void OnInitialized(EventArgs e)
        {
            EventHandler sortDirectionChangedHandler = (sender, x) => UpdateColumnInfo();
            EventHandler widthPropertyChangedHandler = (sender, x) => inWidthChange = true;
            var sortDirectionPropertyDescriptor = DependencyPropertyDescriptor.FromProperty(DataGridColumn.SortDirectionProperty, typeof(DataGridColumn));
            var widthPropertyDescriptor = DependencyPropertyDescriptor.FromProperty(DataGridColumn.WidthProperty, typeof(DataGridColumn));

            Loaded += (sender, x) =>
            {
                foreach (var column in Columns)
                {
                    sortDirectionPropertyDescriptor.AddValueChanged(column, sortDirectionChangedHandler);
                    widthPropertyDescriptor.AddValueChanged(column, widthPropertyChangedHandler);
                }
            };
            Unloaded += (sender, x) =>
            {
                foreach (var column in Columns)
                {
                    sortDirectionPropertyDescriptor.RemoveValueChanged(column, sortDirectionChangedHandler);
                    widthPropertyDescriptor.RemoveValueChanged(column, widthPropertyChangedHandler);
                }
            };

            base.OnInitialized(e);
        }
        public ObservableCollection<ColumnInfo> ColumnInfo
        {
            get { return (ObservableCollection<ColumnInfo>)GetValue(ColumnInfoProperty); }
            set { SetValue(ColumnInfoProperty, value); }
        }
        private void UpdateColumnInfo()
        {
            updatingColumnInfo = true;
            ColumnInfo = new ObservableCollection<ColumnInfo>(Columns.Select((x) => new ColumnInfo(x)));
            updatingColumnInfo = false;
        }
        protected override void OnColumnReordered(DataGridColumnEventArgs e)
        {
            UpdateColumnInfo();
            base.OnColumnReordered(e);
        }
        protected override void OnPreviewMouseLeftButtonUp(System.Windows.Input.MouseButtonEventArgs e)
        {
            if (inWidthChange)
            {
                inWidthChange = false;
                UpdateColumnInfo();
            }
            base.OnPreviewMouseLeftButtonUp(e);
        }
        private void ColumnInfoChanged()
        {
            Items.SortDescriptions.Clear();
            foreach (var column in ColumnInfo)
            {
                var realColumn = Columns.Where((x) => column.Header.Equals(x.Header)).FirstOrDefault();
                if (realColumn == null) { continue; }
                column.Apply(realColumn, Columns.Count, Items.SortDescriptions);
            }
        }
    }
    public struct ColumnInfo
    {
        public ColumnInfo(DataGridColumn column)
        {
            Header = column.Header;
            PropertyPath = ((Binding)((DataGridBoundColumn)column).Binding).Path.Path;
            WidthValue = column.Width.DisplayValue;
            WidthType = column.Width.UnitType;
            SortDirection = column.SortDirection;
            DisplayIndex = column.DisplayIndex;
        }
        public void Apply(DataGridColumn column, int gridColumnCount, SortDescriptionCollection sortDescriptions)
        {
            column.Width = new DataGridLength(WidthValue, WidthType);
            column.SortDirection = SortDirection;
            if (SortDirection != null)
            {
                sortDescriptions.Add(new SortDescription(PropertyPath, SortDirection.Value));
            }
            if (column.DisplayIndex != DisplayIndex)
            {
                var maxIndex = (gridColumnCount == 0) ? 0 : gridColumnCount - 1;
                column.DisplayIndex = (DisplayIndex <= maxIndex) ? DisplayIndex : maxIndex;
            }
        }
        public object Header;
        public string PropertyPath;
        public ListSortDirection? SortDirection;
        public int DisplayIndex;
        public double WidthValue;
        public DataGridLengthUnitType WidthType;
    }
}

Though it might seem otherwise, WPF is working just fine. The binding’s StringFormat property only applies if the binding needs to convert the bound object to a string. Since the Content property of any ContentControl (such as Label) is of type object and a string is also an object, the binding system does not need to do a conversion and so  ignores its StringFormat property.

Change the Label to a TextBlock, move the binding to its Text property and the binding’s StringFormat is applied.

<TextBlock Text=”{Binding Amount, StringFormat=C}” /> outputs $123.90.

Why? The binding subsystem knows that Text, the destination property, is of type string and so converts the non-string bound object to a string, applying StringFormat in the process.

So, how do you format the Content property of a ContentControl (such as the Label in our example)? Easy. Set the control’s ContentString property to the desired string format. If the Control’s Content property is rendered as a string—which is what happens by default with a Label control—the format specified in ContentString will be applied during the object-to-string conversion.

<Label Content=”{Binding Amount}” ContentStringFormat=”C” /> outputs $129.90!

Sometimes, it’s desirable to synchronize child report page settings to their parents. Brian Welcker posted a code sample showing how to automate this property copying using the now old-style .Net 2.0 Web Reference approach. Let’s implement the same functionality using the modern (though, unfortunately, more verbose) Service Reference approach.

For our example, we’ll use C# executed in the context of a Console Application.

Creating the Service Reference

In Solutions Explorer, right-click on the project’s References folder and select Add Service Reference. In the dialog that’s displayed, input your reporting server’s web service URL, then click Go. Once the service information fetching completes, click OK. (If you’d like, adjust the namespace to be used for the service proxy classes before clicking OK.)

Code

using System;
using System.ServiceModel;
using rs = PropertySync.ReportingService;

namespace PropertySync
{
    class Program
    {
        static void Main(string[] args)
        {
            var service = new rs.ReportingService2010SoapClient();

            // Retrieve a list of reports.
            rs.CatalogItem[] reports = null;
            service.ListChildren(new rs.TrustedUserHeader(), "/", true, out reports);

            // List of properties to copy from parent to linked reports.
            var requestedProperties = new rs.Property[] {
                new rs.Property { Name = "PageHeight" },
                new rs.Property { Name = "PageWidth" },
                new rs.Property { Name = "TopMargin" },
                new rs.Property { Name = "BottomMargin" },
                new rs.Property { Name = "LeftMargin" },
                new rs.Property { Name = "RightMargin" }
            };

            foreach (var report in reports) {
                Console.Write("{0} ({1})", report.Name, report.Path);

                if (report.TypeName == "LinkedReport") {
                    string parentReportLink = null;
                    service.GetItemLink(new rs.TrustedUserHeader(), report.Path, out parentReportLink);

                    // Fetch interested property values from parent report.
                    ReportingService.Property[] parentValues = null;
                    service.GetProperties(new rs.ItemNamespaceHeader(), new rs.TrustedUserHeader(), parentReportLink, requestedProperties, out parentValues);

                    // Set the child report's properties to the just-fetched values.
                    service.SetProperties(new rs.TrustedUserHeader(), report.Path, parentValues);
                    Console.WriteLine(" -- properties updated from {0}", parentReportLink);
                } else {
                    Console.WriteLine(" -- non-linked - skipped");
                }
            }
        }
    }
}

Compile and run. If the application executes successfully, we’re done!

Configuring the Binding

If the program fails with a security error (perhaps a MessageSecurityException), you probably need to adjust your web service binding configuration. Your code is probably trying to execute web service methods anonymously (without passing authentication credentials) while SSRS is probably configured to require client authentication.

The exact binding settings required depend on your server’s configuration—detailing the various possibilities is beyond the scope of this article. A common client configuration scenario is illustrated below:

var binding = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);
binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;

var endpointUri = "http://reporting/ReportServer_SQL/ReportService2010.asmx";
var service = new rs.ReportingService2010SoapClient(binding, new EndpointAddress(endpointUri));
service.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;

If you are using integrated (Windows) security, you may need to run your application as an administrator in order for credentials to be passed. (Hint: if you are launching the program from within Microsoft Visual Studio, run Visual Studio as an administrator.)

Shortly prior to this problem appearing, I had set a couple of configuration directives in a php.ini file fragment—something like this:

post_max_size	        2GB
upload_max_filesize     2GB

Looks correct, doesn’t it? Nope!

I learned the hard way that PHP uses single letter abbreviations to indicate kilobytes (K), megabytes (M) and gigabytes (G)! Dropping the “B” off of each “GB” fixed the problem—PHP went back to properly populating $_POST.

Interestingly, phpinfo() and ini_get() won’t necessarily cough about the extraneous “B” being present. This deceptive acceptance of incorrectly formatted configuration values can complicate debugging.

Thanks to Stack Overflow for providing the answer I needed to solve this perplexing $_POST issue!

Status code 127 is commonly used to indicate “command not found.” The error message’s bracketed portion indicates that Rake attempted to run an executable named “zip,” passing to it several arguments. By default, Windows systems do not include a command named zip. Hence, the error.

To fix this problem, configure Rake::PackageTask to use an alternative zip command by setting its zip_command property. In the example below, notice the inner quotes surrounding the path to the command. These were necessitated by the space in “Program Files.”

Rake::PackageTask.new('Module', :noversion) do |p|
  p.need_zip = true
  p.zip_command = '"C:\Program Files\7-Zip\7z.exe" a -tzip'
  p.package_files.include(..)
end

Rake::PackageTask also provides a tar_command property which can be used to override the command used to gzip and bzip2 archives.

MySQL supports incomplete dates out of the box. Simply insert zeros in place of the missing date part:

INSERT INTO TestTable (ID, IncompleteDate) VALUES
(NULL, '0000-07-10'), -- unknown year
(NULL, '2012-00-15'), -- unknown month
(NULL, '2012-06-00'); -- unknown day

Microsoft SQL Server doesn’t support incomplete dates so zeroing out a missing date part won’t work. Let’s examine several ways to work around this limitation.

Placeholder Year

Suppose we’re storing birth dates. Let’s say we know that a day and month will always be provided but sometimes the year will be omitted. That is, sometimes we’ll need to store dates in the format of March 18 (unknown year).

To use the placeholder year approach, pick a year outside the range of expected year values to use as the unknown year placeholder. In order to accommodate the date February 29 (unknown year), the placeholder year must be a leap year.  In the case of our birth date example, let’s choose year 1200 as the unknown placeholder. It’s well outside the range of birth dates used in a normal line of business application and is a leap year. To store March 18 (unknown year), we’ll insert “1200-03-18″.

With this approach, normal SQL date functions work. However, if computations involving the year are invoked, dates using the placeholder year must be filtered out.

-- Failed Attempt: Find individuals born before 1980.
-- (Problem: Records with unknown birth years will be included in the result set.)
SELECT *
FROM TestTable
WHERE YEAR(BirthDate) < 1980

-- Successful Attempt: Find individuals born before 1980
SELECT *
FROM TestTable
WHERE YEAR(BirthDate) > 1200 AND YEAR(BirthDate) < 1980

Date Parts in Separate Columns

To implement, create three columns: day, month, year. If a particular date part may be unknown, allow the associate column to store null values. To insert March 18 (unknown year), we execute:

INSERT INTO TestTable (BirthDay, BirthMonth, BirthYear) VALUES
(3, 18, NULL);

This method eliminates the use of a placeholder year and allows for unknown days and months, benefits not offered by the placeholder year approach. Its principle downside? Loss of SQL Server’s built-in date functionality (date functions, conversion/cast operations and date validation checking).

Date validation can be manually recreated using a somewhat complex set of CHECK constraints. The loss of date functions may not be the end of the world. In fact, some operations may become easier. No longer is MONTH(BirthDate) necessary. Selecting BirthMonth now achieves the same effect.

CLR User-Defined Type

In addition to the benefits of the date parts in separate columns approach, a CLR user-defined type (UDT) allows for a degree of cast/conversion operations and stores its data in a single column on the server. With this method, all functionality is packaged into a data type which can easily be reused server-wide. This data type can also be included in client-side programs, allowing those programs to locally work with retrieved data using all the methods and properties defined by the custom data type.

The downside? Out of the methods discussed, this is the most complex to implement

Solution

Include/require (perhaps using require_once) app/Mage.php in the code you execute from outside of Magento. When Mage.php is included, the code in that file will register Magento’s autoloader with PHP. Also, Mage.php contains the method definitions for the Mage singleton methods.

Learn more about unit testing code written for Magento on Magento’s wiki.

Yes! In your authorization request, put the memo text in a field called T_memo.

Thanks to Cornerstone, one of my client’s credit card processing vendor, for passing on this tip!

Foundation: The Script Comes First

Let’s start by creating a script that displays an Insert File dialog. This script should contain two steps: Set Error Options [On] followed by Insert File [Table::FieldName] (where Table is the name of the table containing the container field and FieldName is the name of the container field).

(Set Error Options [On] isn’t strictly necessary. However, if it’s left out and the user clicks cancels out of the Insert File dialog, a script error will be displayed.)

The Container’s Button Setup

Now, configure the container field’s button setup so that clicking on the field runs the script we just created. While editing the layout, right-click on the field, choose Button Setup, change the action to Perform Script then click Specify and select the script you created above. Switch from edit layout mode to view mode, then click on the container field. You should see an Insert File dialog. Excellent!

Ah…but there’s a catch. Normally, to export or delete the file stored in the container, you’d right-click on the field and choose the appropriate option from the pop-up menu. However, when we configured button setup, we overrode the field’s click behavior for both left- and right-clicks. Right-click on the field and Insert File appears instead of the pop-up menu. Unfortunately, FileMaker Pro doesn’t provide an easy way to limit our script so that it only processes left-clicks. If we want the script to handle clicks, it must handle all of them. What can we do about this?

Separate Buttons

It’s not pretty, but it works. Next to the container field, create two buttons: export and delete. Via button setup, associate each with a script that performs the appropriate action.

Export’s script contains two steps: Set Error Capture [On] and Export Field Contents [Table::FieldName].

Delete’s script uses an If statement to check if the container field is empty. If the field is not empty, the script calls Set Field [Table::FieldName, ""].

Why the If statement? Without it, clicking the delete button on a brand-new, empty portal row sets the container field to a value which causes the portal row to be inserted into the table, even though it is empty. The If statement prevents this.

To improve the user interface experience, conditional formatting can be used to make the two buttons appear disabled when the container field is empty.

When SET FMTONLY is OFF (the default), SQL Server processes control-of-flow statements normally. In the case of an IF statement, SQL Server determines which conditional expression evaluates to true and then executes the code associated with that expression. Turn FMTONLY to ON and SQL Server executes every conditional branch, even those associated with conditions evaluating to false!

To illustrate, if SET FMTONLY is OFF, executing the following SQL returns one result set containing a column named 1 = 1. With SET FMTONLY ON, the below SQL returns two result sets: one containing the already-mentioned 1 = 1 column and a second containing a column named 1 = 2. When FMTONLY is ON, the code blocks associated with both of these conditional expressions are executed—even though one of the conditions evaluates to false!

IF 1 = 1
	SELECT '1 = 1' = 'Value'
ELSE IF 1 = 2
	-- Normally, this SELECT statement would not be executed because 1 does not equal 2.
	SELECT '1 = 2' = 'Value'
END

Setting SET FMTONLY ON also changes the behavior of CONTINUE, RETURN and BREAK statements, TRY…CATCH blocks and WAITFOR statement as demonstrated by the following SQL:

SET FMTONLY ON;

DECLARE @counterContinue INT;
SET @counterContinue = 1;

WHILE (@counterContinue < 10) BEGIN
	SET @counterContinue = @counterContinue + 1;
	CONTINUE;
	-- Normally, this next SELECT statement will never be executed because of the proceeding
	-- CONTINUE; however, SET FMTONLY ON causes it to be processed.
	SELECT 'Post Continue Table' = 'Value';
END

DECLARE @counterBreak INT;
SET @counterBreak = 1;

WHILE (@counterBreak < 10) BEGIN
	SET @counterBreak = @counterBreak + 1;
	BREAK;
	-- If SET FMTONLY where OFF, this next SELECT statement wouldn't be run but
	-- because SET FMTONLY is ON, it will be executed.
	SELECT 'Post Break Table' = 'Value';
END

BEGIN TRY
	SELECT 'Try Table Column' = 'Value'
END TRY
-- Normally, this CATCH statement will only be executed if an error occurs in the TRY
-- statement block. With SET FMTONLY ON, the CATCH block will always be executed.
BEGIN CATCH
	SELECT 'Catch Table Column' = 'Value'
END CATCH

-- With SET FMTONLY ON, the no waiting occurs.
BEGIN
    WAITFOR DELAY '02:00';
    SELECT 'Wait' = 'Value'
END;

-- If SET FMTONLY is OFF, the code below this RETURN statement will never be executed.
-- When SET FMTONLY ON, the following SELECT statement is executed.
RETURN
AfterReturnLabel:
	SELECT 'After Return Label Table' = 'Value'

Why does FMTONLY ON cause this behavior change?

Here’s my guess: SET FMTONLY ON is used to retrieve metadata describing the result set(s) that could be returned when the specified query is run (i.e. run with SET FMTONLY OFF). In order for SQL Server to provide metadata on all result sets that could be returned, SQL Server must process all branches of all control-of-flow statements.