Warning! This explanation simplified for the faint-of-heart


>"Form1.doCheckMark(byVal asdfasdf as String)"<

While the name of the control (in this case "Form1") will certainly be easily found because it's actual text, the attributes, events and procedures won't. For example, "doCheckmark" does not appear in the exe in any way related to Form1; rather, a pointer to the address of that procedure will appear; that pointer will be what is related to Form1. Since that address is the only relationship between the control and the procedure, you would usually use the address as the name of the procedure; that way, any reference to the address indicates a reference to the procedure. Later, you can rename the procedure (and any calls to it) to something that makes sense, if you can detrmine what that something is. For example, after examining the above procedure, you realize that it relates to CheckMark. So, you could call it anything form "CheckMarkActivated" to "EnableChkMrk" to <whatever>, as long as it is consistant and helps you realize what the code does.

As for the "(byVal asdfasdf as String)", all variables are pushed onto the stack before usage by a call. So, the only way to determine that a variable is even used it to check for a Push of some kind before the prodecure call. But, you'll never know the name ("asdfasdf"), only the stack pointer position. Like the procedure address above, the stack pointer then becomes the name, which you can also later rename, of course. Then, you can examine the procedure to see how the variable is used (in this case, "byVal") . You can determine the type ("String") by looking at what the pushed value is pointing to, assuming it's a pointer and NOT a value.

This process is loosely called Heuristic Processing (HPP = Hueristic Post Processing). Rather than being a step-by-step process of analysis, you look at the whole picture to determine what the intent is, THEN you go back and look at the details to see how they are used to support that intent.

Sarge