[JMI]

Pompeyfan:

Another piece of good advice (besides that ball bouncing in off the corner post) is that you get in the practice of keeping notes of the process "as you go." This gives you two advantages. Taking the time to make notes tends to make one more careful, instead of just crashing along, and it gives you something to check against when you have a problem like you are experiencing.

I believe you will find that if YOU write out the steps you understand you should be taking and write down the results of what happens when you take those steps, you will become somewhat more methodical and careful and can cross check your results with what you were expecting, without totally trusting to tired eyes and sleep deprived brain.

One additional advantage of proceeding by this method, is that the next time you are working with the same protection and it takes a strange turn, you will be aware it has happed differently than in the past and have a new path down which to wander.

Sometimes it is benificial just to take a step back and look at the code and try to figure out what the hell it appears to be trying to do. You know it is moving stuff around and getting and placing things in various places, but the more you come to UNDERSTAND what the code is ACTUALLY doing, the better chance you have to work your way through the dark codewoods. This is real learning. Then you will not only be following the path, you will be reading the trail markers. That's when it becomes really fun and you actually begin to search for that something different, which signals that a new varient has arrived on the scene. Then you are not following someone else's trail, but blazing your own.

If you are only trying to "follow" someone else's path (as from a tut) without actually trying to understand what the code is doing, you eventually will miss a step when the trail forks just when a cloud passed in front of the moon and you don't see the side trail.

Regards,