[VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs

Win 10 Home 64. VB6 Pro SP6: That is perfect now thank you. TaskDialogINdirect, ITaskbar3, Dil's notify ctrl that pops out the Win 10 info bar. Who needs CodeJock!!!

Bless you mate - thank you.

Steve.

Hi Faf, some of the things you said above made me think. I now wonder if a Combobox would not be better than a Textbox. You still get the benefits of a Textbox but if you need to present a list then you get the advantages of a Combo. What do you think? Here is a picture of a form I created to dummy it up.

What do I think?

It must exist! Stand by. Will make it a ComboBoxEx with images too. At least one good point though is a lot of the code can be copied from the textbox.

Edit
So far so good...
http://i.imgur.com/FaEdTrK.jpg

Code:

---

himlSys = GetSystemImagelist(SHGFI_SMALLICON)
With TaskDialog1
    .Init
    .MainInstruction = "Duplicates"
    .Content = "If you want to exclude an Artists name from the search:" & vbCrLf & vbCrLf
    .Flags = TDF_VERIFICATION_FLAG_CHECKED Or TDF_COMBO_EDIT
    .AddCustomButton 100, "Continue"
    .CommonButtons = TDCBF_CANCEL_BUTTON
    .IconMain = TD_SHIELD_ICON
    .Title = "cTaskDialog Project"
    .ComboCueBanner = "Cue Banner Text"
    .ComboImageList = himlSys
    .ComboAddItem "Item 1", 2
    .ComboAddItem "Item 2", 3
    .ComboAddItem "Item 3", 4
    .VerifyText = "Exclude Jingles"
    .ParenthWnd = Me.hWnd
    .ShowDialog

---

I've even set things up so that you can have both a combo and a textbox, since there's 3 different positions...

http://i.imgur.com/lPKfQQy.jpg or http://i.imgur.com/hDTzXcz.jpg

I think I need to add some sizing options...

Was thinking... i *could* probably add autocomplete too... but it would have to support custom lists... so that would be a large expansion and a dependency for oleexp. Think I'll leave off the main class, but I am going to expose properties for the hWnd's, so it could be attached if someone wanted to go down that road.

====
And I just thought of another idea.. still OTHER controls- was thinking an option for a calendar control would be really useful in particular. With the way I re-did the code for the combo, adding new ones in the same position configurations is standardized now.. a lot of work, but set up so it's fairly modular; can drop a new control in by just adding the flag, slightly changed create routine, and an additional set of variables/properties.

Edit
Yeah totally adding a datetime option too.
http://i.imgur.com/j4xB6lU.jpg

Edit2
Going crazy now... and now up to 2500 lines after adding support for (date or time) AND date + time,
http://i.imgur.com/0ghOSt7.jpg

and of course it's set up like the combo, something that can be added on:
http://i.imgur.com/qVWvfcC.jpg

That looks great!! Here's the things I pick up in your screenshots (allowing for the fact this is just proof of concept).

The Combo dropdown needs to be width adjusted for long items. Code Below.
The control in the footer should be spaced away from the Icon, or, of course, we simply don't use the icon at this time.
Need to ensure the dialog doesn't bloat too much. I use this ALL the time now and, for a simple program, don't want it to increase the size of the program disproportionately.

Code:

---

Option Explicit
Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long

Private Sub AutoSizeDropDownWidth()
    Dim i As Integer, lTempWidth As Long, lWidth As Long
    Const CB_SETDROPPEDWIDTH = &H160
   
    If cboDialog.ListCount = 0 Then Exit Sub

    'Get the width of the largest item
    For i = 0 To cboDialog.ListCount - 1
        lTempWidth = cboDialog.Parent.TextWidth(cboDialog.List(i)) 'Ensure that form has the same font/size as combo
        If (lTempWidth > lWidth) Then lWidth = lTempWidth 'Store the longest length in lWidth
    Next
   
    lWidth = (lWidth \ Screen.TwipsPerPixelX) + 20 '+20 to allow for vertical scrollbar
 
    'don't allow drop-down width to exceed screen.width
    If lWidth > Screen.Width \ Screen.TwipsPerPixelX - 20 Then lWidth = Screen.Width \ Screen.TwipsPerPixelX - 20
    SendMessage cboDialog.hWnd, CB_SETDROPPEDWIDTH, lWidth, 0
End Sub

---

Many thanks - Yet again - Steve.

The size is really a concern? The difference between 1000 lines and 10000 lines is a few KB, probably smaller than a single icon. (also, this size is par for the course for common controls... e.g. krool's usercontrol for a simple TextBox is 1900 lines, and 6700 for a ListView... so even if I hit 3000 i'd hope you wouldn't avoid the class for that)

What I am doing is keeping the usage simple, and each thing that's added uses the same simple setup and config... nothing new effects anything old, so if you're not using something you won't be inconvenienced by it. And the way it's designed, very little additional code is actually executed if one of these new features isn't being used.

http://i.imgur.com/VGEHnky.jpg (edit: ok, I fixed the spacing. And a weird bug where if you used an edit control in the footer, but no footer icon, the bottom half would be cut off)

Code:

---

himlSys = GetSystemImagelist(SHGFI_SMALLICON)
Dim hIconF As Long
hIconF = IconToHICON(LoadResData("ICO_CLIP", "CUSTOM"), 16, 16)
With TaskDialog1
    .Init
    .MainInstruction = "Schedule Event"
    .Content = "Pick action to schedule. You can also set a name below." & vbCrLf & vbCrLf
    .Flags = TDF_DATETIME Or TDF_COMBO_LIST Or TDF_INPUT_BOX Or TDF_USE_HICON_FOOTER Or TDF_KILL_SHIELD_ICON
    .DateTimeType = dttDateTime
    .DateTimeAlign = TDIBA_Buttons
    .ComboSetInitialItem 0
    .ComboImageList = himlSys
    .ComboAddItem "Do One Thing", 3
    .ComboAddItem "Do Something Else", 4
    .ComboAddItem "Run and hide", 5
    .CommonButtons = TDCBF_OK_BUTTON Or TDCBF_CANCEL_BUTTON
    .InputText = "New Event 1"
    .InputAlign = TDIBA_Footer
    .Footer = "$input"
    .IconMain = TD_SHIELD_GRADIENT_ICON
    .IconFooter = hIconF
    .Title = "cTaskDialog Project"
    .ParenthWnd = Me.hWnd
    .ShowDialog

---

Edit:
I can do an autosize... but the combobox might not have the same font as the form, and TextWidth would create a dependecy ON a form. I'll have to use something like GetTextExtentPoint32.
Not sure if making it larger than the combo width is a good UI decision anyway tho.. and it can't be smaller. Might make it optional. Or since the hWnd is exposed the user could always do it themselves in the TaskDialog_Created event.

Quote:

---

Originally Posted by fafalone

The size is really a concern?

---

You're right of course, consider me chastised. :blush: Sadly I am of the age where when I started 'Lean & Mean' was the only to go and I guess it has stuck. Also there was no criticism of your coding style, as you say the Dialog is beautifully simple to use and an elegant addition to a program.

Have I missed where I can download this version from, or is it still being polished?

Still being polished... wanted to get everything done; the combos, the date/time, and the most complicated, combining a date picker and time picker as a single option; and making sure all the options work. Will update it later this afternoon or tonight.

Edit
If it's ok, things are complex enough as it is so I'm going to leave things like drop width to the user; it's a single line anyway:

Code:

---

Private Sub TaskDialog3_DialogCreated(ByVal hWnd As Long)
Call SendMessage(TaskDialog3.hWndCombo, CB_SETDROPPEDWIDTH, 900&, ByVal 0&)
End Sub

---

Edit2: Ugh, you're going to have to hold out until tomorrow. Ran into quite a few complications handling the date/time ranges and checkboxes, the latter due to a bug that took forever to run down.
And this other TRULY bizarre bug...
So the Init function resets all the variables to their initial state, and part of that was clearing all the text fields:

Code:

---

    m_sContent = ""
    .pszContent = StrPtr(m_sContent)
    m_sFooter = ""
    .pszFooter = StrPtr(m_sFooter)

---

etc etc for every field...
Well, the TDF_KILL_SHIELD_ICON flag was causing a crash, but only when .Init was called (even if it was still new and hadn't been used yet), and I traced it down to another standard text clear:

Code:

---

    m_sExpandedInfo = ""
    .pszExpandedInformation = 0 'StrPtr(m_sExpandedInfo)

---

That variable is declared just like all the others, nothing had been assigned to it previously, yet for some reason this caused the dialog to appear as a tiny box no bigger than an icon, with an 'X' that led to a crash or no X and having to ctrl-alt-delete. For the life of me I can't figure out WHY, weirdest bug I've ever seen. Took hours to figure out that line was the cause. Setting it to 0 instead of StrPtr fixed the problem.

So yeah anyway, just minor bug fixes and final touchups now, but the screen shots and documentation posts are a major effort. Just too tired tonight. It's all working now though, so let the hype build!

After this release I'm planning some good things for 1.0. Going to add those dropdown buttons I was working on, and since that needs subclassing anyway that can then be used to create events for the new controls, like ComboItemChange, InputBoxChange, etc. Then I'm also going to add more controls... definitely a Slider and picture, will see what else.

This is not life or death, so take your time and get it exactly as you want it. We both know it's gonna be awesome!

Steve.

Will be worth the wait...
Check it, snuck one more new thing in for this release...
Now not only can you entirely kill the icon for the shield gradients like post #65, you can replace it with a resource icon id from your app, or set TDF_USE_SHELL32|IMAGERES_ICONID and use one from those (or a custom module you load yourself with LoadLibrary and set to .hInst):
http://i.imgur.com/odFwXEq.jpg

Considering how much stuff there is on that dialog, it still manages to look neat and tidy!!! :)

Ehh I couldn't resist doing it now... holding off on the major subclassing thing, but did want to add sliders:
http://i.imgur.com/F6V43k4.jpg

It's a good thing I did too, because I didn't notice until I had to adjust it's coords, but there was a massive lack of proper alignment when the expando control came into play... I had only handled 1 scenario, there were about a dozen more to make sure things are always positioned correct (you can see this issue starting in the current release; if the inputbox is in the footer position, the position doesn't adjust, and if it's the expand into footer area style, it's in the entirely wrong position, from the get-go when expanded by default is on). There went 7 hours.

Get some sleep man!!!

Task dialog, with non editable combobox (TDF_COMBO_LIST) or editable (TDF_COMBO_LIST Or TDF_INPUT_BOX) styles, would be superb.

and then you should package it into a nice DLL or OCX. :)

Just to update everyone, I ran into a large number of alignment issues. I really want the new controls to work with the existing options as much as possible, and that means individually lining up every control to each scenario of standard options.

Things like:
-Controls placed in the main area are counted by the backend API towards the dialog height, but not the button positions. So it creates a blank area at the bottom when the expando control resizes the dialog. So the dialog has to be manually adjusted on top of control alignment.
-Expando + verify checkbox alters alignment
-Radio buttons alter alignment slightly differently than command links
-Expando controls resizing things effect the alignments in all sorts of unpredicted ways (like not eliminating whitespace originally only existing because of adding two vbCrLf's, even after those are removed and the element updated). There's the principle alignment for each control combined with each native control (and more than one native control for the content area), and the alignment in response to expando controls altering the content or footer area.
-Some are minor adjustments; some are major and require adjustments beyond just changing x,y; like adding and removing line breaks to create whitespace, each in a different way for each of a dozen option scenarios.

So as the pictures indicate, the basic work is done, but I'd rather spend a bit more time getting everything to play together nicely than further restrict how the new controls can be used in combination with the existing control options.. It's not hard to do this; just time consuming. Still coming soon; just want to get it right.

Edit:
@Tech99, yes both are available... the TDF_COMBO_BOX flag adds a combo control, and the type is determine by a .ComboStyle property to choose either dropdown list or edit list.

@DEXWERX, really?? a DLL or OCX instead of a class module?? I guess I could provide that option but what's the advantage good enough to be worth the loss of easy customization? All it requires right now is a single class module and a couple callback headers that can go in any standard module.

Edit 2: The major alignment adjustment process has been completed. Now just putting finishing things off and making demos. It took a while, but the good news is that you can use any combination of existing controls (command links, radio buttons, progress bar, expando button, and verify checkbox) and the new controls; I think I've covered every scenario...
Config InputBox Combo Date DateTime Slider
Content-Standard OK OK OK OK OK
Content-CommandLink OK OK OK OK OK
Content-Radio OK OK OK OK OK
Content-CmdLnk+Radio OK OK OK OK OK
Content-Expando-Std OK OK OK OK OK
Content-Expando-CmdLnk OK OK OK OK OK
Content-Expando-Radio OK OK OK OK OK
Content-Expando-CmdLnk+Radio OK OK OK OK OK
Content-ExpandoDef-ALL 4 OK OK OK OK OK
Content-ExpandoTF-ALL 4 OK OK OK OK OK
Content-Verify-Std OK OK OK OK OK
Content-Verify-CommandLink OK OK OK OK OK
Content-Verify-Radio OK OK OK OK OK
Content-Verify-CmdLnk+Radio OK OK OK OK OK
Content-Exp+Ver-Std OK OK OK OK OK
Content-Exp+Ver-CommandLink OK OK OK OK OK
Content-Exp+Ver-Radio OK OK OK OK OK
Content-Exp+Ver-CmdLnk+Radio OK OK OK OK OK
Content-Progress-Std OK OK OK OK OK
Content-Progress-CmdLnk+Radio OK OK OK OK OK
Content-Progress-Expando (ALL) OK OK OK OK OK
(C-E-V w/Default) OK OK OK OK OK
(C-E-V w/Expand to Footer) OK OK OK OK OK
Content-No Content Text (ALL) OK OK OK OK OK
Content-No Main Instr (ALL) OK OK OK OK OK
--------------------
Button-Std OK OK OK OK OK
--------------------
Footer-Std OK OK OK OK OK
Footer-Verify OK OK OK OK OK
Footer-Expando-Std OK OK OK OK OK
Footer-Expando+Verify OK OK OK OK OK
Footer-Expando-ToFooter OK OK OK OK OK
Footer-Expando+Verify-ToFooter OK OK OK OK OK
(adjusting and testing every one of those is what took so long)

Update: cTaskDialog 0.8

After the success of the Input Box in 0.7, version 0.8 of cTaskDialog adds even more useful controls added by custom flag. There's now 4 types of controls:
TDF_INPUT_BOX The textbox from 0.7
TDF_COMBO_BOX A combo box that can either be an editable one or a dropdown list. It's a ComboBoxEx (ImageCombo), so it accepts an imagelist in the form of an HIMAGELIST.
TDF_DATETIME Shows a datetime control; either a single one for date or time, or two controls for date AND time.
TDF_SLIDER A standard slider control with detailed options for the range and ticks.

Following in the tradition of the existing control options, you can add one of each of these (up to 3) in the same 3 areas where the inputbox could be placed: in the main content area, next to the buttons (replaces the expando and/or verify controls if placed here), or as the footer (the footer icon shows and is properly aligned, but old footer text is covered). Thanks to some painstaking calculations and testing, all these controls are additional options: you can use any number and combination of the built-in controls along with the new custom ones, including the expando control, and a space for them is automatically created. The creation and usage of the new controls follows the exact same easy format of the rest of the class.

Here's some selected samples; the attached project contains many additional ones showing the different options.

Code: himlSys = GetSystemImagelist(SHGFI_SMALLICON) 'any image list will do; make your own with ImageList_Create or IImageList With TaskDialog3     .Init     .MainInstruction = "Duplicates"     .Content = "If you want to exclude an Artists name from the search:"     .Flags = TDF_VERIFICATION_FLAG_CHECKED Or TDF_COMBO_BOX     .AddCustomButton 100, "Continue"     .CommonButtons = TDCBF_CANCEL_BUTTON     .IconMain = TD_SHIELD_ICON     .Title = "cTaskDialog Project"     .ComboCueBanner = "Cue Banner Text"     .ComboSetInitialState "", 5 '    .ComboSetInitialItem 1     .ComboImageList = himlSys     .ComboAddItem "Item 1", 6     .ComboAddItem "Item 2", 7     .ComboAddItem "Item 3", 8     .VerifyText = "Exclude Jingles"     .ParenthWnd = Me.hWnd     .ShowDialog     Label3.Caption = "Checked? " & .ResultVerify     Label7.Caption = .ResultComboText     Label9.Caption = .ResultComboIndex     If .ResultMain = 100 Then         Label1.Caption = "Continue!"     Else         Label1.Caption = "Cancelled."     End If End With	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
Here we add pre-selected users to our password demo. The partial code below shows how dual custom controls are used: Code:     .Flags = TDF_INPUT_BOX Or TDF_COMBO_BOX     .ComboStyle = cbtDropdownList     .InputIsPassword = True     .InputAlign = TDIBA_Buttons     .CommonButtons = TDCBF_OK_BUTTON Or TDCBF_CANCEL_BUTTON     .SetButtonElevated TD_OK, 1     .SetButtonHold TD_OK     .ComboAlign = TDIBA_Content     .ComboSetInitialItem 0     .ComboImageList = himlSys     .ComboAddItem "User 1", 6     .ComboAddItem "User 2", 7     .ComboAddItem "User 3", 8     .Footer = "Enter your password then press OK to continue."     .IconFooter = TD_INFORMATION_ICON     .IconMain = TD_SHIELD_ERROR_ICON	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
The most basic Date control. This can also be a time control. Code:     .Init     .MainInstruction = "Hello World"     .Content = "Pick a day, any day" & vbCrLf & vbCrLf     .Flags = TDF_DATETIME     .CommonButtons = TDCBF_OK_BUTTON Or TDCBF_CANCEL_BUTTON     .IconMain = TD_INFORMATION_ICON     .Title = "cTaskDialog Project"     .ParenthWnd = Me.hWnd     .ShowDialog     Label11.Caption = .ResultDateTime	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
Many common options are supported. This example shows combining the new controls with the built-in ones, and setting a limited range in the date and time controls. When the two controls are used, both the chosen date and time are represented by .ResultDateTime. Code: Dim dTimeMin As Date, dTimeMax As Date dTimeMin = DateSerial(Year(Now), Month(Now), Day(Now)) + TimeSerial(13, 0, 0) dTimeMax = DateAdd("d", 7, dTimeMin) dTimeMax = DateAdd("h", 4, dTimeMax) With TaskDialog1     .Init     .MainInstruction = "Date Ranges"     .Content = "Pick a time, limited to sometime in the next 7 days, between 1pm and 6pm" & vbCrLf & vbCrLf     .Flags = TDF_DATETIME Or TDF_USE_COMMAND_LINKS     .DateTimeType = dttDateTime     .DateTimeAlign = TDIBA_Content     .DateTimeSetRange True, True, dTimeMin, dTimeMax     .DateTimeSetInitial dTimeMin     .AddCustomButton 101, "Set Date" & vbLf & "Apply this date and time to whatever it is you're doing."     .CommonButtons = TDCBF_CANCEL_BUTTON     .IconMain = TD_INFORMATION_ICON     .Title = "cTaskDialog Project"     .ParenthWnd = Me.hWnd     .ShowDialog     Label11.Caption = .ResultDateTime	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
Here's a highly customized slider combined with showing the auto-positioning that allows the expando control to be used, even with built-in controls further upping the complexity. Code:     .Init     .MainInstruction = "Sliding on down"     .Content = "Pick a number"     .Flags = TDF_SLIDER Or TDF_USE_COMMAND_LINKS     .SliderSetRange 0, 100, 10     .SliderSetChangeValues 10, 20     .SliderTickStyle = SldTickStyleBoth     .SliderValue = 50     .SliderAlign = TDIBA_Content     .ExpandedControlText = "ExpandMe"     .ExpandedInfo = "Expanded"     .AddCustomButton 100, "CommandLink"     .CommonButtons = TDCBF_OK_BUTTON Or TDCBF_CANCEL_BUTTON     .IconMain = TD_INFORMATION_ICON	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
Finally, here's an example of using 3 of the new controls together in combination with two of the built-in controls, as well as the option to replace the shield icon with one from shell32.dll, while maintaining the gradient background. Code: himlSys = GetSystemImagelist(SHGFI_SMALLICON) Dim hIconF As Long hIconF = IconToHICON(LoadResData("ICO_CLIP", "CUSTOM"), 16, 16) With TaskDialog1     .Init     .MainInstruction = "Schedule Event"     .Content = "Pick action to schedule. Provide a date, and optionally a specific time. You can also set a name below."     .Flags = TDF_DATETIME Or TDF_INPUT_BOX Or TDF_COMBO_BOX Or TDF_USE_HICON_FOOTER Or TDF_USE_SHELL32_ICONID Or TDF_KILL_SHIELD_ICON Or TDF_USE_COMMAND_LINKS     .DateTimeType = dttDateTimeWithCheckTimeOnly     .DateTimeAlign = TDIBA_Buttons     .ComboAlign = TDIBA_Content     .ComboStyle = cbtDropdownList     .ComboSetInitialItem 1     .ComboImageList = himlSys     .ComboAddItem "Do Thing #1", 2     .ComboAddItem "Do Thing #2", 7     .ComboAddItem "Do Thing #3", 8     .CommonButtons = TDCBF_CANCEL_BUTTON     .InputText = "New Event 1"     .InputAlign = TDIBA_Footer     .IconMain = TD_SHIELD_GRADIENT_ICON     .IconFooter = hIconF     .IconReplaceGradient = 276     .Title = "cTaskDialog Project"     .ParenthWnd = Me.hWnd     .AddCustomButton 102, "Schedule" & vbLf & "Additional information here."     .AddRadioButton 110, "Apply to this account only."     .AddRadioButton 111, "Apply to all accounts."     .ShowDialog     Label2.Caption = "Radio: " & .ResultRad     Label5.Caption = .ResultInput     Label7.Caption = .ResultComboText     Label9.Caption = .ResultComboIndex     Label11.Caption = .ResultDateTime     If .ResultDateTimeChecked = 0 Then         Label13.Caption = "Time unchecked."     Else         Label13.Caption = "Time checked."     End If     If .ResultMain = 102 Then         Label1.Caption = "Scheduled."     Else         Label1.Caption = "Cancelled."     End If End With	http://www.vbforums.com/images/ieimages/2014/09/1.jpg

---

Full update notes from the .cls:

Code:

---

'NEW IN VERSION 0.8
'--Added ability to use comboxes (normal edit dropdown and dropdown list), date/time pickers,
'  and sliders like the inputbox controls.
'--There's still the 3 alignment positions from the inputbox, so you can have controls in each
'  of these places (however, only 1 of each type is allowed)
'--When TDF_KILL_SHIELD_ICON is used, there's now an option to replace it with a different icon:
'  Set .IconReplaceGradient...
'    1) To an ID in your app's resource file (only works when compiled)
'    2) Add the TDF_USE_SHELL32_ICONID or TDF_USE_IMAGERES_ICONID flag and use an ID from those
'    3) Set .hInst to a custom module and use an icon ID from that
'  Using an hIcon is not supported at this time.
'--Bug fix: Using TDF_KILL_SHIELD_ICON and calling .Init crashed the app
'--Bug fix: Using an InputBox at the footer position, the bottom half was cut off if no
'          footer icon was set.
'--Bug fix: Input box position adjusted for expando only if in the content position, now adjusts
'          if in footer position too. Prevented this bug in all other controls.
'--Bug fix: If input box was in footer position, and expanded info was expanded automatically
'          and into the footer area, the input box would be in the wrong position. Fixed and
'          prevented for new controls.
'KNOWN ISSUE: If the slider control is placed in the footer position and an expando control is
'            set to expand into the footer area, the transparent background on the slider is
'            lost (turns white) until it's clicked. It's a very unusual and specific situation,
'            so not going to delay this version while I come up with a fix.
'TODO:
'The next version will be 1.0. There's a couple major features planned, including images and more
'events (for the custom controls). Maybe more controls; like dropdown menus on the buttons.
'I'm very aware this class needs substantial cleanup, that's also being saved for 1.0
' So please go easy on the sloppiness!!! :)

---

Excellent work from the UK! Much more than the doctor ordered.

Tiny problem, if you push the expando button you see some strange resizing going on. (Win 10 any way).

Steve.

Yeah the expando button changes the built-in control positions and the size of the dialog, so the custom controls have to be moved too and the API doesn't do it on its own. The API actually counts the custom controls when calculating the dialog height, but forgets about it when the buttons are arranged. So the result was an incorrectly sized dialog with a giant blank space; so I resize to the correct dimensions. The reason for the delay is that it does some weird fading thing... if you don't delay the resize/reposition on a timer, the APIs that get the RECT's return the original value, and you need the new value to correctly position everything; and figuring it out in advance would be a huge undertaking: figuring out not only the RECT size based on the font and text length, with line breaks and everything, but also MS's word-wrapping and dialog-sizing algorithms.

I'm open to better solutions. There might be a way in the next version where the whole thing is going to be subclassed; but for now things have to be resized and repositioned like they are. The only alternatives are giant blank spots and/or things winding up on top of eachother; so it's that or simply disable the custom controls when the expando button is present.. the awkwardness seemed better.

Edit

Coming Soon To A Dialog Near You....
http://i.imgur.com/D2L7wnK.jpg
+Split button and logo image...

http://i.imgur.com/7osIvFm.jpghttp://i.imgur.com/PTeiH2u.jpg
+Logo can also be placed top right... Edit: Got transparency working (to the background color).
+InputBoxes, ComboBoxes, and Sliders aligned next to the buttons scale in width to take up the available area (automatically adjusted based on furthest-left button)
+The footer position is still fixed by default, but if you specify a width of -1 it will scale
+InputBox/Combo/Slider have an added option to manually specify a fixed width
+Focus placed on the control in the content area (or button area then footer if none) so the inputbox isn't automatically focused if it's a secondary control

Edit2
http://i.imgur.com/WrMTpNH.jpg
+New alignment options fix widths in dialogs with no main icon, and footer right-align option (in addition to left and center) allow footer text to be shown too.

Thansk fafalone.

Tested this 0.8 version briefly.

Taskdialog created with...

Code:

---

TaskDialog1
    .Init
    .ParenthWnd = frmMain.hWnd
    .MainInstruction = "Testing"
    .Content = "Does this work."
    .IconMain = IDI_QUESTION
    .Title = App.EXEName  '"cTaskDialog Project"
    .flags = TDF_USE_COMMAND_LINKS 'TDF_USE_COMMAND_LINKS_NO_ICON
'etc...

---

do not work, error (TaskDialogIndirect ret=0x80070715) returns when IDI_QUESTION icon is defined. Version 0.6 did work, with IDI_QUESTION icon.

Yeah there's been an issue with the IDI_QUESTION and IDI_APPLICATION icons...

In order to display Icon resources from your compiled project's resource file, or from Shell32.dll or Imageres.dll, the hInstance must be set to App.hInstance or the handle of those DLLs. Changing to the class doing App.hInstance by default is what broke the IDI_'s.

So if you want to use IDI_QUESTION or IDI_APPLICATION, add .hInst = 0 - but note you won't be able to use an icon from your .res file, shell32, or imageres in the other spot (header and footer).

If you want to permanently change the default, change uTDC.hInstance in Class_Initialize and Init to 0. On the whole I thought displaying resource icons was more important to have as the default, although I'm definitely open to feedback: The two possible scenarios are
A) You can use an icon from your .res Icon resources just by using it's number, but then must set .hInst = 0 if you want to use IDI_ (0.8), or
B) You can use IDI_, but then must set .hInst = App.hInstance if you want to use a .res file Icon index (0.6)
So is (B) better?

PS- As suggested by the above, if the TDF_USE_SHELL32_ICONID or TDF_USE_IMAGERES_ICONID flags are set, you can't use IDI_ e.g. use a shell32 index for the main icon and IDI_QUESTION for the footer

I have tested this class on Win8.1, great work!

But this class will not work well when Windows display DPI rate is not 100%, say, 150%(Win10 Default for some new type ThinkPad laptops) or 200%(Microsoft Surface).

Some pixel size of extra elements(text/combo/datetime) are hard coded, say, always use 22 for TextBox height. I tried to modify some code, but It's really not a easy work to just adjust by 15/screen.TwipsPerPixelx, on 150% DPI, it will get 33 and that's too much for a single line TextBox.

My suggestion is to make some adjustment on element size and position for high DPI monitor.

Pardon for my bad English.~~

Thanks!

Yeah unfortunately a lot of stuff in VB6 isn't suited to high-DPI, and I don't have a high-DPI monitor myself to work with it. Will look into it.. I'm sure there's an article somewhere about to size controls correctly according to DPI. (but if you're using 150% DPI and have twips per pixel=15, that's the same as my standard dpi monitor)

Dear fafalone:

you can easily set high dpi on your current monitor, in fact all my daily work is done on a regular 1440*900 monitor, but to test vb6 programs on high dpi monitor,just set Control Panel\Appearance and Personalization\Display to 150% and set vb6.exe compatible properites to DPI awareness.

Attachment 145181
Attachment 145183
Attachment 145185

[QUOTE=fafalone;5141057]Yeah unfortunately a lot of stuff in VB6 isn't suited to high

Thanks fafalone, setting .hInst = 0 sorted problem.

On the whole (usage scenarios), i would wote B, as it (IMHO) would be more logical.

Ok so if I'm understanding MSDN's intro to DPI correctly, I should adjust x,y and cx,cy like
scaledX = GetDeviceCaps(GetDC(0), LOGPIXELSX) * originalX / 96
right?


Edit2: Well after playing around with what values got scaled, I've got everything looking correct except X is just a little too far, but not so much it's unacceptable. The biggest issue I'm worried about is everything says you're supposed to divide but I'm multiplying everything.

http://i.imgur.com/gyu8hNX.jpg

The X being so slightly off and the multiplying is making me very worried this isn't the correct way and is going to not look right on other DPI settings and resolutions.
What I'm doing to get the dialog above is cx*scale, cy*scale, but calculations for x,y only multiply the offsets by the scale and not the other things like the button positions.. e.g. lButtonY3 - (44 * m_ScaleY)

Edit: Yeah it's definitely wrong. If I scale the offset for the footer position the same exact way, it goes too far down.
Frankly I have no clue what to do since the official method doesn't work and I'm not at all familiar with this area.

Dim twipsX As Double
twipsX = 1440 / GetDeviceCaps(hdcPrimaryMonitor, LOGPIXELSX)

that will get 96 on 100% dpi, or 120 on 125% dpi.

so scale rate is 120/96, same as 1.25

also you can try 15/screen.twipsPerpixelX(Y)m but that's not always accurate if windows DPI rate is NOT 125%, 150%.

On 200% DPI, screen.twipsPerpixelX(Y) is 7 (since it's an Integer value), but Actually it's 7.5. that will cause a lot of problems on ActiveX controls. only a few ActiveX Control have fix on this problem, an example of this can be found in this forum: http://www.vbforums.com/showthread.p...mmon-controls), Common.DPICorrectionFactor function

Example: a textbox on vb6 form with 20*100 pixel based client rect will automatically resized to 25*125 on dpi 125%

Do what with 1440 / gdc? Can't multiply or divide by it...

The x-offset on 100% scaling is 52 pixels. Manually aligning on 150% scaling got 69 pixels. That's a scale factor of 1.323.

And 1440 / GetDeviceCaps(hdcPrimaryMonitor, LOGPIXELSX) returns 10 on 150% on my computer, so I don't know where that's coming from.

But I'm starting to think the problem is the task dialog size isn't a simple scale; something much more complex seems to be going on behind the scenes- given that control width/height is scaled appropriately.
So I went back and contemplated what was effecting the layout calculations the API was making behind the scenes, and struck upon an interesting hypothesis: the adjustment is caused exclusively by the icon. So instead of 52 * m_ScaleX, I instead set the offset to (32 * m_ScaleX) + 20... 32 being the unscaled width of the icon, and it WORKED! Perfect alignment. Footer left adjusted from 32 to (16 * m_ScaleX) + 16 also worked perfectly. There's quite a bit more work to confirm, test, and adjust things, but it looks promising as it reconciles quite a few issues.
It's going to be a nightmare to adjust Y-values on this principle though, because if the theory holds I have to figure out what part of the offset is the button height and adjust based on that, at least for the footer position where the button height would matter.

Edit: Y looks promising too. I got a button height of 23 unscaled, and instead of buttontop+(40*scale), buttontop + (23 * scale) + 17 put it 1 pixel off from the correct spot.

Edit2: I've got it down now. I've identified what does and does not need to be multiplied by the DPI scale factor for every aspect of alignment and sizing. Just need to revise all the other custom controls now. Version 1.0 will definitely be DPI sensitive. Thanks for pointing this out.

Edit3: Things are looking good.
If anyone is interested in testing things out while I'm doing final testing, I'm attaching a beta version of the big 1.0 release. This is really just a test version; there's a lot of commented debug code and notations, the samples are rearranged for testing with lots of extra lines to turn on and off, and there's a bunch of extra buttons for testing things.. aka not ready for public release- but I know I love getting beta versions of cool stuff, so thought I'd share since it's feature-complete and SHOULD be working 100% on normal DPI, and hopefully on other DPIs. It includes the dropdown buttons and logo images too.

(attachment removed; full version released)

cTaskDialog 1.0

It's been a long road to this 1.0 release. I started off with a barebones implementation of Task Dialogs nearly 3 years ago, then a full implementation of TaskDialogIndirect. From there the customizations began. Now this class is extensively enhanced, turning the already excellent Task Dialog API into a powerhouse of customization without sacrificing ease of use.

While only adding 3 major features, dropdown buttons, logo images, and auto-close, 1.0 brings huge changes behind the scenes:

Code:

---

'NEW IN VERSION 1.0
'--You can now make a custom button into a Split Button (dropdown arrow). Use .SetSplitButton
'  with the ID of the custom button. This fires a DropdownButtonClicked event. Cannot be used
'  with Command Links. Note there's one more function prototype in mTaskDialogHelper you'll
'  need to copy if you're placing those in your own module (they've been condensed too so the
'  whole thing is only 3 lines now).
'--A logo type image can now be placed with .SetLogoImage. The current placement options are
'  the top right corner, or next to the buttons (only if no controls, either custom or the
'  expando/verify are present). The image is passed as an HBITMAP or HICON, so you can load
'  in whichever way you want. No copy is made, so you must destroy the image yourself, but
'  only after the dialog closes (or it will not appear).
'--Autoclose has been implemented. Set the .AutocloseTime property to a value in seconds; when
'  you get the property, it returns the current time remaining.
'--Events for custom controls: ComboItemChanged, ComboDropdown, InputBoxChange, DateTimeChange
'--Custom controls now have the option to manually set their width (and height for combo).
'--Custom controls in the Buttons position now have their width adjusted to fill the space.
'  Custom controls in the Footer position still use a standard size, however for InputBox,
'  ComboBox, and Slider if you specify a width of -1 the width will scale to the full width
'--For custom controls in the footer area, and the datetime control in the content area, there's
'  an additional alignment option to choose between left, center, and right. In the footer area
'  this could be used to show footer text and have the control off to the right.
'--Focus is no longer always on an InputBox: Focus is set on whatever custom control is in the
'  content area, if none button area, last footer area. Or, there's now a .DefaultCustomControl
'  option to manually specify which one, or not have focus set on any of them.
'--Bug fix: Several fixes relating to alignment and events for custom controls used on dialogs
'          that are loaded as a new page (NavigatePage/TDN_NAVIGATED)
'--Bug fix: .DefaultButton used TDBUTTONS instead of TDRESULT enum to identify IDs
'--Bug fix: .DefaultRadioButton was incorrectly associated with the TDBUTTONS enum
'--Alignment: -Adjusted Content area custom controls slightly higher when expanded
'              info is used.
'            -Custom controls in content area now have an appropriate X-position and width when
'              no icon appears, shifting everything to the left.
'            -Made sure that content text actually had a link before making the link adjustment,
'              since the flag would still be used if there's a link only in the footer area.
'            -When there's a link but no command links or radio buttons, content area controls
'              needed to be adjusted upwards a bit.
'--Alignment: -Custom controls size and position is now automatically adjust for the current DPI.
'            -You can also specify a scale factor manually with the DPIScaleX/DPIScaleY properties.
'KNOWN ISSUES: -If there's a custom control in the content area, when an expando control is expanded
'              and then collapsed, the excess whitespace isn't removed despite there not being any
'              extra vbCrLf's to account for it. No way to correct this has been discovered yet.
'              -If the dialog has to be resized in response to an expando control, the width is
'              reduced by several pixels for an unknown reason- but only on the first time. If the
'              numbers returned by getting the client RECT were wrong, you'd expect to lose more
'              pixels every time, but that's not the case. No solution has been discovered.
'              -Some alignment scenarios remain unsupported. If expando with the expand-footer w/
'              expand-default, have text with multiple lines, alignment will be off. This remains
'              a significant challenge to address as the DirectUIHWND reports incorrect information
'              to GetPixel, so figuring out where things are will require font height analysis and
'              reverse engineering line break length determination. Will work on in next version.
'              -Sliders with ticks on top and bottom simply don't fit on higher DPIs in the footer
'              position. Height available is too small no matter how it's positioned.

---

---

On to examples, first up is the very simple auto-close.

When creating the dialog, you specify an auto-close time in seconds. When you retrieve the property while the dialog is active, it returns the time remaining, allowing you to do things like tie it into a progress bar of doom: Code: With TaskDialogAC     .Init     .MainInstruction = "Do you wish to do somethingsomesuch?"     .Flags = TDF_CALLBACK_TIMER Or TDF_USE_COMMAND_LINKS Or TDF_SHOW_PROGRESS_BAR     .Content = "Execute it then, otherwise I'm gonna peace out."     .AddCustomButton 101, "Let's Go!" & vbLf & "Really, let's go."     .CommonButtons = TDCBF_CLOSE_BUTTON     .IconMain = IDI_QUESTION     .IconFooter = TD_ERROR_ICON     .Footer = "Closing in 15 seconds..."     .Title = "cTaskDialog Project"     .AutocloseTime = 15 'seconds     .ParenthWnd = Me.hwnd     .ShowDialog End With 'Then: Private Sub TaskDialogAC_DialogCreated(ByVal hwnd As Long) TaskDialogAC.ProgressSetRange 0, 15 TaskDialogAC.ProgressSetState ePBST_ERROR End Sub Private Sub TaskDialogAC_Timer(ByVal TimerValue As Long) On Error Resume Next TaskDialogAC.Footer = "Closing in " & TaskDialogAC.AutocloseTime & " seconds..." TaskDialogAC.ProgressSetValue 15 - TaskDialogAC.AutocloseTime On Error GoTo 0 End Sub When a dialog times out, it returns a TD_CANCEL main result (it also does this if you hit 'x').	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
Next up, logo images. Now, there's a very wide variety of image processing techniques. Rather than accept a file name and limit things to one method, the class module must simple be passed an HBITMAP, which you can acquire in a multitude of ways. The demo project uses GDI+, so a generic set of standard images is supported. The logo image can go in two places, in the buttons position (means no controls, custom or built-in, can be placed there): Code: 'some initializing settings from the picture are omitted     Dim hBmp As Long     Dim sImg As String     sImg = App.Path & "\vbf.jpg"     Dim cx As Long, cy As Long     hBmp = hBitmapFromFile(sImg, cx, cy) With TaskDialog1     .Init     '[...]     .SetLogoImage hBmp, LogoBitmap, LogoButtons     .ShowDialog End With Call DeleteObject(hBmp) 'do not free image until the dialog is closed, otherwise it won't show.	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
Two more features of the logos are support for transparency, and support for custom offsets from the edges. Transparency, due to the way TaskDialogs work with that infernal DirectUIHWND, require some processing... the background color isn't correctly reported so it's transparent to the wrong color. This is resolved by custom-setting the background it's transparent to to the current RBG of the actual visible pixels. If we always just used the standard window background, it wouldn't work with the shield gradients. Don't worry, it's all handled for you. Just set the alignment and desired offsets: Code:     .SetLogoImage hBmp, LogoBitmap, LogoTopRight, 4, 4 (as suggested by 'LogoBitmap', there's also 'LogoIcon' that you need to use for .ico's)	http://www.vbforums.com/images/ieimages/2014/09/1.jpg
Finally we get to drop down buttons. It's a pretty rare thing to require, but once subclassing had to be brought in for a host of other uses, why not add it? Note that the demo project prints a debug message when the dropdown arrow is clicked, I didn't include the large amount of code to then generate a menu at that spot. If you need help with doing that, let me know in this thread or by PM, as I do have that code written. At this time, it's only possible to make a split button out of a custom button; which has to be a normal button-- so command links aren't supported. Turning a button into a split button is done by ID (and only 1 button can be made into a split one at this time): Code:     .AddCustomButton 123, " SuperButton  "     .SetSplitButton 123 Note the extra space padding-- this is required for the button to look right. I'll look into automating the addition of spaces in the future but for now it's gotta be manually done. Icons work but aren't perfect: http://www.vbforums.com/images/ieimages/2014/09/1.jpg You might want to consider customizing the icon by having some blank pixels on the left.	http://www.vbforums.com/images/ieimages/2014/09/1.jpg

---

A final major feature, that took by far the longest to implement, was making the dialog play nice with different DPIs. It was a significant challenge that took quite a few hours, but I believe I have made the position and size calculations correct for arbitrary high-DPI. I've done quite a bit of testing at 125% and 150% DPI, and everything is looking good. You don't need to do anything to handle this, the class detects DPI and adjusts automatically. However, there is an option to manually set the scaling factor that is used (or see the one currently in use by the class): DPIScaleX and DPIScaleY.
It's calculated currently as follows:

Code:

---

hDC = GetDC(0&)
m_ScaleX = GetDeviceCaps(hDC, LOGPIXELSX) / 96
m_ScaleY = GetDeviceCaps(hDC, LOGPIXELSY) / 96

---

---

As always, please report any bugs you encounter or features you'd like to see. Enjoy :wave:

**Plans for new features**

I'm going to continuously update this post with new features as I add them for the next version.

The first new feature is extending the left/right/center alignment options for custom controls. This combined with fixed width means that the block on multiple controls in the same place will be removed since if you're careful it's possible to have multiples like this:

http://i.imgur.com/tnzxUX4.jpghttp://i.imgur.com/0cSiudJ.jpg

In the first image, the date/time has a right-align set, and the textbox has a center-align set.
In the second image, the input textbox uses a fixed-width, which can be DPI sensitive by .InputWidth = 140 * .DPIScaleX. I'm also going to add a manual offset option.

Hi, Fafalone, I encountered the following two questions when I tested your TaskDialog on Win10:

1. When I click any of the buttons on the main window, the following prompt appears:

2. When I compile the project, the following prompt appears:

For 1: Your project, and the IDE if running from there, needs to be manifested for Common Controls 6.0..

Quote:

---

Before using cTaskDialog

The TaskDialog was introduced with version 6.0 of the common controls, with Windows Vista. That means a manifest is required for your compiled application, and for VB6.exe in order to use it from the IDE. In addition, your project must start from Sub Main() and initialize the common controls before any forms are loaded. The sample project includes Sub Main(), and see LaVolpe's Manifest Creator to create the manifests.

---

The linked thread also covers manifesting the IDE.

For 2:
You can delete that whole function.
Sorry about that, it's just test code for a future version I was playing around with. The download has been updated with the whole thing commented out too.

Ok, I'll try again, thank you very much.

Typo: Event DialogConstucted -> DialogConstructed

Well that's embarrassing, that typo has survived since the very first release :blush:

It'll be fixed in the next major release; not going to push it as a 'can't wait' issue. Thanks for pointing it out.

can this be used in office vba?

I don't see why not.

Quote:

---

Originally Posted by fafalone

I don't see why not.

---

seems need manifests as well as in vb6 ide?

Good point; I just checked and VBA does support the 6.0 API, so it *can* be called, no manifest needed, but like everything else it has to be converted to VBA's PtrSafe garbage where Long is different from LongPtr.
I did a test calling the simple API, which shows it works:

Code:

---

Private Declare PtrSafe Function TaskDialog Lib "comctl32.dll" _
                                                    (ByVal hwndParent As Long, _
                                                    ByVal hInstance As Long, _
                                                    ByVal pszWindowTitle As LongPtr, _
                                                    ByVal pszMainInstruction As LongPtr, _
                                                    ByVal pszContent As LongPtr, _
                                                    ByVal dwCommonButtons As Long, _
                                                    ByVal pszIcon As Long, _
                                                    pnButton As Long) As Long


Private Sub CommandButton1_Click()
  Dim dwIcon As Long
  Dim pnButton As Long
  Dim Success As Long
    Dim sTitle As String
    Dim sMainText As String
    Dim sMessage As String
    sMainText = "test"
    sMessage = "msg"
   
Dim pszTitle As LongPtr
Dim pszMain As LongPtr
Dim pszContent As LongPtr

If sTitle = "" Then
    sTitle = "titlist"
End If
pszTitle = StrPtr(sTitle)
If sMainText <> "" Then pszMain = StrPtr(sMainText)
If sMessage <> "" Then pszContent = StrPtr(sMessage)
Dim dwIco As Long
dwIco = -1
If dwIco Then
  dwIcon = tdMakeIntResource(dwIco)
End If
  Call TaskDialog(hWndOwner, _
                        hinst, _
                        pszTitle, _
                        pszMain, _
                        pszContent, _
                        1, _
                        dwIcon, _
                        pnButton)

   
End Sub
Private Function tdMakeIntResource(ByVal dwVal As Long) As Long
  tdMakeIntResource = &HFFFF& And dwVal
End Function

---

So given the extensive use of pointers in the class, even if you used the older version before my customizations, it would still be quite the time consumer to convert, but the API can indeed be called.

But it seems in my VBA IDE mode, it still shows "cannot find entrypoint taskdialog balabala"
office 2010x86 win7x64

I tried ur demo on #99

Perhaps it could be only 64bit VBA supports comctl32. I know it's not the versions that are the problem; I'm also using Office 2010 on Win7x64, except I've got 64bit office.

You could also try providing a manifest for the office exe. Check if it has one (if you don't know how I can explain), if not provide it...
I looked at my 64-bit Excel 2010 executable, and it has this manifest:

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <noInherit/>
        <assemblyIdentity version="14.0.4756.1000" processorArchitecture="AMD64" name="excel" type="win32"/>
        <description>Microsoft Excel</description>
        <dependency optional="yes">
                <dependentAssembly>
                        <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.1.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>
                </dependentAssembly>
        </dependency>
</assembly>

---

So that's why it works for 64-bit, but I don't have a copy of 32-bit Office2010 handy to see if it does the same thing.

how can i check the res file of my Excel.exe, which is just the same version of urs except mine is 32bits

I checked with Resource Hacker... open excel.exe and check if there's a 'Manifest' category (the category name might be '24' in other resource editors).

Yes the 'Manifest' here it is.
why can't i use it...

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <noInherit/>
        <assemblyIdentity version="14.0.4756.1000" processorArchitecture="X86" name="excel" type="win32"/>
        <description>Microsoft Excel</description>
        <dependency optional="yes">
                <dependentAssembly>
                        <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.1.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>
                </dependentAssembly>
        </dependency>
</assembly>

---

So I went searching on Google and ran across this: https://gist.github.com/kumatti1/1714700

It declares TaskDialog like this:

Code:

---

Declare Function TaskDialog& Lib "C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll" (ByVal hWndParent&, ByVal hInstance&, ByVal pszWindowTitle&, ByVal pszMainInstruction&, ByVal pszContent&, ByVal dwCommonButtons&, ByVal pszIcon&, ByVal pnButton&)

---

See how it's pointing to an x86 sxs reference instead of just the DLL? Try using that declare (or just that code).

(I'm not familiar with how all that works; but I'm guessing a similar path should exist if that one doesn't?)

this seems good, wonderful...

Quote:

---

Originally Posted by fafalone

So that's why it works for 64-bit, but I don't have a copy of 32-bit Office2010 handy to see if it does the same thing.

---

32-bit Excel 2010 has this manifest (file excel.exe.manifest), at installation folder, typically in C:\Program Files (x86)\Microsoft Office\Office14

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><noInherit></noInherit><assemblyIdentity version="11.0.0.0" processorArchitecture="*" name="excel" type="win32"></assemblyIdentity><description>Microsoft Excel</description><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.30729.1" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity></dependentAssembly></dependency><trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security><requestedPrivileges><requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel></requestedPrivileges></security></trustInfo><compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
                <application>
                       
                        <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"></supportedOS>
                </application>
        </compatibility><asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
                <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
                        <dpiAware>true</dpiAware>
                </asmv3:windowsSettings>
        </asmv3:application></assembly>

---

That one doesn't mention comctl 6... could the 'prefer external manifest' setting have been flipped on? Or Tech99 does your excel.exe not also have an internal manifest?

Do you guys think there's really enough demand that I should re-write the class for VBA? The newer versions with all the customizations aren't going to happen (wayyy too much work) but I'm considering v0.6- the version that implemented all the built-in functionality. Just curious if there's a good number of people interested in something like that.

Quote:

---

Originally Posted by fafalone

That one doesn't mention comctl 6... could the 'prefer external manifest' setting have been flipped on? Or Tech99 does your excel.exe not also have an internal manifest?

Do you guys think there's really enough demand that I should re-write the class for VBA? The newer versions with all the customizations aren't going to happen (wayyy too much work) but I'm considering v0.6- the version that implemented all the built-in functionality. Just curious if there's a good number of people interested in something like that.

---

Sorry for the fuss, yes there is an internal manifest.

I think IMHO that there is not much of a need, to make an VBA version of your class. Demand might not be worth of re-write it.

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<noInherit/>
<assemblyIdentity version="14.0.7170.5000" processorArchitecture="X86" name="excel" type="win32"/>
<description>Microsoft Excel</description>
<dependency optional="yes">
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.1.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
</assembly>

---

can we change excel.exe.manifest to use normal declare of comctl32.dll?

Quote:

---

Originally Posted by loquat

can we change excel.exe.manifest to use normal declare of comctl32.dll?

---

What you mean by normal declare? Sure you can generate/modify common control v6 manifest to suit your application.

See the MSDN article.
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

what i mean can we change excel.exe.manifest to use this declare in vba

Code:

---

Private Declare Function TaskDialog Lib "comctl32.dll" _
                                                    (ByVal hwndParent As Long, _
                                                    ByVal hInstance As Long, _
                                                    ByVal pszWindowTitle As Long, _
                                                    ByVal pszMainInstruction As Long, _
                                                    ByVal pszContent As Long, _
                                                    ByVal dwCommonButtons As Long, _
                                                    ByVal pszIcon As Long, _
                                                    pnButton As Long) As Long

---

but no need to use comctl32.dll in winsxs folder like this

Code:

---

Declare Function TaskDialog& Lib "C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll" (ByVal hWndParent&, ByVal hInstance&, ByVal pszWindowTitle&, ByVal pszMainInstruction&, ByVal pszContent&, ByVal dwCommonButtons&, ByVal pszIcon&, ByVal pnButton&)

---

by the way, in my winsxs folder there are 3 version of comctl32.dll up to version 6.0.7601.17514
they are 6.0.7601.18837, 6.0.7601.23039 and 6.0.7601.23403

can we call the comctl32.dll api without declare it just like
paul caton do
http://www.planetsourcecode.com/vb/s...70195&lngWId=1
or Lavolpe do
http://www.vbforums.com/showthread.php?781595

Quote:

---

Originally Posted by LaVolpe

...P.S. this horizontal scrolling is annoying; maybe it's just my browser

---

The "poll" on the right side is gone :D that's why you have to scroll...When the new poll coming you'll see better again.

Quote:

---

Originally Posted by loquat

what i mean can we change excel.exe.manifest to use this declare in vba

Code:

---

Private Declare Function TaskDialog Lib "comctl32.dll" _
                                                    (ByVal hwndParent As Long, _
                                                    ByVal hInstance As Long, _
                                                    ByVal pszWindowTitle As Long, _
                                                    ByVal pszMainInstruction As Long, _
                                                    ByVal pszContent As Long, _
                                                    ByVal dwCommonButtons As Long, _
                                                    ByVal pszIcon As Long, _
                                                    pnButton As Long) As Long

---

but no need to use comctl32.dll in winsxs folder like this

Code:

---

Declare Function TaskDialog& Lib "C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll" (ByVal hWndParent&, ByVal hInstance&, ByVal pszWindowTitle&, ByVal pszMainInstruction&, ByVal pszContent&, ByVal dwCommonButtons&, ByVal pszIcon&, ByVal pnButton&)

---

---

Sure you can declare library directly, pointing to 32-bit DLL, but nowadays it is better to use PtrSafe type declaration - which is compatible 32 and 64 bit office versions.

https://msdn.microsoft.com/en-us/lib...ffice.14).aspx

Quote:

---

To resolve this, VBA now contains a true pointer data type: LongPtr. This new data type enables you to write the original Declare statement correctly as:

VBA

Code:

---

Declare PtrSafe Function RegOpenKeyA Lib "advapire32.dll" (ByVal hKey as LongPtr, ByVal lpSubKey As String, phkResult As LongPtr) As Long

---

This data type and the new PtrSafe attribute enable you to use this Declare statement on either 32-bit or 64-bit systems. The PtrSafe attribute indicates to the VBA compiler that the Declare statement is targeted for the 64-bit version of Office 2010. Without this attribute, using the Declare statement in a 64-bit system will result in a compile-time error. Note that the PtrSafe attribute is optional on the 32-bit version of Office 2010. This enables existing Declare statements to work as they always have.

The following table provides more information on the new qualifier and data type already discussed as well as another data type, two conversion operators, and three functions.

---

can we make a dynamic call of TaskDialog api in comctl32.dll, so that we need no manifest?
this maybe a solution of the problem need manifest in ide mode such as office vba

I found that copy C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll to any folder is will be good
such as "c:\comctl32.dll"
then this will be ok in ide mode, vb6ide as well as office vba

Code:

---

Private Declare Function TaskDialog Lib "c:\comctl32.dll" _
                                                    (ByVal hwndParent As Long, _
                                                    ByVal hInstance As Long, _
                                                    ByVal pszWindowTitle As Long, _
                                                    ByVal pszMainInstruction As Long, _
                                                    ByVal pszContent As Long, _
                                                    ByVal dwCommonButtons As Long, _
                                                    ByVal pszIcon As Long, _
                                                    pnButton As Long) As Long
'WINCOMMCTRLAPI HRESULT WINAPI TaskDialogIndirect(const TASKDIALOGCONFIG *pTaskConfig, __out_opt int *pnButton, __out_opt int *pnRadioButton, __out_opt BOOL *pfVerificationFlagChecked);
Private Declare Function TaskDialogIndirect Lib "c:\comctl32.dll" _
                                                    (pTaskConfig As TASKDIALOGCONFIG, _
                                                    pnButton As Long, _
                                                    pnRadioButton As Long, _
                                                    pfVerificationFlagChecked As Long) As Long

---

found a problem within "Misc - Auto-close"
if i set the AutoCloseTime to 20 seconds, it seems that the former 5 seconds shows no progress
.Footer = "Closing in 20 seconds..."
.Title = "cTaskDialog Project"
.AutoCloseTime = 20 'seconds
and if i set the AutoCloseTime to 5 seconds, the 1st seconds will show progress to 10/15 of the progressbar


how to use the progressbar just like vb6 progressbar control

To do the progress bar in the demo, I had hard coded the range...

Code:

---

Private Sub TaskDialogAC_DialogCreated(ByVal hwnd As Long)
TaskDialogAC.ProgressSetRange 0, 15
TaskDialogAC.ProgressSetState ePBST_ERROR
End Sub

Private Sub TaskDialogAC_Timer(ByVal TimerValue As Long)
On Error Resume Next
TaskDialogAC.Footer = "Closing in " & TaskDialogAC.AutocloseTime & " seconds..."
TaskDialogAC.ProgressSetValue 15 - TaskDialogAC.AutocloseTime
On Error GoTo 0
End Sub

---

The 15 is those functions represents the 15 seconds in the demo dialog, so it would instead be 20 or 5.
You'll likely want to set up a module-level variable with your time and use that instead....

Code:

---

Private lTimeLimit As Long

Private Sub TaskDialogAC_DialogCreated(ByVal hwnd As Long)
TaskDialogAC.ProgressSetRange 0, lTimeLimit
TaskDialogAC.ProgressSetState ePBST_ERROR
End Sub

Private Sub TaskDialogAC_Timer(ByVal TimerValue As Long)
On Error Resume Next
TaskDialogAC.Footer = "Closing in " & TaskDialogAC.AutocloseTime & " seconds..."
TaskDialogAC.ProgressSetValue lTimeLimit - TaskDialogAC.AutocloseTime
On Error GoTo 0
End Sub

'[...]
lTimeLimit = 20
.Footer = "Closing in " & lTimeLimit & " seconds..."
.Title = "cTaskDialog Project"
.AutoCloseTime = lTimeLimit
'[...]

---

It's controlled manually like that in general, there's no automatic progressbar for autoclose, just the normal one that's synced to the time as it counts down; it's got all the features of a standard progress bar... see the end of post #2 in this thread for an example and documentation of all the calls.