PDA

View Full Version : Error Handling when Displaying Dialogs



TonyJollans
05-29-2004, 10:43 AM
As we're short of questions, thought I'd throw this in :) ...

I'm playing with someone else's problem, and probably trying to be a little too clever, and I can't get my error trapping to work properly. I'm going to be out most of next week so there's no urgency here; I just wondered what was happening and whether there's a way round it.

If I go to Print a Document (Ctrl-p or whatever), and give some erroneous input (enter "abc" in the Pages: textbox, for example) I get an error message popup - "This is not a valid print range" - and am then returned to the Dialog to correct it. All as you would expect.

Now, if I try and drive this from code ..


With Application.Dialogs(wdDialogFilePrint)
.Display
End With



.. the Print Dialog is displayed. This time, if I enter "abc" in the Pages: textbox and press "OK", the dialog is refreshed with the invalid text blocked, but no error message popup. So I know what's wrong and I correct it, and press "OK" again. Control now returns to my code with an Error 5141 (This is not a valid print range) and the .Pages value is empty - it has neither the invalid "abc" nor the corrected "1". I have the error number and know what WAS wrong (if not the complete cause of it) so can tell the User, BUT the User has already corrected the problem and I do not have details of the correction so must ask them to supply the correct input again. No amount of error trapping makes any difference - control does not return to the code until there is no longer an error but it reports the error there was before correction.

Of course, as usual, I'm probably missing the blindingly obvious so what do I do to resolve it?

fumei
06-01-2004, 01:36 PM
Vegatables such as chocolate are not good for diabetics....sigh.

More sigh re: your post. Darn darn darn. That is a weird one, and has been driving me crazy for the last two hours. Got to get back to real work. That is very very weird. I can't error handle it either, I mean other than simply clearing the ErrObject. I don't understand why it does not go right to the run-time error message. It does not make sense to allow the user (me!) to fix the problem...then still give me the damn message. Weird.

it is enough to make me go eat chocolate...i.e. kill myself. Just kidding.

jamescol
06-01-2004, 03:20 PM
I know this post does not address your issue, but I though it might be beneficial.

You may want to review the following MS article:

322710 HOW TO: Raise and Control Print Dialog Boxes from Visual Basic

It discusses a download to replace the Visual Basic CommonDialog control with a dll that provides access to more Print dialog properties.

James

TonyJollans
06-09-2004, 03:56 AM
James, thanks for the link. Interesting but, as you say, does not address the issue.

Gerry, glad it's not just me! If I find any further info I'll post it here; otherwise I guess this just stays open as it isn't solved :dunno

mark007
06-09-2004, 04:40 AM
Hmm, this is very odd.

the solution appears to be to trap the error when it eventually appears and give the message box:

"if you'd filled it in right in the first place you wouldn't have got asked again!"

:)

mark007
06-09-2004, 04:47 AM
On another note I'm a big fan of never using built in dialogs like this where possible due to the lack of control. However in searching for a solution to this I came across this article which lists all the properties of all the dialogs in word - definatley a keeper!

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbawd10/html/wohowDisplayBuiltInDialogs.asp

:)

TonyJollans
06-09-2004, 04:08 PM
That list is also in the Help files.

As for using the Dialog or not - it's a case of swings and roundabouts; the built-in validation is a plus - in this case I guess it wouldn't be too hard to replicate with regular expressions, but in general it could be a lot of effort just re-inventing the wheel; the User interface leaving, as it does, a bit to be desired, is a minus.

mark007
06-10-2004, 03:24 AM
Ah, the help files. I get so used to not having them available at work that I always check the net first nowadays!

:)

TonyJollans
06-10-2004, 04:41 AM
Isn't it strange the way so many system administrators seem determined to stop their Users taking advantage of the many powerful and useful facilities built into software? This is not a new phenomenon (I have been dealing with it since before the first PC) but it is a persistent one.;)

I must admit I do use the net an awful lot these days - the biggest disadvantage is that I find what I want and then discover it isn't in my not-latest version of the software.

mark007
06-10-2004, 05:15 AM
Yep it's ridiculous. I can never understand the theory behind paying for office on everyone's PC but then only partly installing it so half the features aren't available....a complete waste of money!

Steiner
06-10-2004, 10:52 PM
It's surely about security reasons. If the user does not know how to use VBA, then maybe he is a lesser security threat (at least that is exactly the reason they told my father at work about that problem !!).

The point that people could use the internet (sometimes even from the same computer), well, that's the responsibility of someone else I guess.

fumei
06-14-2004, 01:24 PM
Hi folks. I'll just add my piece. I had a rant with management, because they refused to add Help. Like....what the bleep bleep?
Yet they are having me teach an advanced Word/beginning VBA course.

Now that microsquish has actually improved Help enough to be worthwhile....oh, well. I going to have every student formally submit a request to have Help installed.

Anyway, Tony - I am still stuck on this little thing. It seems so strange to me. I am afraid that it is going to have to be shrugged off as one of those things. One of those things that appears to be simply, like "Water For Chocolate". That is, unless you have solved this.