More On VFP and Windows XP XP2 NX … Samples and What-not (by John Koziol)


For background information, please refer to my prior post on this topic.  Also, there's an excellent paper on advanced COM and VFP in particular, located at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnfoxgen7/html/vfpandcom.asp 


As aforementioned, the problem with the NX switch is that it makes early binding a no-no for COM. Now, if you've created a COM DLL with VFP and it's being called from a client using early binding, then the client code has to be changed. The VFP code is fine.


“So what do I have to do differently in my VFP code to comply with the NX switch being on?“, you might reasonably ask.  “Stay the bloody hell away from CREATEOBJECTEX()” would be my answer, that is, after a few drinks or particularly bad session feedbacks. Seriously, the following mantra applies:


CREATEOBJECT, NEWOBJECT good!.  CREATEOBJECTEX bad!“


Now there are cases where a COM object must be instantiated using CREATEOBJECTEX, fer instance, where a remote server computer has to be named or the COM server does not support an iDispatch interface.  What to do then?


Well, the NX switch can be toggled per process, so a particular COM DLL that requires NX = OFF can be dealt with.  Refer to the links I posted in my earlier post on this topic.


Here's some code.  The first part of the code creates a simple DLL.  


*:*************************************
*:* Create a simple VFP DLL.
*:*
*:* Calvin Hsia and John Koziol
*:*
*:*************************************
*:* Create a simple VFP DLL
*:*************************************


IF FILE("testnx.dll")
 DECLARE integer DllUnregisterServer IN testnx.dll
 ?DllUnregisterServer()
 CLEAR DLLS
ENDIF


SET TEXTMERGE TO testnx.prg
SET TEXTMERGE ON NOSHOW
 \DEFINE CLASS testnx AS Session OLEPUBLIC
 \PROCEDURE MyEval(cExpr)
 \RETURN &cExpr
 \ENDPROC
 \ENDDEFINE
SET TEXTMERGE TO


BUILD PROJECT testnx FROM testnx
BUILD DLL testnx FROM testnx
*************************************************


OK, now here's guaranteed success for instancing the and calling the COM DLL under NX.  


*:*************************************
*:* Here's a good way to create the COM object -
*:* no early binding.  NX compatible.
*:*************************************


ox=NEWOBJECT("testnx.testnx")
?ox.myeval("_VFP.ServerName")
RELEASE ox,oy


Here's a guaranteed exception under NX


*:*************************************
*:* Here's early binding, NOT NX compatible
*:*************************************


ox=CREATEOBJECTEX("testnx.testnx","","")
?ox.myeval("_VFP.ServerName")
RELEASE ox,oy


See?  The only difference was I used NEWOBJECT in the good and CREATEOBJECTEX in th bad.


If I come across any other issues, I will post yet again.  Until then, be thou not afraid of XP SP 2.  It's cool, it's stable, and the security enhancements are going to be better for all of us in the long term.

Comments (4)

  1. Hmm. I hope you’re going to make a new Documentation-Appendix for all this nice updates…

    Keep working on this excellent product guys!

    DBZ

  2. John Koziol says:

    Not my call on documentation or whitepapers, Pablo, but I’m not sure that VFP issues with Windows XP SP2 rise to that level. Just bookmark my two posts here and that’s 99% of what you need to know.

Skip to main content