MsgBox( ), meet TaskDialog( ) Filed by Ben Baird on Friday, March 10, 2006 at 20:39:36

As long as we're on the topic of Windows Vista, let's take a look at another of Longhorn's UI updates. A new function, TaskDialog (and its brother, TaskDialogIndirect), is now available in comctl32.dll. It's a replacement for the tired old MessageBox API, and contains many improvements that developers have requested over the years.   If you have a Vista machine handy, you can download the VB6 source code for this project below. It contains full VB translations for the TaskDialog API definitions, as well as an example of how to use both TaskDialog and TaskDialogIndirect.   Of course, if you see the declarations, you'll realize that my basic sample only scratches the surface of what's possible in TaskDialog. Certainly you can provide your own custom command buttons and option buttons, but there's also a handy callback interface as well as support for placing custom icons in a few strategic places on the TaskDialog UI.   I only wish that this API were available in Windows XP - if your code also targets legacy platforms, then you'll have to revert to MessageBox in cases where TaskDialog is unavailable. Microsoft has no plans to provide this API in Windows XP versions of comctl32.dll. VBT_TaskDialog.zip Comments (125)

VB6 on Windows Vista: Down, but not out! Filed by Ben Baird on Sunday, March 5, 2006 at 21:06:17

I recently installed the latest MSDN build of Windows Vista, build 5308. Needless to say, the first thing I installed was Visual Studio 6.0. Just as a test, of course.   I'm happy to say that, for the most part, VB6 continues to function. There are some UI oddities (and downright malfunctions) due to Vista's new common dialogs and double-buffered desktop rendering. But you can still write code and compile programs. (Unfortunately, I have to do it with a base VS6 install, because I can't get any service packs to do anything on this build of Vista.)   In any case, I thought this might be a good time to see just how much of Vista's new functionality I could access using a language with no native access to Windows Presentation Foundation (WPF), to say nothing of Dot Net. You can observe my initial efforts below:   On the left, we see a base Visual Basic form, with no extra code. On the right, we have the results of a few basic calls to Vista's new Desktop Window Manager (DWM). Yes, Visual Basic 6.0 is fully capable of taking advantage of the Aero Glass UI!   Of course, there's so much more to do before we actually see anything useful on this form, so I've been delving into the thousands of new Win32 API declarations that Vista provides in order to get a handle (no pun intended) on the new world order.   If you have Build 5308, you too can explore the vast new functionality available even to non-.NET developers. Simply download the February CTP release of the Windows SDK found on the Windows Vista Developer Center and start digging through the new C++ headers.   More to come as more develops. Comments (5)

2005 Filed by Ben Baird on Tuesday, November 22, 2005 at 22:00:32

Partly out of curiosity, and partly because my current place of employment requires all of my web development to be done in ASP.NET, I installed a copy of the newly-released Visual Studio 2005 on my home system early this week. I must admit that the code editor is pretty impressive. (And I prefer to spend my time there rather than the WYSIWYG editor - I still don't buy into that wacky "web page as form" business.) Anyway, I will continue to work with it since I'm sure ASP.NET 2.0 will be featured prominently in my future intranet projects. About VB.NET: What can I say? I read the bullet list of "What's New?," shrugged my shoulders, and promptly hit the big red X. I'll continue to use VB6 for my client-side projects. Comments (1)

Roll your own form designer Filed by Ben Baird on Saturday, August 20, 2005 at 21:44:05

For today's lesson, I've pulled a sample from the school of 100% VB code. Well, maybe 99%.   If you want to give your users full control over the visual arrangement of your application, why not take a page from Visual Basic itself? Give them a screen painter so they can drag and drop to their heart's content:   Form customization can be as simple or as complex as you want it. In this case, I decided to take it as a challenge to code most of the functionality without any API calls. My only exception were the SetPixel calls for drawing the form's control grid (which, arguably, we could have done without).   The beauty of this example lies in its ease of use in any project you wish. Simply drop the CControlSizer class into your project and make a few calls to it from your form(s): Private Sub Form_Load() Screen.MousePointer = vbHourglass Set ctl = New CControlSizer ctl.GridSize = 8 ctl.AttachForm Me 'The form that is using the designer class ctl.LoadControls 'Load control locations from previous session DrawGrid 'Draw the GridSize by GridSize pixel grid on the background of the form Screen.MousePointer = vbDefault End Sub   Any changes to the behavior of this form designer would be made completely within the CControlSizer class. Even the PictureBox drag handles are added to the form at runtime by the class!   As an exercise for the reader, consider what it might take to reduce the required amount of form-based code even further. Perhaps I'll revisit this project in a future entry. FormDesign.zip Comments (9)

Menu-like Popups in Visual Basic Filed by Ben Baird on Thursday, June 16, 2005 at 18:20:39

It was perhaps Microsoft Office that popularized "special" popup menus which could house such candied interface gadgets as color pickers and edit fields. Interestingly enough, however, it's not as difficult as you might think to reproduce similar effects in VB code.   There are really only two major gotchas to work around when using a VB form as a menu.   First, you need to make sure your popup never gets the focus. (If it does, your main form's titlebar will go inactive, which never happens with a "real" menu.) There's not much to this one. A simple API call will display your form without giving it the focus: ShowWindow hWnd, SW_SHOWNOACTIVATE   You should also prevent your popup from becoming active when the user clicks directly on it. This must be done through subclassing, and as it turns out, the Windows API has a very convenient feature for our purposes here: MA_NOACTIVATE. You'll use it in your subclassing callback procedure: If wMsg = WM_MOUSEACTIVATE Then GetCursorPos pt If WindowFromPoint(pt.cx, pt.cy) = hWnd Then 'Don't allow our popup to be activated, or else the main 'window's titlebar will go into an inactive state. frmMenuCallback = MA_NOACTIVATE Exit Function End If End If   The second gotcha is that you need your popup to receive mouse and keyboard events that it wouldn't receive under normal circumstances. Your popup form isn't technically active, but it needs to capture events such as the escape key (to hide the popup) and mouse clicks outside of the popup's boundaries (also to hide the popup).   As it turns out, this isn't much of a problem either. Once again, the Windows API comes to the rescue - this time in the form of the SetCapture API call. You'll want to call it in a few strategic places, including just after you've displayed your popup, and after a MouseUp event in which you don't want to hide your form. (This is because your original SetCapture call becomes invalid once the user releases the mouse button, thereby releasing the input capture.)   The downloadable popup color picker sample covers these requirements, along with some minor things. I've left the fancying-up of the popup's interface as an exercise for the reader. Consider how you could add features such as hot mouse tracking and, if you're feeling bold, in-menu text editing. PopupForm.zip Comments (1)

Debugging Multithreaded VB6 Applications Filed by Ben Baird on Saturday, April 30, 2005 at 20:21:57

I recently wrestled with finding a good way to debug a multithreaded VB6 library I've been working on. You see, the last time I'd written anything multithreaded, VB 5.0 was still the big thing. Between then and now, 6.0 came along and messed with all sorts of language internals to foul up the works - most importantly for me, of course, were the changes in thread local storage (TLS).   When I first began the project, I didn't concern myself with having to debug in my compiled executable. However, this project involves a lot of Winsock traffic that has to occur simultaneously to work properly, so once I had my core Winsock functionality, I had to move into the domain of multiple threads.   So I started with what I vaguely remembered from my years with VB5, and boy - was I in for a surprise!   First of all, I discovered that accessing module-level entities (such as global variables) from a threaded class is a big no-no. Doing so didn't crash my executable, but it did cause my thread to simply hang at that line of code and never run to completion.   Second, there are a fair number of Visual Basic statements you simply can't use from a threaded class. VB's file access statements are included in this grouping of taboo-ness, so my initial attempts at outputting debug logs met a miserable (but swift) demise.   Then I made one more futile attempt at logging result codes and errors. And I'm slightly embarrassed to admit, I should have known it wouldn't work, but again I'll have to attribute my mental lapse to having only a little experience, several years previous, with VB multithreading.   I tried to access a COM object cross-process, which in turn attempted to print text to a VB TextBox control. (The punchline being, of course, that VB controls are single-threaded, making their properties inaccessible to me even if the out-of-process COM server had been multithreaded itself.)   I spent a few hours on the problem of how to send output from my worker threads to something I could see on my screen. But I was running out of time and finally settled on a quick and achingly primitive solution: Beep   It turns out Beep is one of the few thread-safe ways in VB6 to give any feedback at all, and if you don't need anything fancy, it's somewhat easier than rolling an API-based solution (an option I'd also been considering).   One beep if by land, two if by sea... Comments (8)

The Great Retool of 2005... Filed by Ben Baird on Sunday, April 3, 2005 at 17:09:05

It happens. But where to start? Well, this time we start with a change in the entire format. (The cheesy blogging interface, designed by yours truly, must have tipped you off?) The previous retool, which occurred a few years ago, was a result of my increasing fascination with database-driven web design and Active Server Pages (ASP) technology. My, how time flies! I had thought that such a change would help me keep my site a little more up to date, but as most of you probably noticed, I was only active for a few months before updates lapsed once again. But you, the reader, are still here. (I know - because your visits still number in the thousands per day!) And I'm back once again. I've moved the site to a new webhost, and I'm in the process of converting (but mostly rewriting from scratch) the site to PHP. It's going to take some time - My experience thus far with PHP can be measured in mere days. Anyway, source code will be back up "soonish." I have some different ideas about how I'm going to do that, this time around. In case you care - yes, I still use Visual Basic 6.0. And no, I have no plans to turn Visual Basic Thunder into a .NET site, nor do I use Visual Basic.NET for anything, though I've still got the install CDs sitting on my desk. My views on Visual Basic.NET remain the same. I'm back. Let's see if I manage a little more activity this time. Comments (12)