Blog by Joel Fjordén a.k.a. Will o Wisp

New Version on its Way!

Friday, September 26, 2008, 01:20 PM - Code Style Enforcer

It's been way to long since I released a new version of Code Style Enforcer, but now I've finally took the time to get back into the code.

A new version can be expected really soon, it will mainly contain some fixes for reported bugs, e.g. invalid violations reported for implicit and explicit cast operators, and similar things.

I'm also going to have a look at the UAC issue and change where settings and rules are stored, since now it happens below the Program Files folder, which is no good.

Stay tuned!

8 comments ( 120 views ) | related link

There is no Virus!

Tuesday, September 23, 2008, 04:57 PM - Code Style Enforcer

Today when I got back home from work I saw that Avast updated its virus definitions, so now it doesn't report a virus/worm anymore.

I must say that Avast took this false positive very seriously, since they fixed it within 24 hours.

Happy Enforcing!

3 comments ( 53 views ) | related link

Virus? False Positive Detected in Setup.exe

Monday, September 22, 2008, 06:39 PM - Code Style Enforcer

A couple of users have reported that Avast reports a virus/worm in the Code Style Enforcer zip file, or in the setup.exe to be more precise.

This seems to be a false positive, based on the following reasons.

I've scanned my computer without any viruses being found, but as soon as I build the installation in Visual Studio, Avast reports a worm in the setup.exe.

I've uploaded the setup.exe to Virus Total, see report, where 2 out of 35 virus scanners reports a possible worm.

I've now sent the setup.exe file to the Avast team, in order for them to verify that it indeed is a false positive, so that they can update their virus definitions for the future.

2 comments ( 64 views ) | related link

Code Style Enforcer 2.2 Released

Wednesday, March 26, 2008, 07:15 PM - Code Style Enforcer

Besides support for Visual Studio 2008, heavy optimizations have been made to the code rule violations engine. DXCore 3.0.5+ is now required for Code Style Enforcer, since DXCore 2.5+ didn’t work well with code analysis in background threads.

So What's New?

New Features

• Support for Visual Studio 2008.

• Optimizations of the code rule validation engine, which now utilizes background threads and incremental parsing.

Bug Fixes

• Rules were not always loaded when opening a solution in Visual Studio 2008.

• Context menus in code editor and on solution item didn't show.

• Name refactoring didn't work in Visual Studio 2008.

• bool.TryParse(stringValue, out boolValue) no longer reports a name violation (fix in DXCore 3.0).

• Steps taken to assure that the MSI setup works with UAC in Vista, according to this blog post

Known Issues

• Code Style Enforcer doesn't work well when UAC is turned on in Windows Vista, but for how long can you stand it anyway :).

Please send me feedback and comments about this new version, especially about the optimizations to the code rule violations engine, since it might have introduced a bug or two.

29 comments ( 399 views ) | related link

No Keyboard Input in Modeless WPF Window

Tuesday, March 11, 2008, 06:24 PM - WPF

Today I encountered the weirdest problem, when showing a WPF Window from a Windows Forms application. When writing letters and numbers into a textbox nothing happened, but space and backspace together with shortcuts for Cut, Copy and Paste worked as expected.

I first thought there must be some problem with my data template, but when showing it from a WPF application everything worked just fine. My next instant thought was that there must be some message filter, in the Windows Forms application, stealing the keyboard input.

I then created a new Windows Forms application and brought up the modeless WPF Window from there, by calling Show, only to notice the same problem. I then changed to a modal window, by calling ShowDialog instead, and suddenly everything responded as it should.

It was time to start some Google:ing…

The solution, to my big surprise, was to explicitly enable keyboard input from Windows Forms, by calling the static method ElementHost.EnableModelessKeyboardInterop. This call takes a Window as parameter and essentially registers an input hook with the Windows Forms application object, running the message loop, and calls ComponentDispatcher.RaiseThreadMessage. The call to EnableModelessKeyboardInterop can be made in the constructor, if the Window is inherited, or simply before calling the Show method.

For more information read about Sharing Message Loops Between Win32 and WPF.

4 comments ( 109 views ) | related link

Back Next