Built-in dialogs in VBA

[OughtFour]

I'm used to using

With Dialogs(wdDialogFileSaveAs)
If .Display = -1 then
[do stuff]
.Execute
End If

With this powerful feature, .Display shows the FileSaveAs dialog box and
suspends execution of the macro until the user okays or cancels the dialog.

This works fine in Windows Office 98. But in Office v. X (Mac OS X 10.2.6),
execution does not pause at .Display, which evaluates at -1 even though the
user has not acted.

This problem is intermittent--or rather, it seems to show itself whenever
the macro is either (a) a substitute for the FileSaveAs command or (b) is
called by a macro that is a substitute for a command.

In other words, if I call the macro "floogle" and run it, it works as it is
supposed to. If I call it "Main" (and put it in a project called
"FileSaveAs") and chose the Save As command form the File menu, it fails as
described above.

This behavior suggests that my code is okay, but that something more
fundamental isn't working right. Any ideas about what it could be?

I would be grateful for any information or suggestions.

 

[Jim Gordon]

Hi

I tried to duplicate the problem using Word 10.1.4, but was unable to get
the problem to reproduce.

Try adding this line to your code inside the WITH

msgbox "Display is " & .Display

It will tell you the value of the button that was clicked.
0 means the cancel button was clicked
1 means the save button was clicked

More information is in the VBA help file on the topic
"Display"

-Jim Gordon
Mac MVP

All responses should be made to this newsgroup within the same thread.
Thanks.

About Microsoft MVPs:
http://www.mvps.org/

Search for help with the free Google search Excel add-in:
<http://www.rondebruin.nl/Google.htm>

 

[OughtFour]

I tried to duplicate the problem using Word 10.1.4, but was unable to get
the problem to reproduce.

Jim, I am grateful for your reply.

The fact that you can't duplicate this makes me think I should resintall
Office from scratch.

But may I ask: Did you make your test macro a substitute for the FileSaveAs
command? Or did you just test it under another name? That is what seems to
make the difference for me. As I said,

Jim Gordon wrote,

Try adding this line to your code inside the WITH

msgbox "Display is " & .Display

It will tell you the value of the button that was clicked.
0 means the cancel button was clicked
1 means the save button was clicked

I believe it is -1 for Save--the positive numbers are reserved for other
dialog buttons (if any).

With that difference, I already did as you suggested. In fact it was on the
basis of such a test that I said

I should also have explained that the result of this is that the code
executes twice--once when it shouldn't (when execution should pause pending
user interaction with the dialog box) and the second time as expected based
on the user's actions.

I'm running the latest version of Office (10.1.5, though Word is only
10.1.4), but I have reason to think this problem predates the latest
upgrade.

Thanks again.

 

[Jim Gordon]

Here's the code I used:

Sub DoTheDialog()
With Dialogs(wdDialogFileSaveAs)
If .Display = -1 Then
MsgBox "Do Stuff"
End If
MsgBox "Display is " & .Display
End With
End Sub

Sub Test()
DoTheDialog
End Sub

I ran the sub called "Test" which runs "DoTheDialog." The dialog displayed
as expected and displayed the values for .Display as expected (zero or 1
depending upon whether Cancel or Save was clicked in the dialog).

-Jim Gordon
Mac MVP

All responses should be made to this newsgroup within the same thread.
Thanks.

About Microsoft MVPs:
http://www.mvps.org/

Search for help with the free Google search Excel add-in:
<http://www.rondebruin.nl/Google.htm>

----------

 

[J.E. McGimpsey]

I'm used to using

With Dialogs(wdDialogFileSaveAs)
If .Display = -1 then
[do stuff]
.Execute
End If

With this powerful feature, .Display shows the FileSaveAs dialog box and
suspends execution of the macro until the user okays or cancels the dialog.

This works fine in Windows Office 98. But in Office v. X (Mac OS X 10.2.6),
execution does not pause at .Display, which evaluates at -1 even though the
user has not acted.

This problem is intermittent--or rather, it seems to show itself whenever
the macro is either (a) a substitute for the FileSaveAs command or (b) is
called by a macro that is a substitute for a command.

In other words, if I call the macro "floogle" and run it, it works as it is
supposed to. If I call it "Main" (and put it in a project called
"FileSaveAs") and chose the Save As command form the File menu, it fails as
described above.

This behavior suggests that my code is okay, but that something more
fundamental isn't working right. Any ideas about what it could be?

I would be grateful for any information or suggestions.

Yes, this appears to be a bug. It has occurred for me when the
FileSaveAs dialog is called within a FileSaveAs macro or a FileSave
macro.

I've reported it to MacBU, but I haven't heard anything back yet.

See

http://google.com/groups?threadm=BB87C4EC.1E71B%[email protected]
soft.com

for one context in which it failed for me.

 

[OughtFour]

Here's the code I used:

Sub DoTheDialog()
With Dialogs(wdDialogFileSaveAs)
If .Display = -1 Then
MsgBox "Do Stuff"
End If
MsgBox "Display is " & .Display
End With
End Sub

Sub Test()
DoTheDialog
End Sub

Thanks, Jim.

As I said, the problem only manifests itself when the macro is a substitute
for the FileSaveAs command.

So I would expect (am at work right now, where I'm running Windows) your
code to run flawlessly on my mac as long as it was named DoTheDialog. As
mine does when I give it another name and do not call it from within
FileSaveAs.

If you want to try to see what I am seeing, rename your module FileSaveAs
and rename DoTheDialog as MAIN. Then choose Save As from the file menu, or
save a new document to disk.

I guess I'm going to have to think about workarounds. Maybe if I call it
xFileSaveAs and customize the appropriate keystrokes and menus.

Thanks again.

 

[OughtFour]

Yes, this appears to be a bug. It has occurred for me when the
FileSaveAs dialog is called within a FileSaveAs macro or a FileSave
macro.

I've reported it to MacBU, but I haven't heard anything back yet.

See

http://google.com/groups?threadm=BB87C4EC.1E71B%[email protected]
soft.com

for one context in which it failed for me.

Thanks J.E.

You probably figured this out, but--The reason why you got that "modal"
error message (which you described in the other thread) is that execution
continues while the dialog box is pending (i.e., word is in a modal state).

You can error handle for this and not get the message, but are still stuck
with the basic problem. The code in the If statement will execute twice when
you want it to execute once, and once when you don't want it to execute at
all.

If it is really a bug that MacBU is not going to fix, I guess it's time to
think about a workaround.

One might be able to get the desired behavior by giving the macro a
different name and using key and toolbar customization to substitute it for
FileSaveAs. (But, one would have to do the same thing for FileSave, I
guess.)

Or maybe a variable could track the number of times it executes the code:

xCount = 0
If .Display = -1 then
xCount = xCount + 1
If xCount = 2 then
[do code]
.Execute
end if
end if

or similarly how much time elapsed--assuming there would be at least a
tenth-of-a-second delay for the user to close the dialog box

vTime= Time()
vTimeIncrement = [whatever]
If .Display = -1 then
If vTime + vTimeIncrement < Time() Then
[do code]
.Execute
end if
end if

It's such a conspicuous failure of a genuinely useful feature--a shame if
they won't fix it!

Thanks again.

 

[Jim Gordon]

Hi again,

I didn't have time to test your suggestion. MacBU prioritizes fixes based
partly on user feedback. Please be sure to send a bug report using Word's
Help menu Feedback feature. Be sure to be specific and include your code
sample.

-Jim Gordon
Mac MVP

All responses should be made to this newsgroup within the same thread.
Thanks.

About Microsoft MVPs:
http://www.mvps.org/

Search for help with the free Google search Excel add-in:
<http://www.rondebruin.nl/Google.htm>

----------

Yes, this appears to be a bug. It has occurred for me when the
FileSaveAs dialog is called within a FileSaveAs macro or a FileSave
macro.

I've reported it to MacBU, but I haven't heard anything back yet.

See

http://google.com/groups?threadm=BB87C4EC.1E71B%[email protected]
soft.com

for one context in which it failed for me.

Thanks J.E.

You probably figured this out, but--The reason why you got that "modal"
error message (which you described in the other thread) is that execution
continues while the dialog box is pending (i.e., word is in a modal state).

You can error handle for this and not get the message, but are still stuck
with the basic problem. The code in the If statement will execute twice when
you want it to execute once, and once when you don't want it to execute at
all.

If it is really a bug that MacBU is not going to fix, I guess it's time to
think about a workaround.

One might be able to get the desired behavior by giving the macro a
different name and using key and toolbar customization to substitute it for
FileSaveAs. (But, one would have to do the same thing for FileSave, I
guess.)

Or maybe a variable could track the number of times it executes the code:

xCount = 0
If .Display = -1 then
xCount = xCount + 1
If xCount = 2 then
[do code]
.Execute
end if
end if

or similarly how much time elapsed--assuming there would be at least a
tenth-of-a-second delay for the user to close the dialog box

vTime= Time()
vTimeIncrement = [whatever]
If .Display = -1 then
If vTime + vTimeIncrement < Time() Then
[do code]
.Execute
end if
end if

It's such a conspicuous failure of a genuinely useful feature--a shame if
they won't fix it!

Thanks again.

 

[OughtFour]

Hi again,

I didn't have time to test your suggestion. MacBU prioritizes fixes based
partly on user feedback. Please be sure to send a bug report using Word's
Help menu Feedback feature. Be sure to be specific and include your code
sample.

Thanks, Jim.

I have done so. For what this is worth.

As a postscript: I haven't had much time for this and am still thinking
about a workaround. I think there will have to be a global variable that
tracks whether the code has run already. Reset to 0 when either .display = 0
or {dostuff] happens.