The odd situation is, that I tend to clean my keyboard while having the computer on — while voice chatting or waiting for a new game to install, I subconsciously clean the keyboard, but also tend to write an essay of jargon at the same time from accidental key presses.

This application, “Keyboard and Mouse Disabler” has only one known purpose so far, and that is to make cleaning your keyboard and mouse peripherals easy. With a few clicks, your mouse and keyboard will be temporarily disabled, preventing accidental key presses and mouse clicks — then it’s cleaning time

There is no install required, it runs straight from the download. While this may seem to be a rather trivial application to release, I thought why not. If someone finds a use for it — great

Download Keyboard and Mouse Disabler!

Contents

1. Log Events
2. Writing Events to the Log
3. Writing Errors to the Log
4. So where does the log file end up?
5. Level specific Logging
6. In Conclusion

As I have learnt over the years, at a certain stage of application development logging becomes critical. It is imperative during testing (especially with multiple, external testers) that they can report any problems or issues in the most efficient manner; this usually entails sending  a log file which the developer can use to locate and debug the bug.

VB.NET comes with its own ‘logging’ sub-system integrated into the language. It allows the developer to place entries into the log file at specified points in the code. These entry points are usually placed at strategic points, such as in the catch statement of a Try… Catch or at the end of a long process to indicate completion.

The logging sub-system of VB.NET resides under the My.Application.Log namespace. Under this namespace are several functions and concepts, that I will detail below, which will let you start logging in your own applications.

Several functions under this namespace allow you to write events to the log file. An ‘entry’ essentially, is composed of a string Message, a Severity Level and an Event ID.

The Message is a string that the developer specifies to appear in the log file. It should generally detail a stage in the code (e.g. “Starting update…”).

The Severity Level is used to determine how ‘critical’ the entry or exception is. This level is only used to help filter out critical events from the less critical ones. For example, an event of a failed update, “Update failed” should be classes at a error level, while an event such as “Starting update” should only be classed as an information level.

Other levels, such as a ‘critical’, are usually reserved for an error that causes the application to cease functioning.

The Event ID attribute is a way help index and identify the errors that may occur for correlation purposes. It is optional attribute when writing an event. It is usually reserved for error events as opposed to verbose events.

You can write events to the log by calling a function under the My.Application.Log namespace. The following code write an example event to the log;

My.Application.Log.WriteEntry("Starting to process function XYZ", TraceEventType.Verbose)

As noted above, the Event ID attribute is optional; it may be considered in-effective to index verbose level messages; reserving the event ID’s for error and critical level events.

When writing Errors to the log a slightly different and specialized function may be used. The WriteError function will write details of an ‘exception’ caught during a Try… Catch statement. It is invoked similar to the code example below;

Try
    Throw New Exception("A sample error exception")
Catch ex As Exception
     My.Application.Log.WriteException(ex, TraceEventType.Error, "Additional information or details")
End Try

Once the error exception is raised within the Try block, the WriteException event will write the exception details (ex) to the log. The same severity level option can be applied, as well as some additional notes to make debugging easier.

When the application closes, and the log file has been flushed to disk the file can be retrieved for analysis. By default it is placed in the user’s Roaming profile under a subdirectory relevant to your application name. To save some time, you can find out the direct path, and for example, show it in a message box, while running the program by executing the following line of code;

MsgBox(My.Application.Log.DefaultFileLogWriter.FullLogFileName)

As with any logging sub-system, some performance overhead (while extremely minimal) may be invoked. To help reduce this, it is possible to only log events that may be considered more relevant than others.

As discussed above the Severity Level can help rank events on a scale of severity, from Verbose to Critical. Similarly we can choose to only log events that we deem important on a release application, for example only events higher than the Informational level. We can choose programmatically as to which events should be included and which should not. The code below sets this level to log events only Information and above.

My.Application.Log.TraceSource.Switch.Level = SourceLevels.Information

The hierarchy of severity levels can be determined using the table below (source).

SourceLevels Value	Message severity required for output
Critical	Critical
Error	Critical or Error
Warning	Critical, Error, or Warning
Information	Critical, Error, Warning, or Information
Verbose	Critical, Error, Warning, Information, or Verbose
ActivityTracing	Start, Stop, Suspend, Resume, or Transfer
All	All messages are allowed.
Off	All messages are blocked.

In Conclusion

Logging becomes essential in larger, more complex programs with several testers. Hopefully the outline of the logging system above will make it simple to implement basic logging capabilities into your own application.

For example, programs with a timer iterative functions with a small interval, programs intercepting Window (WndProc) messages, or even programs with multiple hooks to the keyboard or mouse. All these type of programs have something in common…. it’s a major pain in the backside to ‘step-through’ (by default F10 in Visual Studio) without it jumping to areas non-related to the area of interest.

It’s not until recently that I discovered the DebuggerStepThrough attribute as a question answer on Stack Overflow.

Essentially, the DebuggerStepThrough attribute belongs to the Systems.Diagnostics namespace, and can be placed before almost any block of code to indicate to the debugger that it should pass/skip the block in question.

Decleration of DebuggerStepThrough in C#;

[DebuggerStepThrough()]
private void AnExampleSub()
{
    // Annoying iterative code
}

Decleration of DebuggerStepThrough in VB.NET;

[DebuggerStepThrough()] _
Private Sub AnExampleSub()
      ' Annoying iterative code
End Sub()

During debugging step through, the debugger will not visit anywhere within the subs in the examples above.

Collection sourced from here. Thanks for the laughs

The theroy behind this code is that when a user right clicks on the program item, a ‘message’ is sent by the Windows UI to your program. Normally your program handles this message itself however we can ‘override’ this, and place our own actions there instead.

Private Const WMessageRightClickTaskbar As Integer = &H313
 
Protected Overloads Overrides Sub WndProc(ByRef m As Message)
 
        ' Check if the intercepted 'message' is a 'right click on taskbar'
        If m.Msg = WMessageRightClickTaskbar Then
 
            ' It is possible to change the action that occurs.
            ' In this case, a context menu is shown at the cursor position
            ContextMenuStrip1.Show(Cursor.Position)
 
            ' If you change the above event to something other
            ' than a context menu, remove the 'Exit Sub' below
            ' to restore the context menu and make it appear also.
            Exit Sub
 
        End If
 
        ' If it isnt, then handle it normally
        MyBase.WndProc(m)
 
End Sub

private const int WMessageRightClickTaskbar = 0x313;
 
protected override void WndProc(ref Message m)
{
 
    // Check if the intercepted 'message' is a 'right click on taskbar'
    if (m.Msg == WMessageRightClickTaskbar) {
 
        // It is possible to change the action that occurs.
        // In this case, a context menu is shown at the cursor position
        ContextMenuStrip1.Show(Cursor.Position);
 
        // If you change the above event to something other
        // than a context menu, remove the 'return' below
        // to restore the context menu and make it appear also.
        return;
 
       }
 
// If it isnt, then handle it normally
base.WndProc(m);
 
}

From http://xkcd.com/327/

Download Visual Studio 2008 SP1

If you have installed the Service Pack beta you will need to install the following Service Pack Preparation tool before installing SP1. Note: With the preparation tool you may be required to insert your original Visual Studio 2008 installation disk.

The only issue I had was while performing the preparation tool where an MSI file ‘rdbg_std.msi’ was ‘missing’. I found out that it was ‘Remote Debugger’ related, then looked for the relevant file on the Visual Studio installation disk. It was under <cd>\Remote Debugger\x86 (or x64)\rdbgsetup.exe. I had WinRAR installed so I right clicked, and extracted the file which resulted in the creation of a ‘rdbg_std.msi’. I pointed the installation to that file and all was good.

Should you have any other issues installing the Service Pack, take a look at the read me. It contains some troubleshooting material and installation details.

I am currently trying to develop an interface that will allow for this in VB.net however it is quite difficult having to use a closed-source Microsoft Virtual PC 2007 in order to obtain this ‘kiosk’ functionality.

Progress:

I have made the GUI which detects the insertion of a usb and performs the finding of all virtual machines on the usb device. However I have hit a roadblock with the VPC configuration files which may take some time and effort to overcome.

This application concept is Copyrighted 2007 Shadow Productions