Experience is a dear teacher, but fools will learn at no other.

Dell XPS 13 7390

November 8th, 2019 Posted in Personal Finance | Comments

As the holiday season nears, a new laptop for developing skills and personal projects is worth considering. The Dell XPS 13 7390 processor, a Core™ i7-10710U, is really enticing. Windows 10 Pro, an M.2 PCIe NVMe SDD, and non-touch display are motivating as well. As with other big purchases, a decision will require more than a month’s consideration.


  • Processor: 10th Generation Intel® Core™ i7-10710U Processor (12MB Cache, up to 4.7GHz, 6 cores)
  • Operating System: Microsoft Windows 10 Pro
  • Memory: 16GB LPDDR3 2133MHz
  • Hard Drive: 512GB M.2 PCIe NVMe SSD
  • Display: 13.3″ FHD (1920×1080) Non-Touch Display

Cross-Thread Manipulation of Windows Forms Controls

November 5th, 2019 Posted in Windows | Comments

System.InvalidOperationException: Cross-thread operation not valid. Control "textBox1" accessed from a thread other than the thread it was created on.

The above exception was encountered while placing a function call with long execution time on a separate thread and having that thread update a TextBox with status updates. The issue arises, because “access to Windows Forms controls isn’t inherently thread-safe.”1

Documentation by Microsoft discusses the following solutions:

  • calling the Control.Invoke() method
  • using a BackgroundWorker component
  • setting Control.CheckforIllegalCrossThreadCalls property to false (unsafe)

Invoke() Method

This approach checks whether the currently running thread is the same thread that created the control. If the threads are different, then Invoke() is called to allow running a delegate in the control’s owner thread. Otherwise, the currently running thread is the owner of the control, and the control’s properties can be manipulated directly. This method is demonstrated by the following code snippet:

if (textBox1.InvokeRequired)
      new MethodInvoker(
         () => {textBox1.Text = "abc";} ) );
    textBox1.Text = "abc";

Using BackgroundWorker

BackgroundWorker raises three events: DoWork, ProgressChanged, and RunWorkerCompleted.

A DoWork event handler is where long duration functions are called away from the main thread. It runs in a thread separate from the thread that created the BackgroundWorker instance. Modifying a control’s properties from a DoWork event handler will throw System.InvalidOperationException().

The main thread usually creates user interface controls. It also maintains UI responsiveness typically by creating worker threads for lengthy functions. Because BackgroundWorker is likely created from the thread that creates user interface controls, and ProgressChanged and RunWorkerCompleted event handlers execute in the thread that creates BackgroundWorker, it is safe to modify UI controls from ProgressChanged and RunWorkerCompleted event handlers.

With the BackgroundWorker’s WorkerReportsProgress property set to true, event handlers for the BackgroundWorker’s DoWork event can call ReportProgress() to indirectly modify UI controls. ReportProgress() raises the ProgressChanged event, which causes calling of event handlers in the thread that created the BackgroundWorker.

The ReportProgress() method is overloaded. One version of ReportProgress() accepts an integer, which is typically used to represent a percentage of completion. The second version of ReportProgress() accepts an object as well as a percentage of completion. The version of ReportProgress() that accepts an object can be used by the DoWork event handler to send detailed data useful for updating UI controls.

A ProgressChanged event handler added to the BackgroundWorker by the main thread, can inspect the UserState property of the ProgressChangedEventArgs. This property is set to the object provided in the ReportProgress(int, object) call. To set textBox1.Text in the ongoing example, the DoWork event handler can call ReportProgress(0, “abc”) and the ProgressChanged event handler can cast the UserState property to a string and assign it to textBox1.Text:

private void backgroundWorker_ProgressChanged(
   object sender, ProgressChangedEventArgs e)
   string s = e.UserState as string;
   textBox1.Text = s;

Setting Control.CheckForIllegalCrossThreadCalls to false

Let’s not.

Using BackgroundWorker or the Invoke() method can be applied for different situations. The Invoke() method may be used by a worker thread to show a Modal dialog or MessageBox that prevents the main application form from receiving input while the dialog or MessageBox are displayed. BackgroundWorker allows lengthy methods to run in worker threads while providing feedback to the main thread. Both methods are acceptable mechanisms for cross-thread manipulation of Windows Forms.

Getting an A+ on SSL Labs Report

October 31st, 2019 Posted in IT Administration | Comments received an A+ overall rating from Qualys SSL Labs.

utmpdump: Dump UTMP and WTMP Files in Raw Format

October 29th, 2019 Posted in Linux / Unix | Comments

Login attempts can be tracked in real time with the following command:

/bin/utmpdump -f /var/log/btmp

I received a Logwatch email reporting a “corruption detected in /var/log/btmp : XX time(s)” issue. By performing an Internet search for the reported issue, I found Gabriel Cánepa’s How to Monitor User Login History on CentOS with utmpdump. Cánepa describes utmpdump in depth and the fields in each utmpdump line entry.

The eight fields emitted by utmpdump are:

  1. session identifier
  2. PID
  3. “~~” (runlevel change) | “bw” (bootwait process) | TTY | PTY
  4. empty | username | reboot | runlevel
  5. TTY | PTY
  6. remote hostname | kernel version
  7. remote IP address
  8. timestamp

Making Your Grass the Greenest

October 6th, 2019 Posted in Personal Development | Comments

Sometime around November 2005, I stumbled upon Scott Berkun’s Essay #41 – Why I Left Microsoft. At the time, I felt inspired by his courage of leaving an environment where he acquired tenure as a program manager for the Internet Explorer web browser project. In his essay, Scott Berkun writes:

So I chose to leave Microsoft less for reasons of escaping a particular place or group of people, but more to seek out a new set of circumstances to live in. Just like I sought out Microsoft to escape my fears of the post-college emptiness, I looked to leave Microsoft to create not a void, but a new space to grow in: one of my own choosing. I ran to Microsoft to escape my fears of failure. I left Microsoft to define my own idea of success.

Like Berkun, there have been times where I was concerned about becoming a “sad, confused bird of prey, circling the same territory over and over again, never understanding why there was nothing new to find.” I am fortunate enough to consistently find or receive opportunities to overcome new and interesting challenges at my current company. Some projects have been tedious and required little innovation beyond skills gained for certifications. Although such projects did not enhance my technical capability, they developed my patience and persistence. I am now working on a project that requires new programming languages, techniques, and paradigms. I am glad to not be circling the same territory. I am finding excitement in helping my current company expand. Maybe the grass is currently arguably greener at other companies, but I feel there is an opportunity for and the possibility of experiencing the achievement of the greenest grass at my current company. Unless a company is disinterested in growth, with sufficient drive and personal motivation this opportunity can be made available at any company.