[VB6] Form-less CommonDialog (comdlg32.ocx)

It is possible to show the common dialogs without using a Form to put the ActiveX control in. Here's how:

Code:

---


'In a BAS module
Option Explicit

Private Sub Main()
    Const cdlCCFullOpen = 2&, cdlCCHelpButton = 8&, cdlCFApply = &H200&, cdlCFBoth = 3&
    Const cdlCFEffects = &H100&, cdlCFHelpButton = 4&, cdlHelpContents = 3&
    Const cdlOFNAllowMultiselect = &H200&, cdlOFNExplorer = &H80000, cdlOFNHelpButton = &H10&
    Const cdlPDHelpButton = &H800&, cdlPDNoWarning = &H80&, cdlPDPrintSetup = &H40&

    On Error Resume Next

    With CreateObject("MSComDlg.CommonDialog")      'Late-bound
  'With New CommonDialog                          'Referenced comdlg32.ocx (not from Toolbox)
        .AboutBox

        .Flags = cdlCCFullOpen Or cdlCCHelpButton
        .ShowColor

        .Flags = cdlCFApply Or cdlCFBoth Or cdlCFEffects Or cdlCFHelpButton
        .ShowFont

        .HelpCommand = cdlHelpContents
        .HelpFile = Dir(Environ$("WINDIR") & "\Help\*.hlp")
        .ShowHelp

        .Flags = cdlOFNAllowMultiselect Or cdlOFNExplorer Or cdlOFNHelpButton
        .ShowOpen
        .ShowSave

        .Flags = cdlPDHelpButton Or cdlPDNoWarning
        .ShowPrinter
        .Flags = .Flags Or cdlPDPrintSetup
        .ShowPrinter
    End With
End Sub



---

Well, that's smaller than Ellis Dee's version and doesn't required the creation of types, private declarations, etc.

Yes, that's because it doesn't call the relevant APIs directly. Instead, it relies on comdlg32.ocx to do the heavy work, so that must be installed first. It was meant to be used in cases where having a Form to host the ActiveX control is unnecessary. That code may also be ported to VBScript with minimal modifications.

Except that the control is not licensed for general use in VBScript.

But... as far as I can tell from all of the licensing terms, as long as you have a license for Visual Basic 6.0 Pro or Enterprise you can build and redist an application you created using VBScript as long as you "add signficant functionality." You just can't hand out the OCX for anyone to use in their own scripts.

One example:

Quote:

---

Important

Your license agreement for Visual Basic states that in order to distribute any redistributables included with Visual Basic, the software you author must add significant and primary functionality. This means that a control that uses TreeView as a constituent control must do significantly more than TreeView does by itself. Consult your Microsoft License Agreement for details.

---

Note that the quote is talking about use in VB6, i.e. it is illegal to create a wrapper DLL/OCX in VB6 and give it away. There is a lot of illegal use of the MSComm control this way for example. As for use in VBScript (or Office VBA, etc.), consult additional license terms which seem to make that legal. Just my opinion though - be sure to check it yourself.


The catch is that you must use a script host that can deal with the design/runtime license requirements. As far as I can determine there isn't a way for a WSH script to do that. However using IE or MSHTA as the host you can create appropriate license packages using the LPK Tool utility and invoke them. This will work until the OCX has been kill-bitted by Microsoft as unsafe for IE anyway.

See Licensing ActiveX Controls.

One of those little "gotchas" people don't notice until they deploy to a system where VB6 isn't installed.


The example given will also bite you in the rear the same way in VB6 unless you have caused the license to be compiled into the program another way. If the control is present in some Form in the project you're ok. Otherwise you need to manually deal with the Licenses collection at runtime - see the VB6 documentation for details.

Thanks for the reminder! I guess that limits this code for personal use then. :)

I did try compiling it and there were no problems showing the dialogs. I also converted it to VBScript and everything ran fine, except for the Help, Open and Save dialogs. I tried to open the exe and vbs on another system where comdlg32.ocx isn't installed, and even after manually registering comdlg32.ocx, they still won't run, complaining about the licensing issues you described. So, I suppose it shouldn't be used in VBScript.

Try a small VB6 project like this with no Forms. Compile, PDW it (adding Comdlg32.ocx manually), deploy to a test system (VM, etc.) without VB6 installed. That ought to fail too.

Tried it. As written your example fails silently due to the OERN. Moving that line under the With CreateObject() line results in:

Quote:

---

Run-time error '429':

ActiveX component can't create object

---

Yeah, I've already tried something like that. I ran the exe on a Win 7 machine where comdlg32.ocx isn't installed and of course, I got the can't create object error. I tried manually registering comdlg32.ocx and though it was successful, I still received an error about a missing license or something like that.

However, on my development computer, both the exe and vbs run fine (albeit with a few issues). So, that code requires that comdlg32.ocx is properly installed. Although, I don't know if VB6 is required to be installed as well.

You can make it work in VB6, but not in legally-sharable source code!

You have to insert the run-time license key at run time within your program before trying to create an instance.

See Add Method (Licenses Collection)

It's a 2-step process. First run a small program to retrieve the license key String, then go into your real program and insert this String there. But don't publish that license String value here, it's a violation of your license agreement. Programmers need to do this for themselves.


This is why the entire process is a little bit shady. It is way too easy to "innocently" share source code and break your license agreement.

Quote:

---

Originally Posted by dilettante

This is why the entire process is a little bit shady. It is way too easy to "innocently" share source code and break your license agreement.

---

Now, I understand you can not share the ocx, dll, etc without breaking the license agreement since it is not yours but sharing the source code that you have created which uses said ocx, dll is a bit rough.

Quote:

---

Originally Posted by Nightwalker83

Now, I understand you can not share the ocx, dll, etc without breaking the license agreement since it is not yours but sharing the source code that you have created which uses said ocx, dll is a bit rough.

---

In this case working source code would have the license key embedded in it. You are not permitted to share that.


This entire thread is academic anyway.

There are several different versions of wrapper classes for the comdlg32.dll here in the CodeBank anyway. That solves both this licensing issue and the original "don't have a Form but want Common Dialogs" issue.

Well then, thanks for the license lessons, dilettante! I'll keep them in mind. :)


P.S.
I think I'll just have to make my own Common Dialogs ActiveX control to avoid licensing issues.