ONERROR Question

[JPGalea]

Hello,
I did a dumb thing! I ran some test code where I defined a variable as logical not realizing that I had this same variable defined as numeric in my main program and referenced in my main menu.
My test code ran fine and when I returned to the main menu and tried to select something off the menu I got the 'Operator/operand type mismatch' error. My question is why didn't my Onerror routine get control? I had to use Task manager to end Foxprow 2.6. My main program does:
Sets up stuff ...
ON ERROR DO GotError WITH ....
Sets up more stuff along with define variable = numeric
PUSH MENU _MSYSMENU
DO M_arts.mpr
READ VALID glQuitting && Foundation read

If more info is needed, let me know.

Thanks, Joe

 

[Olaf Doschke]

I don't have legacy foxpro at hand, but let me try...

..this behaviour still exists in VFP9 SP2. I just added a skip for clause testing a numeric variable for a certain numeric value. Then used a menu item to change that variable to .T. and when reactivating the menu the test of the skip for condition causes the VFP system error message, though ON ERROR is defined.

I changed the code generated by Genmenu to call a procedure so I changed from [tt]SKIP FOR condition[/tt] to [tt]SKIP FOR testcondition()[/tt] and defined a testcondition procedure, which does [tt]RETURN condition[/tt]. That way the code executed triggers the ON ERROR handling. So this would be your way out, if the problem is with SKIP FOR clauses or similar clauses: move code into procedures/functions you call, because when that call is made the ON ERROR handling works.

I don't see a way to make it work within DEFINE BAR, for example.

It would be interesting to know how you referenced the variable in your menu, because if that is within menu procedure code, this should trigger the error handling specified by ON ERROR. If that is within a SKIP FOR clause, as in my case, a part of a DEFINE BAR, the situation is quite complicated indeed. This is not even as simple as a property set to an expression, the SKIP FOR expression must be checked everytime the menu is activated to decide to skip or not skip that menu bar. But the code execution of the DEFINE command is when the bar is defined. To know why this happens you'd need to know how the VFP runtime manages to create code triggered by each menu activation which causes SKIP conditions to be checked. It's fair to assume that is not done on the VFP runtime level, but buried deeper into establishing some C++ event handling and thus, perhaps, this could explain it, jsut the normal system error handling happens.

Bye, Olaf.

 

[JPGalea]

Hi Olaf,
The variable is in the SKIP FOR clause. Thanks for your input!
Regards, Joe

 

[Olaf Doschke]

Thanks for the feedback. So this is as I thought.

That bug could have been fixed in all the years but at least there is that workaround. I actually don't know, but assume you can define a bar calling a procedure on selection. Genmenu must be quite legacy itself, I assume not much changed, it's one topic, where VFPX added the OOPMenu project (

https://github.com/VFPX/OOPMenu)

for the reason MS didn't develop this further into the OOP direction. It roots in the legacy menu commands nevertheless.

Bye, Olaf.