[VB6, Vista+] Simple Task Dialog

I posted sample code using this class for raising simple Task Dialogs several times over the years, but I never gave it a CodeBank thread of its own.


Task Dialogs

Now that Windows XP is dead we can start making more use of features like this to avoid that old Windows 3.1/95 look and feel. This class is a basic wrapper for the calls required to make use of the Task Dialog.

You can expand upon this with callbacks to make use of even more Task Dialog features, but here we have the core subset covered without extra modules to host those callbacks. The result is a simple alternative to the VB6 MsgBox.


Requirements

Window Vista or later.

An application manifest selecting the Common Controls 6 assembly.

Startup logic that loads shell32.dll and comctl32.dll before any Forms or other UI elements - and in the correct sequence.


Details

STDlg.cls is a VB_PredeclaredId = True class so you don't have to create additional instances. It wouldn't make sense to have more than one in a program anyway.

It has just one method: TaskDialog(), loosely patterned on MsgBox().


Caution

STDlg.cls is unlikely to work correctly within the IDE if you run VB6.exe with a Common Controls 6 manifest itself. Most people don't do this though.

Normally it checks the loaded comctl32 version to determine whether to try to use Task Dialog or just substitute a MsgBox call instead. You could add a "running in the IDE" test to the code though.

Attachment 118883

I like this MsgBox alternative... a lot.

Just a couple of notes when project is NOT compiled.

I am one that runs IDE manifested. Just used to it. Because of that I get an error & the error code is because the icon resource wasn't found. That error doesn't occur if the IDE is run not-manifested, but the icon isn't displayed on my Vista box. I assume because the project isn't compiled into an exe at this point?

To get rid of the error, while IDE is manifested, I simply had to ensure the Icon value was set to zero & got the same result (no icon) as if IDE wasn't manifested.

Out of curiosity. Was your screenshot from a compiled exe sample project or uncompiled (Ctrl+F5)? I ask because yours shows the icon where mine didn't. I didn't happen to see any comments as to whether the icon would display if uncompiled?

Edited: Icon does show when compiled. A little more feedback follows

1. The question mark icon no longer exists. But microsoft doesn't want it to:

Quote:

---

Question mark icons

Use the question mark icon only for Help entry points. For more information, see the Help entry point guidelines.
Don't use the question mark icon to ask questions. Again, use the question mark icon only for Help entry points. There is no need to ask questions using the question mark icon anyway—it's sufficient to present a main instruction as a question.
Don't routinely replace question mark icons with warning icons. Replace a question mark icon with a warning icon only if the question has significant consequences. Otherwise, use no icon.

---

This can be worked around if absolutely needed by supplying one's own "question" icon in their resource file.

2. It appears valid "standard" Icon values range from -1 to -9. The ones that you don't have included in your sample project are various forms of the Shield/Security icon.

3. Some annoyances.

a. Doesn't appear you can see the dialog with icon during IDE. Not a huge deal, but not WYSIWYG either. And a custom flag may be needed so that one can override which "msgbox" style is displayed if on Vista+ and wanted to see what it might look like on XP or lower. Minor issue since XP has one foot in the grave.
Updated: unless another workaround exists. The indirect version of the TaskDialog allows icon handles to be passed

b. Now that we have the ability to use custom icons, they must come from the resource file, correct? Well VB may not allow you to add a 32 bit, alpha blended, icon to the resource file as an Icon. It always will as a custom resource. I haven't searched hard, but haven't seen any documentation whether or not the icon reference that TaskDialog uses must be from the icon group of the resource file (i.e., RT_ICON). There are methods to force VB resource files to accept 32 bit icons, but would require effort.

Quote:

---

Originally Posted by LaVolpe

Edited: Icon does show when compiled...

---

Sure - since the (Int)ResourceID is looked up in the (App.)hInstance which is passed
in the appropriate Parameter - and in case of IDE-Mode it is the hInstance of VB6.exe.

Quote:

---

Originally Posted by LaVolpe

1. The question mark icon no longer exists.
This can be worked around if absolutely needed by supplying one's own "question" icon in their resource file.

---

Either that (when App.hInstance is used further) - but there's also other Resource-Binaries
one can easily retrieve a hInstance from - as for example per LoadLibrary from shell32.dll.

...which then would offer a quite nice Set of System-Icons without having to include them as a
separate Resource (e.g. different QuestionMark-Icons are offered under either 263, 289 or 324 -
one can lookup those IDs for example here: http://www.glennslayden.com/code/win...ll32-dll-icons

For a short Test that worked here, i only had to adjust to the following (in dilettantes original example):

Code:

---

        Static Shell32Instance As Long
        If Shell32Instance = 0 Then Shell32Instance = LoadLibrary(StrPtr("shell32.dll"))
        HResult = TaskDialogAPI(hWndParentForm, _
                                Shell32Instance, _
                                StrPtr(WindowTitle), _
                                StrPtr(MainInstruction), _
                                StrPtr(Content), _
                                Buttons, _
                                Icon, _
                                TaskDialog)

---

After the small change above - it is enough to switch the formerly passed 101 ResourceID within
the TestIt-function to one of the IDs in the IconID-Range of shell32.dll.

And that will work also in the IDE of course (due to the aforementioned switch to a different hInstance).

Olaf

Quote:

---

Originally Posted by Olaf

...which then would offer a quite nice Set of System-Icons without having to include them as a
separate Resource...

---

Very nice solution for alternate icons.

If offered, probably best to stick with the Vista Shell32 I would think. Seems with every O/S, Shell32 grows in icon count. Wouldn't want to reference some Win8 icon only to crash when app run on Vista if that icon exceeded the Vista Shell32 count.

Just FYI. If using this in IDE, a simple workaround for WYSIWYG (see icons) is to farm off the TaskDialogAPI call to the Indirect Dialog call (not available in his sample project). That would allow you to display icons during IDE easily enough & though that Indirect call has a lot more options, it includes the basic options of the Direct call. Code change would require a callback procedure added to the project

Quote:

---

Originally Posted by LaVolpe

If offered, probably best to stick with the Vista Shell32 I would think.

---

Yes - perhaps a good idea to include a check which keeps the IconIDs in a safe range,
in case dilettante is planning to e.g. enhance the TASKDIALOG_STANDARD_ICONS - Enum
about a new Member: TD_USE_SHELL32_ICONID = 2 ... or something like that - then
the hInstance-Member could be switched dynamically (depending on, if TD_CUSTOM_ICON
was passed, or TD_USE_SHELL32_ICONID came in)...

Quote:

---

Originally Posted by LaVolpe

Just FYI. If using this in IDE, a simple workaround for WYSIWYG (see icons) is to farm off the TaskDialogAPI call to the Indirect Dialog call (not available in his sample project). That would allow you to display icons during IDE easily enough & though that Indirect call has a lot more options, it includes the basic options of the Direct call. Code change would require a callback procedure added to the project

---

Yeah, seen that more powerful entry-call into the API in the MSDN, it offers direct passing of hIcons
(among other niceties) too - but as I read in the normal Forum - there's apparently a few new Classes
"in the work" which enacapsulate it - and hopefully will shine up in the next days/weeks here...

Maybe my suggestion to make the Shell32-IconPool conveniently available, is taken up -
and already included in one of the Interfaces of those new Classes then... ;)

Olaf

It sounds as if the questions above have already been satisfied by now.

I really hadn't intended this as drop-in code so much as the bare bones required to show use of the new feature.


Actually for more general use this would probably work better implemented as a separately compiled DLL, written in VB6 or in VC++ for that matter. Such a DLL could be designed to accept custom icons passed in some more generic fashion, such as an ICO "file image" stored by the caller as a custom resource.

At least that could be a way to deal with things like alpha-blended icons without a lot of extra logic in the client/host program which after all just wants to display an "upgraded" MsgBox without making a career out of it. And then most of your debugging issues go away.


I've really just been posting code based on old snippets lately to help people understand what some of the positives of the post-XP world are for VB6 programmers. Someday it might be worth posting code samples making use of things like the Compression API, however Windows 8+ are and probably will continue to be quite unpopular. Even the upcoming "Windows 9" is starting to look like far less of a mindshare grabber than I'd hoped.

Personally I'm doing far more Android development today and await the day we get desktop builds that let us leave Redmond in the rear-view mirror forever.

I very much like the idea of the TD_USE_SHELL32_ICONID flag. I tested it on my implementation... changed the hInstance to GetModuleHandle(shell32), and it works. Going to add it to my project (the full class implementation of TaskDialogIndirect) if there's no objections? Will of course credit the idea. It obviously already supports custom icons but this would be preferable to creating an hIcon for most needs.

Draft code: (need to get shell32 path from correct way, will do before publishing revision)

Code:

---

If (uTDC.dwFlags And TDF_USE_SHELL32_ICONID) Then
    uTDC.hInstance = GetModuleHandle("c:\windows\system32\shell32.dll")
    uTDC.pszMainIcon = MakeIntResource(m_Icon)
End If

---

Also would add imageres.dll, where many more icons are, especially for newer things.

Quote:

---

Originally Posted by fafalone

I very much like the idea of the TD_USE_SHELL32_ICONID flag. I tested it on my implementation... changed the hInstance to GetModuleHandle(shell32), and it works. Going to add it to my project (the full class implementation of TaskDialogIndirect) if there's no objections? Will of course credit the idea.

---

Nah, no need for any credits - it was trivial enough.

Quote:

---

Originally Posted by fafalone

Draft code: (need to get shell32 path from correct way, will do before publishing revision)

Code:

---

If (uTDC.dwFlags And TDF_USE_SHELL32_ICONID) Then
    uTDC.hInstance = GetModuleHandle("c:\windows\system32\shell32.dll")
    uTDC.pszMainIcon = MakeIntResource(m_Icon)
End If

---

---

In the above, no full path is required (since System-Path's are searched for Dll-references anyways, and for 32Bit-
Processes the lookup will automatically choose the right "SystemPath" - as e.g. SysWow64 when on a 64Bit system).

Quote:

---

Originally Posted by fafalone

Also would add imageres.dll, where many more icons are, especially for newer things.

---

In this case you should perhaps use LoadLibrary (as in the original Demo) instead of
GetModuleHandle (which tries to find *already-loaded* Modules in the running Process)-
also not really sure, if shell32.dll can be expected to be *always* already loaded by e.g.
a very sparsely populated VB6-GUI-App. Using LoadLibrary instead doesn't really hurt, when
you put the hModule-Vars globally into a *.bas Module - populating them only once from
inside your Class-Instances then (in case they are still at Zero).
When the Process dies, the Handles will be freed anyways - and the RefCounters which
are involved on a loaded LibHandle are only Process-wide - and die with it also.

Taking care of correct RefCounters on LoadLibrary-loaded modules is IMO only important,
when it's your very own Dlls (not some System-ones) ... *AND* when you plan to unload
them on your own, whilst the Process is still running (e.g. for a dynamic Update on your
own \DllBin\-SubFolder - where you might want to overwrite a Dll-File with a newer Version -
followed by a reloading into the still running Process per LoadLibrary).

Olaf

Hmm.. the everything seems to be working well enough with GetModuleHandle; I do call it every time the dialog is constructed, but isn't it already loaded in general as a major system resource- referring to imageres.dll too, which is most certainly not specifically loaded by VB6 or my test app. I would imagine a non-system critical DLL that's not used by default may require LoadLibrary then? Is there also some benefit to LoadLibrary even if the DLL is always loaded in Windows?

Also, if you just use a generic "shell32.dll" input... does it load from SysWoW64 if that's present? Because that would be the 32-bit version IIRC ("windows on windows64"). If they're the same icons at the same ids that's ok, but I haven't looked into it. I know CSIDL_SYSTEM returns System32 and has CSIDL_SYSTEMX86 to get SysWoW64 specifically if present.

Quote:

---

Originally Posted by fafalone

Hmm.. the everything seems to be working well enough with GetModuleHandle; I do call it every time the dialog is constructed, but isn't it already loaded in general as a major system resource- referring to imageres.dll too, ...

---

Nope, if you put the following into Sub Main() (tested on Win8-64Bit):

MsgBox GetModuleHandle("shell32.dll")
MsgBox GetModuleHandle("imageres.dll")

You will get Zero both times (when run in a compiled App and not in the IDE).

One might get lucky with "shell32.dll" later on, when some other COMponent (or Declare)
was already called - but "imageres.dll" is very unlikely to be already loaded in a VB6-App.

Better to use (in your Class - with gShell32Instance and gImageResInstance declared globally at Module-Level)

Code:

---

Private Function GetShell32Handle() As Long
  If gShell32Instance = 0 Then gShell32Instance = LoadLibrary("shell32.dll")
  GetShell32Handle = gShell32Instance
End Function
Private Function GetImageResHandle() As Long
  If gImageResInstance = 0 Then gImageResInstance = LoadLibrary("imageres.dll")
  GetImageResHandle = gImageResInstance
End Function

---

Quote:

---

Originally Posted by fafalone

Also, if you just use a generic "shell32.dll" input... does it load from SysWoW64 if that's present?

---

Yes, definitely.
And even when you put in an explicit Path as "c:\Windows\System32\..." -
it would be resolved/redirected to SysWoW64 from within a 32Bit-Process.

The GetSpecialFolder-APIs are not necessary at all.

What's also wrong currently is, that you allow a mix of "Shell32-related Icon-Flags" together with "ImageRes-Flags"
E.g. then expecting different Icons loaded from two different resources for the Main-Icon and the Footer-Icon -
that's not possible, because the Dialog-Call in the uTDC-Struct only allows one single hInstance-member...

Also note that - whilst the IDs in "shell32.dll" give the same (only differing in small details) Icons from Win-XP to Win8 -
that there's definitely an "ID-Shift" between e.g. Win7 and Win8 for the Icons in "imageres.dll".

But perhaps better to continue in your other Thread - where your CodeBank-contribution is located.

Olaf

I'll check on Win8 but on Win7 GetModuleHandle works in the compiled app as well. I'll switch it over to LoadLibrary though.

That's for pointing out the mixed hInst's, not sure how I overlooked that.

Very nice implementation.
A small note though:
InitCommonControls is not a function but a sub (void InitCommonControls)! There might not be any noticeable problem at first but you are corrupting the stack this way.

vb Code:

Private Declare Sub InitCommonControls Lib "comctl32.dll" ()

Also, you could have written it as a standard module, since there is only 1 function to call and no properties to set.

Ahhh yes dilettante. It has some nice features. I like the "My Main Instruction" feature, and also the ability to specify custom icons. I do use the MsgBox but I've long since used my MsgBoxEx that I've tweaked on for years, using the MessageBox API call. I put yours and mine side by side, and I couldn't see any difference in the style.

The thing mine has is the ability to customize the button labels and also the ability to set a timer for it (after which time it times out and returns). I use this feature extensively.

I've re-posted your project with both routines included (your InitCommonControls API and my MessageBox API). Maybe someone will be motivated to merge them. The custom button caption is just something I can't live without.

Again, nice work,
Elroy

Attachment 120079

Elroy, just a heads up. The 'indirect' version of the API allows nearly full customization: custom captions, timer event for auto-closing dialogs, checkbox control, option buttons, command link button styles, progress bar (standard or marquee), multi-page dialogs, displaying/reacting to hyperlinks, an expando button, footer area, interaction with the dialog for things like "Apply" buttons that when clicked are acted on, disabled, but dialog remains open, and much more. That "indirect" version falls just short of letting the user completely customize it. Still has limitations, but some of us have already figured ways around them

In my opinion, the biggest drawback to this Vista+ API is just that: Vista+. If using this as a better message box, then not too big of a deal. But if you are designing a UI around what this API gives you, one is in for a lot more work if they want that project to also run on XP. XP may be on its way out, but I think it will still be in the mainstream for several more years to come, my opinion. So, using a nice new Dialog, but can't use all the bells & whistles on XP & project is required to be XP compatible then: a) create multiple versions of your app (XP, Vista+), b) create dumb-downed msgbox's for XP clients, or c) create a suitable substitute to replace this Dialog when on XP & if including lots of the bells & whistles, might as well just create a custom user control

P.S. Anyone that comes across this post, not disrespecting Dilettante's project. As mentioned above, this project has a fall back to a standard VB msgbox for XP clients. But if any of the bells & whistles of the other version of that API were used; well then ... that's a whole other matter, but doesn't apply to this thread - that would be comparing apples to oranges.

Ahhhh, good to know. I've got dilettante's code tucked away, and definitely need to look this approach further. However, I also have the problem of quite a few XP machines still lingering. In fact, the machine I'm given to use at one of my primary clients is an XP machine. I usually setup my powerhouse laptop and borrow a monitor from it to get two monitors on my laptop, but I still have to port updates over to it and do my testing there. They're in the process of "SLOWLY" upgrading everything to Windows 7, but these places have the viscosity of hardened putty. (They are TOTALLY the reason that computer stores have "commercial" counters where you can buy hardware with old OS's and old Software).

There is a project in this codebank that uses the other API version. I also have one, but won't be posting it for another couple weeks (out of town next week) & want to dummy-proof it a bit more as I find the time, no hurry. My version will be completely useless on XP, it will contain all the bells & whistles plus some hacked ones. And am not in the mindset of creating some GUI fallback to replicate the dialog for XP clients.

Oh gosh, LaVolpe, I totally agree. It's just that I do have to appease my clients. I'm sure you know about that. I'm probably stuck in VB6 for some time though, but that's just because Microsoft has been so dim-witted about the whole VB language thing. I suppose that I still have hopes that they'll rip the 64-bit VBA out of office and write a true machine language compiler for it. You know they could easily do it because the p-code interpreter does it. But yeah, new spiffy features are almost always a good thing. :) Have a nice trip.

Well as a messagebox replacement it's simple enough to add a fallback; just put the text fields into one multi-line string, and pick one best match for icon. Could be done with this project and with version using the expanded api (see here)... since mine is also useless on XP. It was just this past year or two that I really gave up on trying to maintain XP compatibility for new projects, and it's been pretty fun bringing in modern features into VB6. I might add a fallback as a basic feature, but I've got a few things ahead of it.
Also, what does 64-bit Office VBA allow you to do that VB6 doesn't? 64-bit shouldn't really be an issue for VB, especially when it's not compiled.

Oh gosh, fafalone. It'd just be nice if Microsoft made a re-commitment to COM based architecture. They clearly still maintain it because all of VBA (including 64 bit VBA) is COM (not NET) based. I've outlined elsewhere some new features that could be added:

* a LongLong type which now exists in 64-bit VBA.
* native AERO support.
* true Unicode support without jumping through hoops.
* easier support of the SxS stuff, possibly compiling OCX and DLLs into the EXE.
* more limited variable scoping, with possibly new Block/End Block keywords.
* maybe thread spawning for multi-threading.
* a meta-command that prohibits a runtime Redim as qualifying for a variable declaration.
* development of METRO apps.
* an "Option Explicit Type" meta-command forcing Variant (or otherwise) declaration.

And, most importantly, it compiles VB6 code absolutely "out of the box" into machine code.

Also, as I've stated elsewhere, I think they'd TOTALLY be back in the game if they built it into Windows 10, just like VBA in Office and BASIC in the original Microsoft OS (before MS-DOS). In fact, GWBASIC and/or BASICA was distributed with every version of MS-DOS.

Also, they can clearly do it because 64-bit VBA easily compiles to p-code, and the p-code interpreter obviously compiles to machine code, or the VBA code would never run. Just turn the p-code interpreter into a compiler that writes an EXE file rather than immediately executing it. It's not like this isn't something they haven't maintained in years. They're just afraid of their own success, and the NETters seem to have them blackmailed (who knows).

But fafalone, you take care.
Elroy

@LaVolpe
Would you mind if you posted a link to your implementation here, once you upload it? ;)

Quote:

---

Originally Posted by Cube8

@LaVolpe
Would you mind if you posted a link to your implementation here, once you upload it? ;)

---

No, I'll post in this codebank & leave it up to Dilettante whether or not he wants to reference it