"This action will reset your project, proceed anyway?"

[Sebastian H]

I get the message

"This action will reset your project, proceed anyway?"

all the time, even when there is nothing to reset. There's no project running, and even if it did, the message pops up in situations that should have no impact on a running project anyway, such as changing capitalization of an identifier, or even just clicking in the code pane. This is really annoying; is there any way to get rid of these false alarms?

I should add that I use
[VBA]End[/VBA]
in my projects; I know that some people say that's bad style; but I sometimes just want to end a macro right away. Apparently, "End" doesn't really end the execution; is there a better way to simply stop a macro?

(Using Outlook 2003 on Win XP SP3.)

[gcomyn]

you could use

[vba]
Exit Sub
[/vba]
GComyn

[Sebastian H]

Thank you for your reply. I do use that when appropriate, but it has a different function.
Exit Sub only ends the sub, but does not end execution. Example:
[VBA]Sub Main()
Do
Do_something
If We_re_done Then Exit Do
Do_something_else
Loop
End Sub

Sub Do_something()
Do_it
If A_problem_occurred Then
Select Case MsgBox("A problem occurred. You probably should fix it in the spreadsheet.", vbAbortIgnore)
Case vbAbort
End
Case vbIgnore
Ignore
End Select
End If
End Sub
[/VBA]

This is just a simplification, there actually can be more than just two levels of subs involved. Of course, I could declare some variable to keep the information that the program wants to stop, and then pass it on from sub to calling sub until I reach Main, and then query that in We_re_done, and then stop, but why bother? There's nothing left to do for the program, so why can't it simply stop?

Anyway, I now don't think it has anything to do with the use of End. After I had posted this, I started getting the same in Excel, including cases in which the program had never run into End.

[Sebastian H]

It definitely has nothing to do with End. It just happened again, twice in a row. I hadn't even run anything before the second occurrence!

[gcomyn]

I'm not sure what the problem is, then...

about your example... with something like that, I'd have the Do_Something sub be a boolean function, then I could test it to see if it worked or not.

GComyn

[Sebastian H]

Maybe we should fork this conversation. (Is there a way to do that?) While I still would like to get rid of the annoying error message, I also find the topic of End interesting.

I know, changing subs into functions for passing exceptions has been fashionable among programmers for quite a while, but personally I don't find it so elegant because it treats the exception as the rule. Moreover, you can't consistently use that method: What if, instead of a sub, you already have a function? You could lump the exception return together with the regular return value, which is what Microsoft did for InputBox. But that's not good; in fact, it has caused much trouble already, which is why Steiner posted a workaround here.