Dragan --

Two separate issues here, really.

(1) The timer is enabled when PEM Editor does not have the focus so that it can sense when you change the active control, or the form you're editing, much the way the Property Window does. I'd love to have an alternative method of doing this -- but, alas, have not found anything (such as an event where I could use BindEvents). Failing this, the timer fires regularly. It does try to use a longer interval if you're using the trace window .... but that interval might be too short. I'd welcome suggestions on what intervals to use in this case.

Perhaps the best timer interval to use when the debugger is open and PEM Editor doesn't have the focus is 'forever' --- the effect of this would be that when you first open a form, PEMEditor does not respond at all until you actively click on it, but then it would respond 'naturally' thereafter.

(2) When PEM Editor does have the focus, the timer is disabled. However, if you have the debugger open, it's running, and reporting on events occurring within PEMEditor. As always, depending on which windows you have open within the debugger, performance can be greatly impacted --- particularly by the trace window and when you have Event Logging on.

I believe the complaints about PEM Editors performance have to do with the second point, that is, when PEM Editor has the focus, not with the first point.




>>Dragan --
>>
>>Thanks for the sample code. That's more or less what I was looking at already.
>>
>>In my teensy bit of testing so far, however, it may not be enough. For one thing, "close debugger" in code doesn't always close the debugger! ... apparently it doesn't do anything if the debugger is not idle. (I think that's it).
>>
>>And, calling "Debug" sets the focus on the debugger ... not what you expect if you've clicked someplace else.
>>
>>And, a typical session involves clicking back and forth between the form you are editing and PEM Editor. I'm sure it would be most annoying if the debugger kept flashing back and forth each time you did so.
>>
>>I'll be trying this more over the next few days (probably a weekend thing, now that I think of it), but am not convinced there's a workable solution.
>>
>>BTW, my statement about the Trace Window was premature -- all the debuggers windows cause speed degradation, some are just much worse than others.
>
>My choice of stuff permanently in watch window may make it much worse. Just try putting this list there: this, _tally, alias(), recno(), recc(), program(), thisform, set("datasession"). Anything running under a timer chokes when it has to fight for processor time while these refresh.
>
>And all your points are valid. Is there any way you could avoid the timer?