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.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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)
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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.
[QUOTE=fafalone;5141057]Yeah unfortunately a lot of stuff in VB6 isn't suited to high
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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.
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.
Last edited by fafalone; Feb 22nd, 2017 at 01:57 AM.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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%
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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)
Last edited by fafalone; Mar 1st, 2017 at 08:39 PM.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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').
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.
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:
(as suggested by 'LogoBitmap', there's also 'LogoIcon' that you need to use for .ico's)
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):
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:
You might want to consider customizing the icon by having some blank pixels on the left.
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:
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
**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:
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.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
For 1: Your project, and the IDE if running from there, needs to be manifested for Common Controls 6.0..
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.
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.
Last edited by fafalone; Mar 24th, 2017 at 10:48 PM.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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.
Last edited by fafalone; Aug 21st, 2017 at 07:09 PM.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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:
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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).
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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
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
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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
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.
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.
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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
Re: [VB6] TaskDialogIndirect - Complete class implementation of Vista+ Task Dialogs
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.
Last edited by fafalone; Sep 11th, 2017 at 11:02 PM.
Reply With Quote
Originally Posted by fafalone
that's why you have to scroll...When the new poll coming you'll see better again.
