Since first version of VHD Attach there were requests for auto-mounting of drives upon startup. This beta finally gets that load of my shoulders. :)
Other change that some will like is possibility to enable/disable context menu items for explorer. Now you can choose whether you want all items there, some of them or none.
You can download beta immediately and final release will follow in a month or so.
If everything went as planned. You should read this blog on new address - blog.jmedved.com. Please do update links for RSS feeds.
If you are working with Unix a lot, you get to be aware of weird time-stamps. That markup is usually called Unix time (although POSIX time is more precise term) and it represents number of seconds from January 1st 1970 (in UTC).
I was handling some timing issues in log and I needed to convert between local and Unix time. Since I got quite annoyed during day, at night I created small utility to handle this simple task.
Both application and full code is available.
I needed up/down buttons for one program of mine and I decided to have them on ToolStrip control.
As soon as I figured how to make it vertical, I stumbled upon shade issues. In default RenderMode (ManagerRenderMode) background is just little bit of different background color. Usually this does not matter since ToolStrip is docked on form but in this situation it was quite visible. Solution was simple - switch RenderMode to System and control blends in perfectly.
However, using System render mode has one downfall. There is small light 3D line on bottom of control. Although it is not visible too much, it was enough to bother me.
Since System rendering is done via ToolStripSystemRenderer class, first idea was to extend it. And there it was - OnRenderToolStripBorder. It is enough to override this method and border is never created:
class ToolStripBorderlessSystemRenderer : ToolStripSystemRenderer {
protected override void OnRenderToolStripBorder(ToolStripRenderEventArgs e) {
//base.OnRenderToolStripBorder(e);
}
}
[/sourcecode]
Only thing left is to actually telling ToolStrip to use our class for rendering:
```csharp
SettingsForm() {
InitializeComponent();
toolstripVhdOrder.Renderer = new ToolStripBorderlessSystemRenderer();
}In one of my programs I fixed a bug. I just forgot to restore TopMost state of form. Fix was very simple, just set this.TopMost = true in form’s constructor and everything is solved.
Like every simple fix, this one failed miserably. As soon as I “fixed it” I could not even start program. Even worse thing is that it failed where there was no error before. It didn’t take much to deduce that this change was somehow responsible for triggering error in completely different part of code. It looked like just fact that I have TopMost turned on changes how rest of program is loaded.
I tested program without setting TopMost and order of triggering form’s events was quite expected - first constructor, then Form_Load, then Form_Activated and Form_Shown. However, things do change when you set TopMost property.
It is a subtle change - contructor is still first one to complete, next one is Form_Activated, then Form_Load and Form_Shown is last once more.
If you have code in both Form_Load and Form_Activated you have a minefield in your code. Everything works as expected until you step on mine. In my case mine was TopMost property, but it is not only one that behaves like this.
Solution was dead simple - just move TopMost from constructor to Form_Load and everything works perfectly.
Sample for your testing can be found here.