If you haven’t checked it out already, DirectShowLib.net is pretty much THE way to get at direct show functionallity in VB.net (that is unless you want to spend $$$). Thing is, it’s only a paper thin wrapper over the DirectShow COM api stuff, so there ain’t no hand holding here.

I’d mucked with it for a while and with the help of some of the sample code, got video playing in a form in VB.net fairly easily, but, I needed to flip and/or rotate that video under some circumstances.

After many googles, I finally came across the IVMRMixingControl9 interface that the VideoMixingRenderer9 exposes, but, no matter what I did, I could not cast from a VMR9 to the MixingControl, like so:

Dim Mixer = DirectCast(VMR9, IVMRMixerControl9)

I kept getting an “Interface not implemented”. Then I happened across a post about a wholly different problem, but buried within it was a comment about needing to set the VMR into “mixing mode” in order for it to implement that IVMRMixingControl9 interface. Ugh! DirectShow is nothing if not interfaces. And odd dynamically implemented interfaces at that. Oh well.

A little more digging, and it turns out to be quite easy. Just obtain the IVMRFilterConfig9 interface from your VMR9 object, and call SetNumberOfStreams on it (with and argument 1 or more).

The end result is code that looks like this (remember, this is with a reference to DirectShowLib.net):

DIM FGM = New FilterGraph
Dim VMR9 As IBaseFilter = New VideoMixingRenderer9

FGM.AddFilter(VMR9, "Video Mixing Renderer 9")
Dim FC As IVMRFilterConfig9 = VMR9
FC.SetRenderingMode(VMR9Mode.Windowed)
FC.SetNumberOfStreams(1)

Dim Mixer = DirectCast(VMR9, IVMRMixerControl9)
Mixer.SetOutputRect(0, New NormalizedRect(1, 1, 0, 0))
Mixer.SetAlpha(0, 0.2)

Note that in this case, the SetOutputRect is reversing the output rectangle, so the video is going to end up flipped and upsidedown, exactly what I was needing. I’ve also set the alphachannel to .2, meaning the video is somewhat transparent.

Unfortunately, there doesn’t appear to be any way to rotate the video using the MixingControl, so that is my next topic of research.

Well, I suppose the economic storm finally caught up with me.

The company I was working for just sold. Unfortunately, it was more of a liquidation than a sale, and the buyer already has a pile of developers on staff.

Soooo. I’ll soon be available for other engagements.

If you or your company needs an experienced architect/developer/manager highly skilled in:

• VB.net
• Legacy vb to .net conversions (VB1 through 6, even the old DOS Basica and PDS, I’ve done ‘em all!)
• Code porting to .net (I’ve worked with Cobol and Pascal, but can read just about anything)
• SQL Server
• Document Management System Integrations (particularly, DocsOpen, Interwoven, and WorldOX, various versions)
• Legal and medical field software
• Office integrations (especially commercial level addin design and development)
• Low level integrations (serial port, networking, that sort of stuff)
• Installer building (particularly Wise or InstallShield)
• Development management
• Product design/architecture

By all means, leave a comment here or better, drop me a note using this form. I’d love to talk with you.

Thanks for reading!

I’ve just finished paving my main machine with Windows 7 64 bit, and was working on tidying up some of the finer points of my installation.

One minor item I use is a batch file with a reference to the excellent Poweroff utility. The batch file basically powers down the monitor, locks the machine, then goes into standby/hibernate mode. I attach it to a Ctrl-f11 hotkey to make it a quick keystroke to powerdown my machine.

Anyway, I have that bat on my path, and I happen to keep it out on a network drive (a NAS array), not on my local machine. I generally keep data off my local machine, preferring to only have program installs and temp files locally.

But when I pointed my shortcut to the network path and hit Ctrl-F11, I’d get that annoying “The publisher could not be verified” prompt. Every time!

Well, a few googles later and I came across this tip on annoyances.com.

It’s for Vista, but it also works in Win 7 (even the 64bit version).

Run gpedit.msc 

Go to User Configuration >> Administrative Templates >> Windows Components >> Attachment 
Manager

Add "*.exe; *.bat" to the "Inclusion list for moderate risk file types" setting.

I added *.bat to the list, as well as *.exe because, in my case, I keep a number of handy BAT files in folders out on my network drives and then include those folders in my path.

Works a treat. Be sure to read up on why to include this in the Moderate risk element and not the High Risk, though. Generally, if you have a reasonably good firewall/router, making this change should be safe.

My system had been getting less and less stable recently, to the point where I’d blue screen and crash the entire machine while just browsing the web in FireFox.

So, when in came up that I’d need to have access to a 64bit OS, I finally decided to pave this machine and lay down a bright and shiny new Windows 7 installation.

Of course, doing so meant a couple of things.

1. I had to make sure I had my old system available, just in case I needing any config files or whatnot. I keep all my data on a network server so that’s never been an issue. I used wbadmin (the Vista backup utility) to create a full VHD image of my Vista installation to a USB drive for this purpose.
2. I did not want to wipe out my current raid, even though I had the backup. So I picked up 2 1.5TB Samsung drives to form a new RAID1 array.
3. My mobo is the Intel Bad Axe 2 (D975xbx2), so it actually has support for the Intel ICH7 Sata raid controller and the Marvell Raid controller. Both can control up to 4 drives, so I figured I’d install the two new drives on the Marvel controller, leaving the existing Intel raid alone for now.

Problem 1

Unfortunately, idea 3 was my first problem. I couldn’t get Win 7 to see the Marvell raid. I spent the better part of a day fiddling with it, before I took the chance and disconnected the drives on the Intel raid. Sure enough, suddenly, the Win 7 installer could now see the Marvell raid.

Problem 2

My joy quickly soured though, when, about 20 minutes into the install, I got a message that the installation was “unable to read installation source files”. That’s it.

Hmm.

Could the CDRom image I burned be bad? Nope: a verify confirmed it was fine.

Maybe the raid array had problems? I reattached my Intel raid, booted Vista, and I could see the Marvell raid drive just fine. I scanned it anyway. Not a single problem.

Maybe I didn’t have the right F6 drivers for the Marvell controller? Some googles turned up that there was in fact, problems with the version of those drivers that Intel makes available, but even the older drivers direct from Marvell resulted in the same error.

Maybe my bios needs an update? Mine was several years old so I pulled the latest and uploaded. Still no dice.

With most of weekend gone, I decided to through a hail mary and try connecting the 2 samsung drives to the Intel raid controller ports. The concern was that, if I disconnected two of the existing raid drives on that controller, would I be able to boot back to the old raid if things still didn’t work? Or would the old raid be toast?

Deep breath, unplug the old, plug in the new, fire up the install, and…

It worked!

Problem 3

Way back, the main issue with 64bit Vista was I had no way to connect to our companies Cisco VPN with it. Well, I still couldn’t find Cisco 64bit drivers, and the 32bit versions won’t install into Win7 64. But, I’d come across the Shrew Soft VPN client before, so I thought I’d give it a shot.

I did need to dig up my Cisco configuration file, but once I found and imported it into Shrew Soft, I was connected first attempt. Pings to servers worked. Connected!

Problem 4

Toolbars. Little thing, granted, but I have run with a toolbar auto hidden on the left, as well as the taskbar at the bottom for ages. It’s comfortable and it put everything I typically use right there.

And Win 7 dropped that feature!

Yep, a feature that’s actually useful and MS drops it. Sigh. In reality, that decision seems to be getting quite a lot of bad blog, so I’m not alone in my sentiments anyway.

Fortunately, a feature in a program I’ve used for quite some time came to the rescue. The program is True Launch Bar from Tordex. I’ve written about TLB before, actually. It’s come in handy for a variety of purposes. For the past few years, when I’ve needed a handy gizmo and thought I’d have to download yet another widget, 9 times out of 10, TLB could already do the job.

This time, I used their “Standalone” version (included with the base package) to duplicate the functionality of the disconnected side toolbar, even though Win7 doesn’t support it directly.

If you like having a highly configured taskbar/toolbar, I (again) highly recommend True Launch Bar. It’s not free, but it’s cheap, and well worth the price.

Taming my Desktop Icons

One last note about my configuration. In the process of setting things up, I came across Fences by Stardock. It’s free. It does one thing, but it does it very well indeed.

Essentially, it allows you to “group” your desktop icons, and they stay in those groups, unlike under normal circumstances, where changing desktop resolution, or other things will tend to scramble your carefully arranged icons quite often.

It actually works on OS’s from Win 7 back to XP. Check it out.

A Minor Incompatibility

I’ve use DiskMapper by MicroLogic for ages. It’s a wonderful way to visualize your disk space usage. Yes, there are similar alternatives out there (like Zero Assumption’s Disk Space Visualizer), but I always seem to come back to DiskMapper.

Well, I tried the install and got an “incompatible application” error. Something about being a 16bit app. Yikes! 16bit!

Well, I pulled my DiskMapper installation files (post install) from the backup image I made, ran the app itself, and, after a quick paste of my registration details, I was up and running. So it would appear that the incompatibility was with the installer and not the app itself. Good news. And another good reason to make sure you have a full backup of your original system before making a switch like this.

And What About Win 7?

I’ve only been using it for a few days, so I’ll reserve some judgment for now. But I will say it feels a bit snappier, plus having the full 4gb ram usable (as opposed to only about 3.4gb under a 32bit os), is definitely a plus.

The ability to mount VHD files directly via the Logical Drive Manager is great. It’s my understanding that you can actually boot the machine into a VHD as well, but I haven’t tried that out yet.

Other than that, it really feels more like Vista SP2 than a really new OS.

A long (long) time ago, if you wanted your users to be able to enhance your product by add coding logic, you pretty much had two choices:

• Dig into Lex and Yacc or....
• Roll your own parser and scripting execution engine.

Then, around the time VB 6 was released, Microsoft introduced VBA. It worked, but it was expensive and a god awful complicated mess to integrate with your app, so outside of Microsoft Office (which even as of Office 2010, still supports it!), very few applications actually made use of it.

Around the same time, the Microsoft Scripting Control was released. This was an ActiveX control you could use from any COM compatible language to embed VBScript. Now, of course, this is VBScript, not a "real" language like C or even VB. But, it was free, easy to obtain, and very easy to use.

As the years have rolled by, .NET has steadily grown in capability and while the Windows Scripting Host exe is still shipped with Windows, the old VBScript and JScript scripting has largely been supplanted by either:

• ASP and more recently ASP.NET
• Powershell
• Dynamically compiled .NET code
• and likely lots more options I'm not familiar with

Now, all these options are good, and each definitely has it's place, but, for many purposes, good ol' VBscript still fits the bit quite nicely.

But can you use it from .NET? And if so, how?

The Tempest in the Teapot

Before I continue, I should point out that any time you start talking about allowing users to add their own code into your application, you're opening up a huge can of worms that you'll need to deal with. Things like properly catching exceptions from badly written user code (yeah, that never happens), adding watchdog timers to deal with hung and infinitely looping user code, security concerns, and the like all will have to factor into the decision. You have been warned .

So Simple It Hurts

I had a plugin project recently where I wanted to give the user the ability to write some very simple logic to expand the functionality of the application.

Of course, I wanted to build a full plugin API, but I also wanted to provide a lighter-weight option for those users that didn't want to dive head-first into a full on .NET project. VBScript seemed like the obvious choice.

A few Google searches later and most everything I found was talking about how to dynamically compile .NET code, which is cool indeed, but not what I was really after. Other articles and posts insisted that users should convert their VBScript code to .NET (ok, yeah, but that's not really the point now is it?).

Then I did a Google Desktop search of my own system and turned up some VB6 code I'd written ages ago to experiment with the Microsoft Scripting Control.

Now, I know that .NET languages support accessing ActiveX Controls and COM objects in general, but this was pretty old stuff. Would it actually still work?

I cobbled up a dirt simple VB.net project:

Public Sub Main()
    Dim Script = New MSScriptControl.ScriptControl
    Script.Language = "VBScript"
    Script.AddCode("sub Main" & vbCrLf & "MsgBox ""This is a Test"" " & vbCrLf & "End Sub")
    Script.Run("Main")
End Sub

Be sure to add a reference in the VB.net project to the COM object "Microsoft Scripting Control".

Run it, and lo and behold, I get the "This is a Test" message box, straight from VBScript!

Obviously, there's lots more to making use of the Scripting Control than just this, but, clearly, VBScript is still very much a choice for adding limited programmable logic to your application.

Managed code (VB.net and C#) are great for a lot of things, but unfortunately, even as of VS2008, it's still missing at least one. Standard DLL exports.

You see, way back in the olden days, virtually every DLL in Windows was written in C or assembler and exported functions via the standard DLL export table.

Then came COM and now .NET, providing much easier, object oriented export capabilities. Old style EXPORTS have been falling by the wayside ever since.

Unfortunately, if you program for Windows, eventually you'll find yourself needing to either consume or provide exports. There's just no way around it.

For consuming (ie simply "calling") exported functions in a DLL, .net makes that almost trivially easy. All of the Windows API can be called in this way, simply by including the proper attributes (for VB) for the function declaration in your application. Here's an example for the SENDMESSAGE Windows API function.

<DllImport("user32.dll", SetLastError:=True, CharSet:=CharSet.Auto)> _
Private Shared Function SendMessage(ByVal hWnd As IntPtr, ByVal Msg As UInteger, ByVal wParam As IntPtr, ByVal lParam As IntPtr) As IntPtr
End Function

The Hard Part

However, exporting functions from a .NET DLL in the standard Windows API style is not near as easy.

Why would you need to do this? The main reason is to provide hooks that other applications can call. There are many, many applications out there that require addins or plugins to export standard DLL entry points. Being unable to do this in .net means either having to write a shell in C/C++ around those entry points (doable but cumbersome), or simply not providing that functionality.

The good news is that the .NET compiler designers didn't completely forget about such down-to-the-metal tidbits as this. The bad news is that they didn't provide any syntactic sugar to make it straightforward either.

Emilio Reale posted an excellent article on CodeProject that discusses the dirty IL (Intermediate Language in .net speak) mechanics of how to:

1. compile your .net DLL
2. disassembly it with ILDASM to IL source code.
3. find the necessary bits in the disassembled output and what to change them to
4. reassembly the IL source using ILASM into a DLL with the proper functions exported.

All fine and dandy till you look at what's required. Needless to say, it's an amazingly involved process to perform manually.

Fortunately, another CodeProject contributor tackled this problem and posted this article. In it, he presents a small utility and attribute definition dll that allows you to export a function (almost ANY function) from a .NET DLL simply by applying an attribute to it, like so:

<ExportDllAttribute.ExportDll("MyFunction", _
System.Runtime.InteropServices.CallingConvention.Cdecl)> _
Public Shared Sub EntryPoint_MyFunction()
     ...my code goes here....
End Sub

and then running the utility on the compiled DLL, which automates the above tasks.

It takes a little work to get things set up, but in the end, it worked flawlessly for me. Within just a few hours, I'd put together the shell of a plugin for an application that I'd had reservations about writing plugins for, simply because it looked like I'd have to do so in C++.

Now, the whole plugin is done, it's all in VB.net (my language of preference currently), it's a single DLL with no dependencies (other than the .net runtime ), and it can be deployed by simply copying it into a folder.

Can't get better than that!

Just came across this excellent little book. Originally published in 1868, it's a compendium of just about every sort of mechanical means of transferring one type of motion to another than you can think of. Lots of illustrations. Makes a great reference, and the best part, it's available free online in a djvu version. It's a 75mb download, because the book has just been scanned in (even the text), so it's not really searchable.

But who cares?

If you're into steampunk in any way at all, this is a must have reference book.

As a side note, while the DJVU format and viewer is quite nice, I preferred a PDF version.

It took some effort, because, when I tried to convert it (using the PRINT function from DJVU into a PDF printer), I kept getting errors about the Courier font not being found (which it most definitely IS installed on my machine).

After some fiddling, I ended up being able to "print" it to the "Office Document Image Writer" printer driver. I then loaded that file up into the Office Document Image Viewer, and printed to the PDF printer from there.

I was working on some validation logic today, and was getting heavily into generics in several classes, when I stumbled across an application of generics that I hadn't see before.

Take the following sample code (granted, it's trivial, but it should get the idea :

Public Class Form1
    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load

        Dim s As String = "Testing"
        GenericTest(s)

        Dim i As Integer = 5
        GenericTest(i)

        Dim f As Single = 10.7
        GenericTest(f)
    End Sub
End Class


Public Module Generics
    Public Sub GenericTest(Of t)(ByVal Variable As t)
        Debug.Print(Variable.ToString)
    End Sub
End Module

Notice that the GenericTest function is early bound directly to 3 different variable types due to the use of generics. Just like using object type variables but without some of the stigma .

Also note that GenericTest is defined in a module. I'd only seen generics as a way of defining classes before, never just a single function, and certainly not a function in a module.

Anyway, this may be old hat for many VB.net people, but I found it interesting, at the least. Not exactly sure how I might leverage it at this point, but it's always good to have things like this in your toolbox.