Not sure if you're just lucky. I don't know enough about the whole situation, but doing some guesswork
oLoadingform - is that a form object existing while a form loads, removed from _screen afterwards? It could also be an object loading a form, but is it temporary only?
Are you checking pemstatus(_screen,'oLoadingForm',5) within a timer?
Well, then the timer events might occur before and after a form loaded, as simple as that. Loading of a form can be quite fast, also the timers aren't very precise and any code execution might queue timer events until after the code execution finishes and VFP becomes idle again, going into READ EVENTS mode and then timer events never fire during form load.
As said, there's very much guessing in this, but you might want to use BINDEVENTS here instead of a timer.
Without guessing, I can assure you it never is a problem to let the IF branch execute on a TRUE condition IF bExpression and it never needs IF bExpression=.T. to get there. Or shorter bExpression=.T. would never differ from bExpression itself, even if you would consider bExpression could be NULL. PEMSTATUS(...,5) can never be NULL, but even if it could, NULL=.T. is NULL just like NULL alone is. So bExpression=.T. always is the same as bExpression. Unless bExpression isn't logical/boolean, but then that would throw type errors every time.
To prove this in short just actually use a variable bExpression and set it to the three possible values .NULL., .T., and .F. and then check whether bExpression=.T. and bExpression itself can ever differ, or specifically whether bExpression = .T. can ever be .T. while bExpression itself is not .T., but .NULL. or .F. - you'll see it can't.
Code:
bExpression = .F.
? bExpression=.T., bExpression
bExpression = .T.
? bExpression=.T., bExpression
bExpression = .NULL.
? bExpression=.T., bExpression
This outputs three lines, each displaying the same boolean value twice.
Now the only remaining thing to know is what happens if an IF statements condition is NULL.
Code:
If .null.
? 'ifbranch'
Else
? 'elsebranch'
Endif
The answer is in case of a NULL value of the IF condition, the else branch becomes executed. This could be relevant if your overall IF condition involves more things that could also become .NULL. and would therefore explain that the if branch doesn't execute.
But in itself adding =.T. to an already evaluated expression with no further terms ANDded or ORed into the overall condition makes no difference whatsoever. So the only reason you had success with adding .T. is luck to catch one instance where the condition became .T., which you'd also have seen not adding =.T.
Well, and as a quintessence of it all - describe what you're doing more precisely to get better analysis and advice. But, really, you've made no difference from what I can see, the condition must be more complex and then it may become explainable.
Chriss
