- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
Hi @kwilson_design. Most of the time, when we use MsgBox or MessageBox.Show, we do not expect to get anything back from them. However, those are both Functions, which means that they are designed to 'Return' something to the routine that called them to run. Both return a slightly different Type of value. The MsgBox Function returns a MsgBoxResult Type value. The MessageBox.Show Function returns a DialogResult Type value. Both types of values represent a different 'Enum'. So, when you want to use one of those to ask a question, where you need to check the result of that question, then you need to have a variable to record the result of the Function to. The Type of that variable will depend on which of those two Functions you are using. Then, to check which value you received from that question, you check the variable that the Function set the value of. When a variable represents an Enum, you usually need to know the name of that Enum (such as MsgBoxResult or DialogResult), because you always start with that name, then type the dot (.) after it, then Intellisense (pop-up helper suggestions) will show you the list of possible values of that Enum, so you can choose one of them. However, if you did not 'declare the Type' of that variable, then the Intellisense system will not know what to suggest, and will not be able to help you. Sometimes these Enum's have a numerical value associated with each variation they contain. When this is the case, you can just specify that numerical value, instead of the name of the Enum and its variation name. However, that is harder to read later, unless you include comments about which variation that number represents.
When asking a question about whether a code should proceed past that point in a code, always handle the 'NO' answer first, instead of the 'YES' answer. That way, if they say No, you can just exit the rule (or current code routine) at that point, and you do not need to handle the 'YES' answer. If they did not say NO, then do not react at all...just let the rest of the code continue as usual. No need for a super long If...ElseIf...End If statement with tons of code between them, where it is easy to loose your place. There is also the possibility that the user clicked the small 'X' in the corner of the dialog, instead of clicking either the 'Yes' or 'No' buttons. If that is possible, and it is important for you to handle that, then you can check for both 'NO' or 'Cancel' and similar values at the same time. So, if they canceled the dialog, or answered No, then stop this whole process right now. If neither, then let the rest of the code playout...with no check for Yes value.
When you look at my example in Message 3 above, you will notice that I am both 'declaring' (using Dim), and specifying the Type of the variable called "oAns", within the If...Then...End If statement, and I am also checking the value of that variable within that same If...Then...End If statement. Then you will notice that I am only checking if the value was 'NO'. I could have also used an 'Or' operator there to check for 'No' or 'Cancel'. The only value I care about is if the user does not want to proceed (answers No), then I want to end that code routine right there. To end the code routine right there, I am using the 'Exit Sub' keywords. That will only work if used within a Sub routine, not if used within a Function. I could have also used 'Return' there, instead of 'Exit Sub'. If it was within a Function routine, I could have also used 'Exit Function' there. However, 'Return' works in both a Sub or a Function. It is just more natural to use a 'Return' from within a Function than a Sub routine, because a Sub routine does not return anything, and a Function does...usually. I do not bother checking if they answered Yes, because that would require putting the whole rest of my code between that point and the 'End If' keywords, which is not necessary, if I do not check for Yes.
PS. That is not 'my' blog post. That is Curtis Waguespack's blog.
Wesley Crihfield
(Not an Autodesk Employee)