>George,
>
>The question here is simple: how can you terminate the inner loop, if user pressed ESC? I believe these two constructs are equal, so both are not permitted in your code:
>
>

>for i=1 to m.lnCount
>   if somecondition
>        exit
>   endif
>   .......
>next

>
>or
>
>

>for i=1 to m.lnCount
>   if somecondition
>        i=m.lnCount+1 && automatically closed the loop ?
>   endif
>   .......
>next

>
>or
>

>i=0
>do while not somecondition or i<=lnCount
>   i=i+1
>   .....
>enddo

>
>Or can you suggest something more clever? Which kind of solution would you choose? Remember, you're doing loop inside of loop inside of loop...
>
>Thanks a lot in advance.

The last one, of course. What follows is the evaluation I wrote up:

Nadya,

I’ve gone through a reviewed your code. The following is how I’d handle the situation. I’m not going to provide you with the code, but rather the principles that I’d apply in solving this problem and also to point some small things out to you.

First, the escape handler needs to take care of the business of saving the current settings in its Init method and restoring them in its Destroy. This removes the burden of your having to do this repeatedly.

Second, in examining the code, I found it much too “busy”. To me it lacks functional cohesion simply because of the number of things it tries to do. There are at least two, and in my view, probably four opportunities to further factor problem down into smaller modules.

To be specific, the first thing that struck me was that you have three iteration structures where only two are required. Further, the inner most could be moved to its own module (passing the escape handler object as an optional parameter, so that it could be monitored.

Additionally, I’d make the file size checking code its own function and probably break the logging of the events into one itself, passing the necessary details.

Naturally, the FOR…ENDFOR loops would be changed to DO WHILE…ENDDO structures that would logically terminate based upon the necessary conditions (loop completed, user pressed escape, insufficient disk space).

Now will you end up with less total code? Probably not, in fact you’ll probably end up with more. However, the individual modules will be easier to maintain and, because of their design, are better candidates for re-use than the current routine is.

The increased readability may even cause you to notice something like what I’m about to point out. I noted in the code a number of variables that had no utility within the context. Perhaps they’re needed elsewhere’s, but they certainly weren’t necessary within the code supplied. Further, there were, at least five references to the ALLTRIM() function so that it would return the name of the DBC. Every one after the first one would have been unnecessary had the result been stored in a variable originally. While it may not amount to a good deal of processing overhead, it is still there and quite unnecessary.

One “rule of thumb” I use to make these type of determinations is the following: I must be able to precisely put into a single sentence what the module does, without the use of a conjunction (“and” in this case).