This is common to explain. It is the business manager who ends up using the model and he has to interpret the outcome from the model. And since a business manager tend to be not very technical, he doesn’t want to get into the trouble of interpret something that he doesn’t fully understand. But this is not a problem from a model developer’s point of view. A developer is technically savvy enough to have the ball to use the complicate information and gets the max satisfaction of developing something powerful.

I believe the conflict is universal because the two sides have quite different standing ground. But a company appealing good developers is the company that has good managers who know technical stuff and have a tolerant bar higher than average ordinal companies. I believe in companies like Apple, Google and Microsoft, there are many managers who embrace fancy, complicate ideas and encourage developers to go to certain point of complication. On contrast, in some old companies with not much innovative atmosphere, managers can be very conservative.

If you are a good developer, always chasing fancy ideas, would like to indulge into complicate stuff and you find business managers are not very supportive, consider changing a place.

Until next time, happy modelling.

Normally, INotifyPropertyChanged interface is used when you want to update the UI as soon as the underlying data has been changed (in this context, mostly in a programmatic way). You will have your data object inherits from this interface, add an event and a method called PropertyChanged(). In your method, you will call any handler to the event if there is any. You will call your PropertyChanged() method at the end of every property setter attribute accessor or something that changes your data. Say more about it, the UI will subscribe the event when you bind the data to the UI. All simple and is good to use.

INotifyPropertyChanged doesn’t work in aschronized style. That is, if your PropertyChanged() method is called in a thread other than the thread creating the UI, you will get random errors. The ultermate evil is that UI updates should be performed in the same thread as it is created. When your PropertyChanged() method is called in a sub-thread, that sub-thread will call the event of INotifyPropertyChanged interface. As I said, that event will be subscribed by some UI control to update itself. So actually you try to update a UI in a different thread and that gives you the headaches.

A common scenario for this problem is the log system. You have a log system, which provides some kind of UI to show the tasks. When a task starts to execute, you want to update the UI about the change of the task status. When the task is running, you want to update the progress of the task. When the task is done, you want to show the end timestamp of the task. All these jobs involve updating the UI. If you bind the tasks to the UI using databinding, you will tend to use INotifyPropertyChanged to update the UI when the task data is changed. Since all tasks will be run in a BackgroundWorker, it is very likely that the BackgroundWorker will change the data of the tasks. So eventually, you will end up using the BackgroundWorker’s thread to call the PropertyChange() method in your task object, and the event of INotifyPropertyChanged interface as well. This is a common scenario to have the problem happening. It is my own experience by the way.

To fix this problem, you will need to make sure that your PropertyChanged() method uses InvokeRequired() and BeginInvoke() methods to make sure the calling of the event subscribers happens in the same thread as the UI. There are many ways to do this. For example, you can pass the reference of the UI control to your task object so when it is the time, it can check thread and execute the UI update in the correct one. Because most of the time, it is the main thread that owns all UI controls, we can even create a non-visible static singleton control object in a static method which will be sure to get called in the main thread. And everytime we create a new task item, we pass that non-visible control to the task item. As long as all the controls are in the same thread, using which one to call InvokeRequired() and BeginInvoke() doesn’t really matter.

Until next time, happy coding!

To get the advantage from RadioCheck setting in menus, go back to MainMenu control. This control is similar to MenuStrip but its MainMenuItem controls have RadioCheck property. Notice that MainMenu control is not shown in the default tool list. You may need to manually add it to the tool list.

Until next time, happy coding.

SelectedText will be useful when you want to implement your own style of suggestion list of the ComboBox. You will need to combine the usage of this property with the KeyPress event of the ComboBox.

Until next time, happy coding!

void DisplayNewText(string text) { tb.Text = text; }

You may want to update your TextBox in a thread rather than the main thread. Usually, your TextBox control is created in the main thread, if so, you cannot call the above method in your sub-thread. In order to do so, you need to rewrite your above method to:

void DisplayNewText(string text) {
if(tb.InvokeRequired) BeginInvoke(new TextBoxDelegate(DisplayNewText), new object[] { text });
else tb.Text = text;
}


You need a delegate here:

delegate void TextBoxDelegate(string text);

The new DisplayNewText method first tests whether the call is made from the thread that the TextBox belongs to, if so, directly execute the else part. If not, it wraps itself into a delegate and pass the call of the delegate to the main thread, where the else part is executed then.

There is a point that I would like to make: the BeginInvoke method is execuated asynchronized. This actually means that it is not guranteed that the else part is executed immediately after the BeginInvoke call. This, actually may cause problem.

In a real product code, we put logs into a TextBox. New logs are put to TextBox in a sub-thread. To put the logs in better format, we use indentions to separate log sections. An example log section is as below:

[Optimization Begins]

Initial value: 0.345

Satisfied constraints: 3 of 3

Objective: 0.5

[Optimization Ends]

Our log system is consisted by many sections and sections can contain sections. To implement the indention, we use a stack to hold sections. Whenever a new section starts, we push it to the stack and whenever a section finishes, we pop it from the stack. When a log is added to the log system, we investigate the total numbers of sections held in the stack, to decide how many “\t” to put in front of each line of log:


for(int i = 1; i < Logging.NumSections; i++) tb.AppendText("\t");
tb.AppendText(logMessage);


Then we found that some lines have wrong indention:

[Optimization Begines]

Initial value: 0.345

Satisfied constraints: 3 of 3

Objective: 0.5

[Optimization Ends]

In this example, clearly, Objective line’s indention is wrong. After investigation, we found that it is the BeginInvoke that causes this problem. Since BeginInvoke is asynchronized, it happens that after the BeingInvoke is called to display the Objective line, the thread hangs there and the main thread executes the exit of the section. Then when the else part is called from the BeginInvoke, the Logging.NumSections is short by one.

Now the story is, we should pass in whatever values we need at the time when BeginInvoke is called, rather than depends on some outside holder (here is the Logging class) to retrieve the value (here is the NumSections). If we use Logging.NumSections to get the number of sections held in stack, it is the number of sections held in stack when the else part is executed, rather than when the BeginInvoke is called. Timing is essential what’s going wrong in our story.

Of course, there are cases when the else part is executed, you want to use the value held NOW, rather than the value held when the BeginInvoke is called, in this case, retrieve the value from the outside holder makes sense.

Until next time, happy coding!

There are several ways to make project or task (time) estimation. The estimation can be made by managers, developers themselves, managers + developers or system analysts. If estimation is made by managers, developers work in lowest efficiency. Managers + developers make things better. Amazingly, if estimation is made by developers themselves, they tend to work better. Note that Baidu (the biggest search engine company in China) uses this way to estimate project schedules. But this is not the best way. Developers work even better when estimation is made by system analysts. The book says that because system analysts are the best people that can make best estimation and developers work better under better estimation. I just partly understand this.

But wait a second, what if no schedule is to be made? Developers work best if no schedule is made or need! Just wake me up when you done. Why? I guess, it is a matter of human pride. Let me summarize this up. If you are told be a manager to finish something in 2 days, and you think the manager doesn’t know better than you about the work, you wouldn’t work very hard to meet her schedule. If you and the manager agree that the work should be done in 2 days, you are involved and it is now part of your responsibility to meet the schedule. But the manager still interferes.  Now the manager asks you and you tell her that you will finish it in 2 days. What now? You need to work very hard to meet your own schedule. Otherwise, everyone else will think you are not very capable of doing your work and you lose credibility. When the system analyst says that you can finish the work in 2 days, she probably knows it well and you feel happy to meet her correct schedule. In above situations, you always have a schedule to meet. You don’t have to finish the work in 1 day if the schedule says you can/should finish it in 2 days. What if there is no schedule at all? The earlier you can finish the work, the better you impress everyone else and the better you feel in the company, and the greater the achievement is, and the harder you will work.

Developers are simply persons working with computers and programs everyday. The only thing they want best is the achievement, the agreement from everyone else about his ability. They will fight very hard to gain the honor. All they want is: to prove they can work quickly; to prove their code works beautifully; to see their code is used by others; to know everyone knows the above truth. If you can let them get all these, they will work harder than you can image.

You can explicitly change the numeric value of enum items. If you set a number to an enum item, the following items’ numeric values are increased by 1 sequentially. Make sure you set the numeric values in a valid way. For example, if you set enum WeekDays { Monday = 1, Tuesday = 0, Wednesday, Thursday, Friday, Saturday, Sunday}; Then WeekDays.Monday will be conflicted to WeekDays.Wednesday and you will have trouble separating the two conflicted values.

Until next time, happy coding.

When a drop down menu list contains menu items and separators, and all menu items in a group are hidden because of certain reason, you will see two separators next to each other vertically in the menu drop down list, with nothing in between them. This is a UI defect that is easy to be overlooked.

A solution is to provide a function for removing menu items, for example, the following function.

   1:  private static void RemoveMenuItem_(ToolStripMenuItem item, ToolStripMenuItem parent)

   2:  {

   3:      int indexOfRemoving = parent.DropDownItems.IndexOf(item);

   4:  

   5:      if(indexOfRemoving + 1 < parent.DropDownItems.Count) {

   6:          var separatorBelow = parent.DropDownItems[indexOfRemoving + 1] as ToolStripSeparator;

   7:  

   8:          if (separatorBelow != null)

   9:          {

  10:              int indexOfAboveRemoving = indexOfRemoving - 1;

  11:              if (indexOfAboveRemoving < 0 || parent.DropDownItems[indexOfAboveRemoving] is ToolStripSeparator)

  12:              {

  13:                  separatorBelow.Visible = false;

  14:                  parent.DropDownItems.Remove(separatorBelow);

  15:              }

  16:          }

  17:      }

  18:  

  19:      item.Enabled = false;

  20:      item.Visible = false;

  21:  

  22:      parent.DropDownItems.Remove(item);

  23:  }

The above code takes care of hiding and removing menu items and separators if necessary.

Until next time, happy coding.