View source for How to programmatically fight with WPS:PMWP entries in POPUPLOG.OS2

<center><noinclude><< [[How to programmatically fight with WPS:.CLASSINFO, 90 sec delay, DEFAULTVIEW|.CLASSINFO, 90 sec delay, DEFAULTVIEW]] -- [[How to programmatically fight with WPS|Index]] -- [[How to programmatically fight with WPS:Lost/broken desktop or broken Templates or Startup|Lost/broken desktop or broken Templates or Startup]] >></noinclude></center>


I've been looking at this for quite a while, and have come up with a possible explanation and a cure that's worse than the disease. AFAIK, the WPS uses "deferred parameter checking" - IOW, it doesn't check parameters for validity, it just uses them. If they cause a trap, the WPS's exception handler cleans up, usually by aborting the current operation. As such, PMWP isn't the "cause" of the problem, just the unsuspecting victim of bad data. Overall, the system is working as designed.

==SHELLEXCEPTIONHANDLER==
If you're really hell-bent on eliminating this, you can try adding this line to config.sys:
 SET SHELLEXCEPTIONHANDLER=OFF

This turns off the WPS's exception handler, guaranteeing any errors will cause a crash. It's normally used by developers of WPS classes to keep the WPS from covering up bugs in their code. (That's why I've pursued this problem so vigorously: with the exception handler off, I couldn't keep the WPS up long enough to begin my debugging.) 


<center><noinclude><< [[How to programmatically fight with WPS:.CLASSINFO, 90 sec delay, DEFAULTVIEW|.CLASSINFO, 90 sec delay, DEFAULTVIEW]] -- [[How to programmatically fight with WPS|Index]] -- [[How to programmatically fight with WPS:Lost/broken desktop or broken Templates or Startup|Lost/broken desktop or broken Templates or Startup]] >></noinclude></center>

[[Category:How to programmatically fight with WPS]]