Posts Tagged C#

C#: Multiple Dynamic Properties on a Class Either Defined or with Generics

Using the class indexer of C# (abc[ xxx ] = yyy) we can create a class which has multiple dynamic properties associated by a string or whatever we want as the key for access. In the example below we use a string as our access key and holds a string as a value. The storage is accomplished by using a dictionary. See the Usage method below on how to access it.

public class MultipleDynamicProperties
{

    private Dictionary<string, string> _dynamicProperties = new Dictionary<string, string>();    
    
    // Index the data here  
    public string this[string key]
    {
        get
        {
            if ( _dynamicProperties.ContainsKey( key ) == false )
                _dynamicProperties.Add( key, string.Empty );

            return _dynamicProperties[key];
        }
        set
        {
            if ( _dynamicProperties.ContainsKey( key ) == false )
                _dynamicProperties.Add( key, value );
            else
            {
                _dynamicProperties[key] = value;
            }
        }
    }

    /// <summary>
    /// Example don't use in your code.
    /// </summary>
    public static void Usage()
    {
        MultipleDynamicProperties mdc = new MultipleDynamicProperties();

        mdc["Jabber"] = "1st Attempt";
        mdc["Jabber"] = "Wocky";
        mdc["Omega"] = "Man";

        Console.WriteLine("Jabber: " + mdc["Jabber"]); // Printers Jabber: wocky

    }

}

Using other index types say integer or enum, we can accomplish the same goal by changing or adding to our index’able properties of the class. We could have multiple accessors as long as the key is not the same. Below is an example using an enum as the key and a List<string> as the value returned:

public class MultipleDynamicPropertiesWithEnum
{
    public enum Operation
    {
        TargetA,
        TargetB,
    }

    private Dictionary<Operation, List<string>> _dynamicProperties = new Dictionary<Operation, List<string>>();


         // Index the data here  
    public List<string> this[Operation key]
    {
        get
        {
            if ( _dynamicProperties.ContainsKey( key ) == false )
                _dynamicProperties.Add( key, new List<string>() );

            return _dynamicProperties[key];
        }
        set
        {
            if ( _dynamicProperties.ContainsKey( key ) == false )
                _dynamicProperties.Add( key, value );
            else
            {
                _dynamicProperties[key] = value;
            }
        }
    }

    public static void Usage()
    {
        MultipleDynamicPropertiesWithEnum show = new MultipleDynamicPropertiesWithEnum();

        show[Operation.TargetA] = new List<string>() { "Jabber" };
        show[Operation.TargetB] = new List<string>() { "Wocky" };

        // Prints Jabberwocky 
        Console.WriteLine( show[Operation.TargetA][0] + show[Operation.TargetB][0] );
    }
}

 

Generic Option

But why limit ourselves, why not make the accessor generic, so the user/consumer can dictate what the keys and what data is returned. Here is the generic version where we mimic the hard coded version of string and string.

/// <summary>
/// This class has a generic indexor defined by the generic parameters specified
/// by the consumer.
/// </summary>
/// <typeparam name="KY">Key type to use to acces the value type to store.</typeparam>
/// <typeparam name="T">The value type to store.</typeparam>
/// <remarks>See Usage on how to use.</remarks>
public class MultipleDynamicPropertiesAsGeneric<KY, T>
{

    private Dictionary<KY, T> _dynamicProperties = new Dictionary<KY, T>();

    // Index the data here  
    public T this[KY key]
    {
        get
        {
            if ( _dynamicProperties.ContainsKey( key ) == false )
            {
                _dynamicProperties.Add( key, Activator.CreateInstance<T>() );
            }

            return _dynamicProperties[key];
        }
        set
        {
            if ( _dynamicProperties.ContainsKey( key ) == false )
                _dynamicProperties.Add( key, value );
            else
            {
                _dynamicProperties[key] = value;
            }
        }
    }

    public static void Usage()
    {
        MultipleDynamicPropertiesAsGeneric<string, string> show = new MultipleDynamicPropertiesAsGeneric<string, string>();

        show["Jabber"] = "Wocky";

        // Prints wocky 
        Console.WriteLine( show["Jabber"] );

    }

}
Share

Tags: ,

C# WPF: Threading, Control Updating, Status Bar and Cancel Operations Example All In One

You're All Mine Bringing them together; this article shows how to do GUI processing and background work in WPF using C# with an eye on progress and the ability to cancel. This article demonstrates all these topics :

  • Create a background thread to do work away from GUI as to not slow down the user experience.
  • Pass data from the GUI thread to the background worker and subsequently to GUI to update appropriate controls.
  • Safely update screen data after work is done.
  • Invoke/Dispatch back to control GUI thread from worker as needed.
  • Associate threaded work with progress bar in WPF to provide status.
  • Allow the users to stop or cancel the process and handle it appropriately.
  • Enable and disable buttons so user is not kicking off superfluous actions while the work process is executing.
  • I write these articles to enlighten the development community as well as notes for myself as I work in the differing technologies going forward. For this article I saw many websites which would individually piece these topics together, but none of them showed the the whole process. This article covers the whole process.

    BackgroundWorker Not Just For Winforms Anymore

    The goal of the operation is to do the work, and that work is not done on the GUI thread where a user will notice the slow down, but on a background thread. To accomplish that, one of the best fixtures of .Net is the Background thread which was introduced for Winforms. Even though the BackgroundWorker is a nice drag and droppable component in the Winform arena it does not mean that it can’t moonlight in our WPF sandbox. We simply have to instantiate and initialize it ourselves. Here is the code to do that in our Window class:

    public partial class Window1 : Window
    {
        BackgroundWorker bcLoad = new BackgroundWorker();
    
        public Window1()
        {
            InitializeComponent();
    
            bcLoad.DoWork += new DoWorkEventHandler(bcLoad_DoWork);
            bcLoad.RunWorkerCompleted += new RunWorkerCompletedEventHandler(bcLoad_RunWorkerCompleted);
    
            bcLoad.WorkerReportsProgress = true;
            bcLoad.ProgressChanged += new ProgressChangedEventHandler(bcLoad_ProgressChanged);
    
            bcLoad.WorkerSupportsCancellation = true;
        }

    Explanation

    • Line 3: We must declare and subsequently instantiate a background worker which will be used. This object and operations can be reused so this only needs to be done once and to keep temporality we declare it on the window class itself.
    • Line 9/10: We are subscribing to the events which will handle our work on the separate thread. The DoWork event is where the heavy lifting of the offloaded operations will occur. The RunWorkerCompleted event is the safe haven where we can pipe the results of DoWork to the GUI controls without having to invoke or dispatch back to the controls because the event code will be done on the GUI’s thread. Note intellisense is our friend one these lines. Type in += and intellisense offers to create the subscribing to the event handler with a Tab. A subsequent Tab key will create the method stub. Give it a try.
    • Line 12/13: Here is where we tell the background worker that we are going to do a progress operation back to the GUI for the user experience. Note if we don’t specify WorkReportsProgress we will get this exception:This BackgroundWorker states that it doesn’t report progress. Modify WorkerReportsProgress to state that it does report progress.
    • Line 15: Here is where we also inform the BackgroundWorker object that we will be handling cancellation.

    Xaml Mammal

    With the goal of providing a cancel and progress status bar as such:

    StatusBar

    Here is the code to add to our Xaml where it lives at the bottom of our screen. Below the code is the status bar and its child elements of a TextBlock, ProgessBar and button for the cancel.

    <StatusBar Name="stBarPrimary" Grid.Row="5" Grid.ColumnSpan="4" Background="AntiqueWhite" Margin="0,9.056,0,0">
    
        <StatusBarItem>
            <TextBlock Name="tbStatus">Status:</TextBlock>
        </StatusBarItem>
    
        <StatusBarItem>
            <ProgressBar Height="12" Width="400" Margin="20,0,5,1" Name="pBar1" Visibility="Hidden" VerticalAlignment="Bottom" />
        </StatusBarItem>
    
        <StatusBarItem>
            <Button Height="24" Width="80" Content="Cancel" Name="btnCancel" Visibility="Hidden" Click="btnCancel_Click" />
        </StatusBarItem>
    
    </StatusBar>

    The only thing to note that initially the Cancel button and progress bar visibility is set to hidden.

    Launching the Operation from a Button Click

    Here is the code where we launch the DoWork event operation, but more importantly we pass in data which the DoWork can use to perform its operations. The data here is special because it all resides on gui controls. We don’t want to access that data directly from our worker thread otherwise we will get this exception as reported in my previous article (C# WPF: Linq Fails in BackgroundWorker DoWork Event ) :

    The calling thread cannot access this object because a different thread owns it.

    private void btnAcquire_Click(object sender, RoutedEventArgs e)
    {
        btnAcquire.IsEnabled = false;
    
        tbStatus.Text = "Status :"; // Reset status if changed.
    
        btnCancel.Visibility =
        pBar1.Visibility = Visibility.Visible;
    
        bcLoad.RunWorkerAsync(new Dictionary<string, string>()
                    {
                        { "AccountID", tbAccount.Text },
                        { "CategoryID", tbCategory.Text },
                        { "SequenceNumber", tbSequenceNumber.Text }
                    });
    }

    The first thing we do is darken the button which launched the process so the user doesn’t click it twice. Then we make the cancel button and the progress bar visible to the user as the process is about to begin. Finally we extract data held in Gui controls exposed to the user. We cannot access that data once the thread is running and must get the data to to the DoWork process.

    Is It Done Yet? Move the Progress Bar.

    Here is our event which handles the moving of the progress bar. This is done on the GUI thread so no need to do checking of the dispatch. We get a numeric percentage which moves the bar along and incremental movements.

    void bcLoad_ProgressChanged(object sender, ProgressChangedEventArgs e)
    {
        pBar1.Value = e.ProgressPercentage;
    }

    Cancelling the Operation from a Button Click

    The cancel is similar because we do the opposite of the initiation code above by hiding the controls and informing the user of the stop action. This cancel is initiated by the cancel button on click event shown in the Xaml above. We do all this on the cancel because a cancel event does not fire the RunWorkerCompleted event.;

    private void btnCancel_Click(object sender, RoutedEventArgs e)
    {
        bcLoad.CancelAsync();
    
        // Turn off from here the progress bar and cancel button and report that.
        tbStatus.Text = "Status : Canceled";
    
        btnCancel.Visibility =
        pBar1.Visibility = Visibility.Hidden;
    
        btnAcquire.IsEnabled = true;
    
    }

    Time to DoWork

    Ok, here is what we have been waiting to do, the actual work which will occur in the background on the separate thread. We add to the code for the DoWork Event.

    void bcLoad_DoWork(object sender, DoWorkEventArgs e)
    {
        try
        {
            List<string> Results = new List<string>();
    
            Dictionary<string, string> UserInputs = e.Argument as Dictionary<string, string>;
    
            if (UserInputs != null)
            {
                bcLoad.ReportProgress(33);
    
                DatabaseContext dbc = new DatabaseContext();
    
                var data = dbc.SystemData
                              .Where(ac => ac.Account_ID == UserInputs["AccountID"])
                              .Where(ac => ac.TimeStamp == 0)
                              .Where(ac => ac.Category_id == UserInputs["CategoryID"])
                              .Where(ac => (int)ac.Category_seq_nbr == int.Parse(UserInputs["SequenceNumber"]))
                              .Select(ac => acc.UnitCode);
    
                Results.Add("Unit Code: " + data.First());
    
                if (bcLoad.CancellationPending)
                {
                    e.Cancel = true;
                    return;
                }
    
                bcLoad.ReportProgress(60);
                Results.Add("Income Processing Types: " + string.Join(" ", Financial.GetIncomeProcessingTypes().ToArray()));
    
                if (bcLoad.CancellationPending)
                {
                    e.Cancel = true;
                    return;
                }
    
                bcLoad.ReportProgress(80);
    
                Results.Add("Stock Movement: " + string.Join(" ", Financial.GetStockMovementTypes().ToArray()));
    
                bcLoad.ReportProgress(100);
    
                e.Result = Results; // Pass the results to the completed events to process them accordingly.
            }
        }
        catch (Exception ex)
        {
            lbxData.Dispatcher.BeginInvoke(new Action(() => lbxData.Items.Add("Exception Caught: " + ex.Message)));
        }
    
    }

    Explanation

    • Line 5: We will return Results to the RunWorkerCompleted event and this line initializes it.
    • Line 7: This method was passed data. Here is where we unbox our present which is a Dictionary which contains our user input we are interested in processing.
    • Line 11: Here is where we pass our percentage. It will move the bar up 33 percent. You can dictate what percentage of the process is done. I have chosen 33 in this case, because the code does three separate work items and it will allow for a smother transitions.
    • Line 16 : Here is where we access the passed in dictionary which holds our user inputs.
    • Line 22: The first work unit will be executed on this line and the database call will be made. After this line we can bump up the progress bar.
    • Line 24: Our first important check to see if the user wants to cancel. If a cancel event has been fired, we simply exit this method. Cancellation means that the follow up function RunWorkerCompleted will not be fired.
    • Line 27: If we are here, bump up the progress bar.
    • Line 28-37: Repeat of the work, check cancel and move progress bar as shown above. Though once done, we bump the result to 100%! We are done with the work.
    • Line 39: Now we place the results on the DoWorkEvents Result property to be used in the RunWorkerCompleted.
    • Line 44: The exception actually reports the error to in this case a List box named lbxData. This is accomplished by using the controls Dispatcher invoke code. That invoke ensures that the action against the control is done safely on the GUI thread. We could have used this in our code instead of putting things onto a result. But I have chosen not to because if the user cancels, we don’t have half loaded data to unload from controls. By passing the result to the RunWorkerCompleted event we ensure that all data is properly populated and no complex back out of data during error situations is needed. But since this is a exceptional and unplanned situation, I have chosen to write to the control directly. You have the tools to do either, its your design. 🙂

    Time to Display the Result to the User

    Finally our work is done and all is complete. The below code safely writes the result to the GUI thread’s controls.

    void bcLoad_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
    {
        if ((e.Result != null) && (e.Cancel == false))
        {
            List<string> results = e.Result as List<string>;
    
            if (results != null)
                foreach (string item in results)
                    lbxData.Items.Add(item);
        }
        else // User has canceled or there is no data.
        {
           lbxData.Items.Clear();
        }
    
        btnAcquire.IsEnabled = true;
    
        btnCancel.Visibility =
        pBar1.Visibility = Visibility.Hidden;
    
    }

    Explanation

    • Line 3: We are expecting results, do a check for good measure.
    • Line 5: Unbox our present from the DoWork event.
    • Line 7: Load our ListBox with our found data!
    • Line 10: Turn on the button which started it all.
    • Line 12-13: Hide the progress bar and Cancel button.

    This is now done and I hope it helped.

    Miscellaneous

    I am including the Xaml which I used which shows the user input and input button for those who may be curious about the code.

    <Window x:Class="CSS_Research.Window1"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Window1" Height="360" Width="582">
        <Grid>
            <Grid.RowDefinitions>
                <RowDefinition Height="34*" />
                <RowDefinition Height="34*" />
                <RowDefinition Height="34*" />
                <RowDefinition Height="34*" />
                <RowDefinition Height="134*" />
                <RowDefinition Height="37*" />
            </Grid.RowDefinitions>
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="170*" />
                <ColumnDefinition Width="216*" />
                <ColumnDefinition Width="16*" />
                <ColumnDefinition Width="155*" />
            </Grid.ColumnDefinitions>
            <Label Name="lbAccount" Content="Account" HorizontalAlignment="Center" VerticalAlignment="Center" />
            <TextBox Name="tbAccount" Grid.Column="1" VerticalContentAlignment="Center" VerticalAlignment="Center" Height="Auto" Margin="0">392702150</TextBox>
            <Label Margin="0" Name="label1" Grid.Row="1" HorizontalAlignment="Center" VerticalAlignment="Center">Category</Label>
            <TextBox Margin="0" Name="tbCategory" VerticalContentAlignment="Center" Grid.Row="1" Grid.Column="1" HorizontalAlignment="Stretch" VerticalAlignment="Center">ret</TextBox>
            <TextBox Grid.ColumnSpan="1" Margin="0" Name="tbSequenceNumber" VerticalContentAlignment="Center" Grid.Column="1" Grid.Row="2" HorizontalAlignment="Stretch" VerticalAlignment="Center" Grid.RowSpan="1">1</TextBox>
            <Label Grid.RowSpan="1" Margin="0" Name="label2" Grid.Row="2" HorizontalAlignment="Center" VerticalAlignment="Center">Category Sequence Number</Label>
            <Button Grid.Column="3" Margin="54.252,6.696,37,6.696" Name="btnAcquire" Click="btnAcquire_Click">Acquire</Button>
    
            <TabControl  Name="tabControl1" Grid.ColumnSpan="4" Grid.Row="4" Margin="12,0.367,0,32.597" Grid.RowSpan="2">
                <TabItem Header="General" Name="tabItem1">
                    <Grid>
                        <ListBox Name="lbxData" Grid.IsSharedSizeScope="True" />
                    </Grid>
                </TabItem>
                <TabItem Header="Data" Name="tbData">
                    <Grid>
    
                    </Grid>
    
                </TabItem>
            </TabControl>
    
            <StatusBar Name="stBarPrimary" Grid.Row="5" Grid.ColumnSpan="4" Background="AntiqueWhite" Margin="0,9.056,0,0">
    
                <StatusBarItem>
                    <TextBlock Name="tbStatus">Status:</TextBlock>
                </StatusBarItem>
    
                <StatusBarItem>
                    <ProgressBar Height="12" Width="400" Margin="20,0,5,1" Name="pBar1" Visibility="Hidden" VerticalAlignment="Bottom" />
                </StatusBarItem>
    
                <StatusBarItem>
                    <Button Height="24" Width="80" Content="Cancel" Name="btnCancel" Visibility="Hidden" Click="btnCancel_Click" />
                </StatusBarItem>
    
            </StatusBar>
    
        </Grid>
    </Window>
    Share

    Tags: , ,

    C# WPF: Linq Fails in BackgroundWorker DoWork Event

    iStock_000010874966XSmall I write this because if I ran into this, someone else will. Now first off it wasn’t Linq that failed, but it looked like it and here is my story of failure I found in a WPF background worker threading code which can happen in other areas as well.

    The perennial advice to all people in the MSDN forums as well as others is never, never, never  write to a GUI control in a thread or the BackgroundWorker’s do work event. All GUI work must be done on a the GUI. I very well knew that…but the reverse (don’t read from a GUI in a different thread)  is also true and that bit me. Let me explain.

    Anecdotal Evidence

    Imagine my surprise when I created a WPF project at a new job and started getting this exception in the DoWork code of my BackgroundWorker when the first use of a Linq query’s delayed execution point was accessed :

    The calling thread cannot access this object because a different thread owns it.

    The code threw an exception, on line 16 below, where I was loading data from after the Linq call.  I began to think, does this have something to do with the Linq DataContext?

    void bcLoad_DoWork(object sender, DoWorkEventArgs e)
    {
        try
        {
            List<string> Results = new List<string>();
    
            DatabaseDataContext dbc = new DatabaseDataContext();
    
            var data = dbc.SystemData
                          .Where(ac => ac.Account_id == tbAccount.Text)
                          .Where(ac => ac.TimeStamp == 0)
                          .Where(ac => ac.Category_id == tbCategory.Text)
                          .Where(ac => (int)ac.Category_seq_nbr == int.Parse(tbSequenceNumber.Text))
                          .Select(ac => ac.Unit_Code);
    
            Results.Add("Unit Code: " + data.First());
    
            e.Result = Results;
        }
        catch (Exception ex)
        {
            lbxData.Dispatcher.BeginInvoke( new Action(() => lbxData.Items.Add( "Exception Caught: " + ex.Message )));
        } 
    }

    No the problem was within the setup of the Lambdas for the Linq query. All the highlighted lines above is where the actual problem originates and not on the final highlighted line.

    The problem was that I was accessing Gui controls data, and not changing; that was the nuance. For in my mind that was ok, it was a passive read action and not a direct writing one. Obviously not.

    Note: If you have come to this blog experiencing this problem but for the writing of items to a control, one method to solve it is to use the Dispatcher off the control on any thread not just BackgroundWorker. That code is shown in my exception catch blog above. That line is perfectly fine to do and is not another issue. The lbxData is a Listbox on the main Xaml and because of the immediacy of the exception, I write

    Resolution

    Since I was already using the plumbing of the DoWorkEventArgs, it seemed a natural choice to pass in the data using that object. I changed the call to pass in a Dictionary of values to extract the data as such:

    bcLoad.RunWorkerAsync(new Dictionary<string, string>() 
                            { 
                                { "AccountID",      tbAccount.Text }, 
                                { "CategoryID",     tbCategory.Text },
                                { "SequenceNumber", tbSequenceNumber.Text }
                            });

    Then to consume the Dictionary as such:

    void bcLoad_DoWork(object sender, DoWorkEventArgs e)
    {
        try
        {
            List<string> Results = new List<string>();
    
            Dictionary<string, string> UserInputs = e.Argument as Dictionary<string, string>;
    
            if (UserInputs != null)
            {
    
            DatabaseContext dbc = new DatabaseContext();
    
            var data = dbc.SystemData
                          .Where(ac => ac.Account_ID == UserInputs["AccountID"])
                          .Where(ac => ac.TimeStamp == 0)
                          .Where(ac => ac.Category_id == UserInputs["CategoryID"])
                          .Where(ac => (int)ac.Category_seq_nbr == int.Parse(UserInputs["SequenceNumber"]))
                          .Select(ac => acc.UnitCode);
    
            Results.Add("Unit Code: " + data.First());
    
            e.Result = Results; // Pass the results to the completed events to process them accordingly.
            }
        }
        catch (Exception ex)
        {
            lbxData.Dispatcher.BeginInvoke( new Action(() => lbxData.Items.Add( "Exception Caught: " + ex.Message )));
        }
    
    }

    I simply convert the object property of Argument to a Dictionary, as highlighted, and go do the work. One doesn’t have to use a Dictionary. One can pass in any object off of the Argument property. Hope This Helps

    Share

    Tags: , , , ,

    C#: Handling Title Case in Strings with Articles and Prepositions

    iStock_000002240961XSmall

    This was an issue I answered in the forums which a user presented and felt that the response was intricate enough to share with the world as a whole. The user wanted to have a string converted to title case but also wanted to have the first letter of any article or preposition to not be be upper case along with the rest of the sentence. This article discusses how to do that in C#.

    For example the user was interested in changing

    “ALL QUIET ON THE WESTERN FRONT”

       to

    “All Quiet on the Western Front.”

    .Net Framework Almost Does It

    Thanks to the TextInfo class and a helping hint from a current CultureInfo object we can use the method ToTitleCase to work with our current language. The problem is that when ToTitleCase is called with the original sentence we get this:

    “All Quiet On The Western Front”

    Give it some Help

    The .Net code is not robust enough to ignore the articles and prepositions so we will augment it. The following code using Linq-to-Object and Regex and processes majority of the target articles and prepositions . I have placed it into an extension method below:

    /*
    using System.Globalization;
    using System.Threading;
    using System.Text.RegularExpressions;
    */
    
    /// <summary>
    /// An Extension Method to allow us t odo "The Title Of It".asTitleCase()
    /// which would return a TitleCased string.
    /// </summary>
    /// <param name="title">Title to work with.</param>
    /// <returns>Output title as TitleCase</returns>
    public static string asTitleCase ( this string title)
    {
        string WorkingTitle = title;
    
        if ( string.IsNullOrEmpty( WorkingTitle ) == false )
        {
            char[] space = new char[] { ' ' };
    
            List<string> artsAndPreps = new List<string>()
                { "a", "an", "and", "any", "at", "from", "into", "of", "on", "or", "some", "the", "to", };
    
            //Get the culture property of the thread.
            CultureInfo cultureInfo = Thread.CurrentThread.CurrentCulture;
            //Create TextInfo object.
            TextInfo textInfo = cultureInfo.TextInfo;
    
            //Convert to title case.
            WorkingTitle = textInfo.ToTitleCase( title.ToLower() );
    
            List<string> tokens = WorkingTitle.Split( space, StringSplitOptions.RemoveEmptyEntries ).ToList();
    
            WorkingTitle = tokens[0];
    
            tokens.RemoveAt(0);
    
            WorkingTitle += tokens.Aggregate<String, String>( String.Empty, ( String prev, String input )
                                    => prev +
                                        ( artsAndPreps.Contains( input.ToLower() ) // If True
                                            ? " " + input.ToLower()              // Return the prep/art lowercase
                                            : " " + input ) );                   // Otherwise return the valid word.
    
            // Handle an "Out Of" but not in the start of the sentance
            WorkingTitle = Regex.Replace( WorkingTitle, @"(?!^Out)(Out\s+Of)", "out of" );
        }
    
        return WorkingTitle;
    
    }
    Explanation
    • Line 21: Here is our English list of words not to capitalize. We would have to change this for other languages.
    • Line 25: We get the current culture from the running thread so that ToTitleCase can do its job.
    • Line 30: ToTitleCase does the first run and upper cases all the first letters and drops any following upper case letters if they exist.
    • Line 32: We split the line on space between the words into word tokens and put them in a list.
    • Line 34: We save off the first word because regardless of what it is, it is correct.
    • Line 36: We remove the first word so not to process it.
    • Line 40: Using the Aggregate extension to accumulate each word token we will add a space. We are using the aggregate method in-lieu of string.Join to add spaces to our words (the accumulation), but also to check each word as it goes by which string.Join can’t help us with.
    • Line 42: As the tokens (words) are handed to us, check to see if they are in the list we setup in line 21. If it exists, add a space in front and make the whole word lower case (Line 43) other wise ad a space and just return the word.
    • Line 46: Handle any two word Out Of issues, but ignore if it is the first word as found in “Out of Africa”.
    Tests and Results

     

    Console.WriteLine( "ALL QUIET ON THE WESTERN FRONT".asTitleCase() );
    Console.WriteLine( "Bonfire OF THE Vanities".asTitleCase() );
    Console.WriteLine( "The Out-of-Sync Child: Recognizing and Coping with Sensory Processing Disorder".asTitleCase() );
    Console.WriteLine( "Out OF AFRICA".asTitleCase() );
    
    /* Results
    All Quiet on the Western Front
    Bonfire of the Vanities
    The Out-Of-Sync Child: Recognizing and Coping With Sensory Processing Disorder
    Out of Africa
    */
    Share

    Tags: , , ,

    C# Tribal Knowledge: Use of the Conditional Attribute for Conditional Compilation For Object and and Argument Validation during Development

    stockxpertcom_id14589271_jpg_013ced4118ce4854e1935aeaa12684ecThis is another one of of my topics which I deem to be Tribal Knowledge type information. For me it seems that such information seems be known by only the privileged few. In this article I present for your reading perusal details on how to handle different state errors found in classes and arguments during debug/development activities. The premise is that such checks for object or argument correctness is only needed for development and not for production level code. By using the Conditional attribute in ones C# code such checks can be utilized for object and state correctness but not be a burden in a production program or web site.

    Development State Errors Checking

    For example, and yes its a basic example,  say one is writing a database layer and the requirement is that the connection string be be properly filled with with a database name a user name and a password. You happen to know that this code will be reused by others on the development staff and they will most likely fail to provide such values the first time they hook up the code. So you don’t have to go to their desks to hand hold and debug the error, wouldn’t it be nice if the object checked its own state of correctness?

    Once working the checks will really become superfluous and will be removed. This scenario speaks to the fact that the user has two options, or two roads to failure, of loading the values. Say it can be done either during construction or after via the exposed properties. Just ripe for someone to forget to do one or the other.

    Code Speaks Conditionally

    For the code we will create a connection object which checks for the validity, to the best of its ability, of those values before their use, and if a problem exists throw an application exception during development time only.

    Here is our code and the highlight lines are related to the state checking:

    using System.Diagnostics;
    
    public class ConnectionManager
    {
        public string DatabaseName { get; set; }
        public string UserName     { get; set; }
        public string Password     { get; set; }
    
        public ConnectionManager() { }
    
        public ConnectionManager( string databaseName, string userName, string password )
        {
            DatabaseName = databaseName; UserName = userName; Password = password;
        }
    
        public string GenerateConnectionString()
        {
            // This is only called during debug builds and *not compiled*
            ValidateState(); // during Release builds.
    
            return string.Format( "{0};User={1};Password={2}", DatabaseName, UserName, Password );
        }
    
        [Conditional( "Debug" )]
        private void ValidateState()
        {
            if ( string.IsNullOrEmpty( DatabaseName ) )
                throw new ApplicationException( "Development Error: DatabaseName Empty" );
    
            if ( string.IsNullOrEmpty( UserName ) )
                throw new ApplicationException( "Development Error: UserName Empty" );
    
            if ( string.IsNullOrEmpty( Password ) )
                throw new ApplicationException( "Development Error: Password Empty" );
    
        }
    
    }

    So if this class is instantiated and the proper variables are not setup an application exception is thrown during debug mode only when a call to generate a connection string occurs. The magic is done by the highlighted lines but the second one with Conditional attribute tells the compiler to only use this in debug builds

    Summary

    Now this example is a bit contrived, but the idea is that if one has unique business state requirements which may need to be met before an object’s operation can be used, this methodology can be used to catch all actions, but not hamper runtime operations. It obviously shouldn’t be used to catch unique runtime scenarios such as user validation, those should be handled directly and possibly not by generating an exception.

    Share

    Tags: , ,

    C# Linq How To Load a Winform Control Using Dynamic Linq entitites (Or any other Control)

    This has been requested in the forums, for most examples in the Linq world are of console applications. One can use Linq to dynamically load winform (or asp.net) controls very easily with the dynamic entities which are created on the fly thanks to Linq. This article shows how to load a gridview control, or any other, with dynamic items of linq.

    Steps

    1. Create a winform project/solution.
    2. Drag two controls to the surface of the form datagridview and bindingsource. We will accept the default names of dataGridView1 and bindingSource1.
    3. For demonstration purposes of this article we will create a struct for the simulated data which the Linq-to-Object operation will query off of:
      struct Data
      {
          public string Name { get; set; }
          public string Operation { get; set; }
          public string Description { get; set; }
          public DateTime DateStart { get; set; }
          public DateTime DateEnd { get; set; }
      
      }

      Note if you don’t create a new file for the above struct, place it below the Form1 partial class. Placing it above will screw up the design view when you try to edit.

    4. Here is the code to load the GridView using Linq which can be called from the constructor of the form after the InitializeCoponent call.
      BindingSource bindingSource1= new BindingSource();
      private void LoadGrid()
      {
          List<Data> dataListing = new List<Data>()
          {
              new Data() { Name = "Jabberwocky", Operation="Read", DateStart= DateTime.Now.AddDays(-2), DateEnd = DateTime.Now.AddDays(-2), Description="Process Started No errors"},
              new Data() { Name = "Space", Operation="Write", DateStart= DateTime.Now.AddDays(-2), DateEnd = DateTime.Now.AddDays(-1), Description="Final process remote allocation of 3000 items to main buffer."},
              new Data() { Name = "Stock Purchase", Operation="DataWarehousing", DateStart= DateTime.Now, DateEnd = DateTime.Now, Description="Shared data transport."}
          };
      
          var items = from dta in dataListing
              select new
              {
                 OperationName = dta.Name,
                 Start         = dta.DateStart.ToShortDateString(),
                 End           = dta.DateEnd.ToShortDateString(),
                 Operation     = dta.Operation,
                 Description   = dta.Description
               };
      
          bindingSource1.DataSource = items;
          dataGridView1.DataSource  = bindingSource1;
      
          // Grid attributes
          dataGridView1.BorderStyle         = BorderStyle.Fixed3D;
          dataGridView1.AutoSizeColumnsMode = DataGridViewAutoSizeColumnsMode.AllCells;
      
      }

    Result

    GridView

    Share

    Tags: , , ,

    C# 101: Extension Method Creation For Variables and Enums

    Class101 With the advent of C# 3.0 in .Net 3.5 one can create extension methods for common tasks for any existing types and enums which one finds in their code. This is a quick how-to article which provides those two examples using an integer and a user defined enum.

    Basic Extension Example

    Sometimes one needs to know when an integer value is negative. Here is an extension method to do that and its usage example.

    public static class MyExtensions
    {
        public static bool IsNegative( this int value )
        {
            return (value < 0) ? true : false;
        }
    }
    1. Step one create a static class.
    2. Create a static method return type can vary to suit the target operations needs.
    3. Use the this keyword in the input parameters of the type which the extension will be used by.

    In the above case we want integers to report if they are negative or not. Here is the usage:

    int value = 1;
    
    Console.WriteLine( value + " is " + value.IsNegative() );
    value = --value;
    
    Console.WriteLine( value + " is " + value.IsNegative() );
    
    value = --value;
    Console.WriteLine( value + " is " + value.IsNegative() );
    
    /* Output
    1 is False
    0 is False
    -1 is True
    */

    Enum Example

    Enums can have extensions in C# as well and are very functional.

    This example is similar to the previous but we will deal with software development states. The first two states are test related and we will create an extension to determine if the state is in test or not.

    public enum States { Test, UserAcceptance, Development, Production, Maintainence };
    
    public static class MyExtensions
    {
        public static bool IsInTest( this States state )
        {
            return state < States.LastTestState;
        }
    
    }

    So every state before Development is considered a “Testing” state. Here is its usage:

    States current = States.Test;
    Console.WriteLine("State: " + current + " is " + current.IsInTest());
    
    current = States.Development;
    Console.WriteLine( "State: " + current + " is " + current.IsInTest() );
    
    /* Output:
    State: Test is True
    State: Development is False
    */

    HTH

    HTH

    Share

    Tags: , , ,

    Linq vs. DataReader; Visual Examples Showing That Linq Does it in Fewer Lines of Code

    Bridges I recently replied to a post in the MSDN C# General forum (one of the best places to get help if you have C# question) where the user was getting data from a DataReader and needed help with null values being returned. What I ended up discovering was differences from old way of getting data from a database in .Net and the new way. Such as the highways above both go to the same location and essentially do the same thing, but the contrast is so much different. Same holds true for .Net Linq and the DataReader.

    In the post I recommend the use of the null-coalescing operator to handle the null returned from the database. Erroneously I forgot that the DataReader returns a DBNull which cannot be handled by the null-coalescing operator. GRRR

    My mistake was based in the fact that I have become used to the Linq Data Context returning a INullable<T> when dealing with null fields in a database. The the null-coalescing operator can handle that to a tee.

    I created my test code and realized that it demonstrated the following

    1. Linq does so much for the developer that what previously took around six plus lines of code boils down to roughly three. It manages so much in the background for the user that it allows for quicker coding to get at data.
    2. The design of Linq handles Nulls differently, or at lease presents them to the end user from the old way processing. Using the null-coalescing operator as shown is a great help.

    Here is the example code, first up is Linq and the target operation is to display values from a nullable field in the database called Description. When enumerating over the data rows, if that field happens to be null it reports it or shows the actual data. Next up is the older way of doing it and notice how the user has to handle reader. Note one could check for DBNull in that situation, so the example may not be what you are looking to do in a real system.

    GTCDataContext gtc = new GTCDataContext();
    
    var items = gtc.Location_US;
    
    foreach ( var it in items )
       Console.WriteLine( it.Description ?? "not Defined" );
    
    string queryString = "SELECT Description FROM dbo.Location_US;";
    
    using ( SqlConnection connection = new SqlConnection( gtc.Connection.ConnectionString  ))
    {
       SqlCommand command = new SqlCommand( queryString, connection );    connection.Open();
    
       SqlDataReader reader = command.ExecuteReader();
    
       // Call Read before accessing data.
       while ( reader.Read() )
       {
          Console.WriteLine( (string.IsNullOrEmpty(reader[0].ToString()) == false) ?  reader[0] : "not defined again" );
       }
    
        // Call Close when done reading.
        reader.Close();
    }

    Here is the result of the run:

    Florida

    not Defined

    Colorado

    California

    not Defined

    not Defined

    not Defined

    not Defined

    —————————————–

    Florida

    not defined again

    Colorado

    California

    not defined again

    not defined again

    not defined again

    not defined again

    Share

    Tags: , , , , ,