Tag Archives: Bug

C# / .NET MessageBox is hidden behind the Form

Imagine calling the following C# code:MessageBox.Show(this, "Some text...", "Title", MessageBoxButtons.OKCancel);

After executing this line, the Message Box is not visible, it seems like hidden behind your form, without input focus, mouse clicks cause default beeps, and it suddenly appears if you click Alt or F10 key.

It turns out I had a custom drawing routine for one of the form’s controls (OwnerDraw / OnPaint), and I was changing the property that was causing the redraw cycle. Make sure, that in your OnPaint / DrawItem / DrawSubitem / etc. you are not invalidating your Control.

Also, if you are using .NET ListView control, it has a bug.

Because of a bug in the underlying Win32 control, the DrawItem event occurs without accompanying DrawSubItem events once per row in the details view when the mouse pointer moves over the row, causing anything painted in a DrawSubItem event handler to be overpainted by a custom background drawn in a DrawItem event handler. See the example in the OwnerDraw reference topic for a workaround that invalidates each row when the extra event occurs. An alternative workaround is to put all your custom drawing code in a DrawSubItem event handler and paint the background for the entire item (including subitems) only when the DrawListViewSubItemEventArgs.ColumnIndex value is 0.

http://msdn.microsoft.com/en-us/library/system.windows.forms.listview.drawitem%28v=vs.80%29.aspx

This is not limited to MessageBox using C# / .NET framework. This also happens very often, with Win32 & WinAPI, with a Form class, etc.:

Disappearing folder – bug in Windows 7

In process of testing one of our automation software I hit interesting Windows 7 bug. First I found it in our software, and right away tested this scenario on Windows 7, and bug was there.

The bug. Create folder on the Desktop.

Right click on Desktop
New folder

New folder appears and cursor blinks allowing to change the name for the folder.

Cursor at the end

Place cursor at the end of folder name, and enter dot (.) character.

Dot at the end

After pressing Enter key the folder disappears.

Folder disappears

But do not worry, it will come back after reboot, or after refresh (F5 key).

After refresh

Appears that this bug/behavior… that only Windows 7 is affected. Other Windows versions I tested does not have this bug, even Windows XP and upcoming Windows 8 behaves correctly (see screenshots at the end of the post).

A side note. By “correctly” in this case I mean, that folder does not disappear, however perhaps, there is another bug. The dot “.” character disappears in all Windows versions. This of course depends on interpretation, for example, I also tested this on Ubuntu 10, and Ubuntu (and probably most nixes) allows dot (.) at the end of filename.

Why this happens? Every filename consists of two parts: filename and extension. These two parts are separated by dot (.) character. Windows Shell hides this dot from you, and when you enter “filename.”, it thinks, that this must be a filename without extension, so it stores only filename. In theory you should be able to trick shell by adding more dots, like “filename…”, but Windows 7 Shell reduces them to no dot. Of course you can create file or folder with one or more dots at the end, but for this you will need a normal file manager, like Far Manager (which is open source). Also, keep in mind, that you will not be able to delete this file or folder from desktop using Windows Shell, you will need to switch to file manager again.

Note 1. Windows Server 2008 R2 is based on the same codebase, so it has the same bug.
Note 2. Operating Systems used in the test:

  • Windows 7 Professional 64-bit
  • Windows Vista Enterprise
  • Windows Server 2008 Enterprise
  • Windows Server 2008 R2 Datacenter
  • Windows Server 2003 Enterprise
  • Windows 8 Consumer preview
  • Windows XP
  • Ubuntu 10

On production machine: AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts.

I was helping my colleagues to debug one weird bug on ASP.NET 4.0 website. Everything worked well on developer’s machine, but after publishing to IIS 7.5 Windows 2008 R2 Webserver, we always got site partially working. Everything worked, except AJAX Control Toolkit controls.

There were no any signs of errors. Ajax controls just were not functioning. Digging deeper, we found, that JavaScript is throwing exceptions:
SCRIPT5022: AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the ToolkitScriptManager in AjaxControlToolkit.dll.

This is the most common error with AJAX Control Toolkit — you need to use ToolkitScriptManager instead of ScriptManager. Read more here.

But in our case we was already using ToolkitScriptManager in the all places in our source code.

Digging deeper we found that there is a bug in Script Manager, that is trying to load all DLLs in the project’s bin folder. Script Manager is trying to load DLL files even if they are not used in the project. [I know, that it is not best practice, to keep files not used by project on the production server, but that’s another story.]

The solution was plain and simple: remove all unused DLLs from production machine’s bin folder.

More info about bug and the same problem in different product: