>><snip>
>>
>>>Hi Ed, Of course, for C or Assembler, these type of error always occur.
>>>But as these part of code cannot be handled by programmer. The 4GL progr try all
>>>possible case to trace what these error may occur?! much seriously!
>>>
>>>Besides, I wonder no need other function call! That is, it will cause error
>>>even:
>>>

>>>= NVL(.NULL., _screen)
>>>

>>
>>I ran this code, as well as:
>>

>>  FOR i = 1 to 100
>>      =NVL(.NULL.,_SCREEN)
>>  ENDFOR
>>

>>
>>with no problems under VFP 5.0a, with no porblem to report.
>>
>>>
>>>Maybe it is a weapon for fired progr to make a deadTime of program.

>>>If Date() >= {2000/1/1}
>>>  = NVL(.NULL., _screen)
>>>Endif
>>>

>>>and hide it in any superclass Init procedure!
>>
>>Why?
>
>It is surely if the Nvl() return value is putting to other user-defined function will cause error.
>
>Strange?!
>In Executable program, if you call:
>

> =NVL(.null.,_screen)
>
> messagebox(_screen.name + chr(9) + _screen.class)
>* It will return other object value or Failure Error!!
>

>
>I think the problem is the NVL() remap another object to system variable _screen, so there will be problem if any statement calling for _screen!
>

If that's the case, then you should be explicitly able to cause the problem by release the LPARAMETER variable receiving the result of NVL() within your procedure, and forward it to M$ as a bug. It's likely in that case that it's not releasing an instance pointer to the _screen object, and needs to be tracked by the people who wrote the faulty code (ie M$). Since the error causes a fault condition that makes the application environment not valid (silly people who use globals should protect themselves better) it would always be impossible to hand control back to the VFP app.

Not worth tracking further for me, since if I'm writing an error handler in VFP, I have to assume that the error condition exists in a realm where the VFP environment is valid, otherwise, the context of where error handling lives (hint: this is caught and handled in the OS kernal, where VFP isn't a known and trusted entity) and if (read: I don't think any) heaps and tasks are safe to continue when this type of memory fault occurs, since at a minimum the OS has to discontinue the faulting processing to protect itself.

>Such as _screen.paint()
>Thus, it may error very fast or not depend on when the _screen object is called!

So why not a codearound to avoid creating this condition? Or do you have another bulletproof, bug-free interpreted language that can do better with equivalent functionality?