Watch out for SYS(2335) in non-COM Applications

Just ran into a nice inconsistency in VFP 9.0. I’ve been adding some functionality into Web Connection to allow easy configuration for unattended COM mode. VFP 8 and later has SYS(2335,0) which basically forces a COM server to throw exceptions on any blocking user interface operation. So if you bring up a MessageBox for example, rather than hanging the COM server, you get an error thrown. This behavior works both in DLL and EXE servers and can be quite handy.

Typically SYS(2335) is only used in COM applications, but it's not all that unusual to have SYS(2335) in code that might have to cooperate with non COM code like an application startup routine or a business object factory.

Supposedly SYS(2335,0) does not have any effect on a standalone non-COM application. However, I’ve run into an edge case where it does seem to affect standalong applications. Oddly the problem doesn’t show up in the IDE runtime of VFP, but only if I run the application as an EXE.

My scenario is in Web Connection where I’ve just added an lUnattendedComMode flag to the server object. When running in File mode, Web Connection throws up a Visual FoxPro desktop form with a timer that checks for request files. The form is kept alive with READ EVENTS handler. This has been working forever.

Now, if I set my lUnattendedComMode flag Web Connection is thrown into unattended mode. In file based mode in the IDE everything still works fine and that’s how I’ve been testing. However, today I actually built an exe and ran it. The server started up and – uncerimoniuosly disappeared immediately when run from Explorer. If I now go into the VFP IDE and run that same EXE the server runs and stays up and running.

In short the EXE starts and immediately exits. Lots of head scratching ensued...

Baffled I started looking at settings and sure enough it turns out it’s the unattended mode flag. When NOT running in COM mode and running a standalone EXE READ EVENTS doesn’t hold up.

The fix for Web Connection is easy enough. Internally an additional check is added for making sure the server is actually in COM mode:

IF THIS.lUnattendedComMode AND this.lComObject

   SYS(2335,0)

ENDIF  

In your own applications you can check _VFP.StartMode:

IF INLIST(_Vfp.STARTMODE,2,3,5)

   *** Global Reference to goWCServer

   THIS.lComObject = .T.  

ENDIF

By the way, be aware that the _VFP and Application objects are COM objects that REQUIRE that the VFP runtimes have been registered on a machine. If you just copy runtime files to a machine or server and don’t register _VFP or Application will fail which can cause some really tricky failures in code.

Anyway – the moral of the story is: When using SYS(2335,0) you should always make sure you explicitly check for the operational mode before setting this flag or else you may have some unexpected side effects even though the documentation states that this function has no effect on non-COM applications.