Ok, lets layout the "pattern" we have to deal with.
The challenge (or called it the "nasty") here is that when one introduces the async code, it will bite you becasue the calling routine NOW also has to deal with this problem. And REALLY nasty is this can force a bubble up of the problem to more then one level deep of sub calls you make. So, that REALLY is a challenge here.
But, lets take the basic pattern here. You have:
Sub Button3_Click
Dim MyResult As Boolean
MyResult = DoStuff2
Log(MyResult)
End Sub
Sub DoStuff2 As Boolean
Msgbox("First message")
Return False
End Sub
So, ok, we change that msgbox in the DoStuff2 async, and we have to return a value.
The "nasty" is we NOW also have to modify the caller.
And golly - just exactly how much code you have (or want) to change, JUST because of that silly "async" problem!
And worse, the routine you using to call that code? You BETTER hope that it is not being called from another routine!
So you have basic example posted. And of course WHEN doing this, who wants to go an fix a WHOLE BUNCH of existing code you had working for years?
In other words, you don't want to re-think, and have to write (much) new code WHEN doing this change over.
It is not too bad. If you follow the "pattern" outlined, then it not too much code change, and MORE imporant, you don't have to much CHANGE the logic or thinking in your code. (you want to minmizine that re-writing, else you create new logic bugs - and that we REALLY want to avoid).
Once you get a "base" working pattern, you can quite much apply to the existing routines - and the changes should be minmial.
So we do this:
Sub Button2_Click
Dim MyResult As Boolean
DoStuff
Wait For (DoStuff) Complete (MyResult As Boolean)
Log(MyResult)
End Sub
Sub DoStuff As ResumableSub
MsgboxAsync("First message","First")
Wait For Msgbox_Result (Result As Int)
Return True
......
End Sub
So just keep in mind:
You introduce the async msgbox, then you ALSO have to change/fix/update the caller routine.
With the above pattern/approach, then this issue is no too much change, and you don't rock the boat so to speak.
You JUST have to toss into this soup bowel that the CALLERS have to be changed.
So, change your code as above. The CALLER(S) need to be changed also (the wait for).
So, make (add) the async mesage box(s). Put the wait for after the msg box.
Then CHECK how many routines are calling WHAT you just changed.
You can hover your cursor over the sub name - then choose "find reference". You VERY much want to do this quick check. And if there is say 2, or 5 places that call the routine you just changed? You go and change the caller code in those 5 places. You often don't have to change the code, but if the sub is "returning" values like your case - then you have to change as per above. So, when you add the async boxes, do that find references as your last step - you NEED to check (look for) all the OTHER places in code that call/use that routine you JUST changed.
eg like this:
So in above, there is 2 places in code that I should check - and might have to change.
So, this is not too hard, but the "nasty" is when you make/add/change those msgbox(s) to async, then you have to check the CALLERS to that routine, and update those callers. As noted, in a lot of cases if you not return values - you are ok. But, no real way of avoiding this change for routines that return values AND you introduce async msgbox.
It always "sad" when you have to go start chopping up perfectly running code. But the above steps are not too bad. Get a test/working sample. Try it a few times, make sure it works. Then you get that cup of coffee, and try this on your production code. Do one routine first, check the "list" of callers. Try it.
If it works, then move on to the next routine that had some halting msgboxs.
I find that even for a relative large application, the change over is not bad. You NOT re-writing code, you NOT really changing the existing code base logic wise.
So the whole job, the whole task is more of a "refactoring" type of work - it a change, but not a difficult brain power one, since 99% of your existing code and logic can remain un-touched.
As noted, if the routine is called from some button etc., and it not returning values - just add the async msgbox. And in some cases you find this works REALLY nice, since in some cases you find that you don't need nor care or want the code to have waited anyway!
In other words? in some cases, you can pop up msgbox, but the code keeps on running and will finish up! Those are nice and fun, since then after they hit ok to dismiss the message, the code following the msgbox will have already completed!
But, to not break existing code flow? Don't worry about the above last cool pony magic trick!
Follow the above noted pattern. It is easy because you doing the SAME thing over and over to fix the code.
it will not take much time to change over your application.
But make no mistake - in those cases that you return values - you have to go and find ALL CALLERS throughout your WHOLE code base that calls that one routine. And since one is returning a value, then all of those callers need the wait for "Complete" with the "Result as "typevar" stub. This is a "nasty" and there is no way out of this task. But it is the "same" change over and over - it not a lot of brain power - but you do have to make this change.
Regards,
Albert D. Kallal
Edmonton, Alberta Canada