| Author | Topic: How to use DLL from within CXP Page | |
|---|---|---|
 | Stacy Violett | How to use DLL from within CXP Page on Wed, 19 Nov 2014 17:15:07 +0100 |
| Andreas Herdt | Re: How to use DLL from within CXP Page on Thu, 20 Nov 2014 12:48:09 +0100 Hi Stacy, The error which is happening is: > Linker: error ALK2102: unresolved external symbol CREATEOBJECT in Line 0 Please have a look at the documentation CreateObject() and the File Info section at the bottom: ========== snip =========== File info Include file activex.ch Static library ASCOM10.LIB Dynamic library ASCOM10.DLL ========== snap =========== This means that all defines you use with the COM/ActiveX layer are available in activex.ch. If you want utilize the function you must add ascom10.lib to your target. The required #pragma library() for adding the library is already available in activex.ch, thus including that header file is all you would do in normal case. However, CXP behaves slightly different. #pragma library() requests from a CXP page have no effect because the library set becoming part of the CXP page is a fixed amount and not on your control. Because of your posting it turns out that the activex subsystem should also be added to any CXP page by default. This is considered as shortcoming on our side and will be corrected in a future Xbase++ update. As far as I realize this is the only reason why your CXP page is not executing now. To overcome this situation I suggest a workaround as illustrated in the attachment to this mail. You will find a project showing the usage of CreateObject in a CXP page via a wrapper library. This is what you need to do: 1) Add a helpers library to your CXP page. This is done in the application. config file: <helpers lib="com.lib" /> 2) Add the com.dll target to your project. This library must be available in the subfolder helpers where your CXP page is. This library links against the ascom10.lib and implements a Wrapper for the function CreateObject(); The wrapper can be used from the CXP page. 3) In the CXP page use the wrapper. As I said, the missing linkage to the COM/ActiveX subsystem is a short- coming on our side and will be corrected. However, using the approach as outlined here has a very neat sideeffect, which is you can implement unit tests in the helpers folder from where you can verify your VFP code bridged to Xbase++. Having the connection to your buisiness logic available from helpers libraries therefore introduces a very strong abstraction layer. In case something is unclear or you need further assistance, please come back to this newsgroup. With my best regards, Andreas Herdt
Alaska Software
--------------------------------------------------------------------
Technical Support: support@alaska-software.com
News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm
Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
--------------------------------------------------------------------
"Stacy Violett" wrote in message
news:169a1714$5df8c99$949e8@news.alaska-software.com...
> Good Morning,
>
> First, thanks to Eric Lendvai and SWFox session getting me started down a
> path of forming my questions.
>
> If possible, I would like to see the approach used as a working sample for
> using VFP COM DLL from within a cxp page.
>
> Following are details of a simple test project:
>
> 1) VFP COM dll
>
> Details: have a project with vfpcom1.prg as main, build as multi-threaded
> com server
>
> *-- vfpcom1.prg contents
> define Class VFPCom1 as custom OLEPUBLIC
>
> Name = "VFPCom1"
> Version = "1.0"
>
> *------------------------------------------------------------------------
> procedure init
>
> set exclusive off
> set reprocess to 1 second
>
> set exact on
> set near off
> set notify off
> set deleted on
> set safety off
> set udfparms to reference
> set century on
> set century to 19 rollover 40
> set escape off
> set multilock on
> set refresh to 0,1
> set compatible foxplus
> set lock off
>
> endproc
> *------------------------------------------------------------------------
> function Test1
>
> private all like l_*
>
> l_return = [Hello World]
>
> return l_return
>
> endfunc
> *------------------------------------------------------------------------
> EndDefine
> *------------------------------------------------------------------------
>
>
>
> 2) my incomplete CXP code test_vfp_com_server.cxp
>
> <%
>
> l_VFP_MyObject = createobject("vfpcom1.vfpcom1")
> l_html += l_VFP_MyObject:Test1()+[<br>]
>
> ? l_html
>
> %>
>
> 3) location and reference to .ch and .lib functions required
> correct syntax and location for #include #pragma
>
>
> Currently, the cxp page errors out as follows:
> Message(s):
> Linker: error ALK2102: unresolved external symbol CREATEOBJECT in Line 0
>
>
> Thank you.
>
> Stacy sample.zip sample.zip |
| Stacy Violett | Re: How to use DLL from within CXP Page on Thu, 20 Nov 2014 22:22:22 +0100 Andreas, Thank you for taking a look and building these samples. Please forgive my newbie processing path here. I was first thinking that you intended your sample to run so I extracted and ran default.cxp from Chrome Linker: error ALK2102: unresolved external symbol GETCOMOBJECT in Line 0 Is your item 2) meant to be a sample of my vfpcom1.dll being built in or are the com.dll and .lib actual files that are needed her? *-- attempted to build the project with my vfpcom1 files and references: I was not able to find com.dll or .lib in my Alaska Software files. I went ahead and attempted to follow the structure of your sample and add my vfpcom1.dll along with copying in active.ch ascom10.dll and .lib (talking to vfpcom1.dll in place of your sample calls to com1.dll) Cxp page errors out because it does not like the fox library vfpcom1.tlb $CTP:Internal Error, no error but error! ALINK: fatal error ALK4002: invalid or corrupt file "c:\dev_users\stacyv\xbase\amr_mob\samplesv\website\helpers\vfpcom1.tlb" I have included a zip of my sample folder updated and modified to include all files and references that seem needed for this to work. Included, please find a zipped copy of the sample website with my attempts at putting this together as samplesv folder. The zip also has the vfp9t.dll multi-threaded runtime which I am not sure is necessary. I sure do appreciate your time. Stacy Andreas Herdt wrote in message news:2069e525$2e63b2cb$cba45@news.alaska- software.com... >Hi Stacy, > >The error which is happening is: > >> Linker: error ALK2102: unresolved external symbol CREATEOBJECT in Line 0 > >Please have a look at the documentation CreateObject() and the File Info >section >at the bottom: > >========== snip =========== >File info > >Include file > activex.ch >Static library > ASCOM10.LIB >Dynamic library > ASCOM10.DLL >========== snap =========== > >This means that all defines you use with the COM/ActiveX layer are available >in activex.ch. If you want utilize the function you must add ascom10.lib to >your target. The required #pragma library() for adding the library is >already >available in activex.ch, thus including that header file is all you would do >in >normal case. However, CXP behaves slightly different. > >#pragma library() requests from a CXP page have no effect because the >library set becoming part of the CXP page is a fixed amount and not on >your control. > >Because of your posting it turns out that the activex subsystem should also >be added to any CXP page by default. This is considered as shortcoming on >our side and will be corrected in a future Xbase++ update. As far as I >realize this is the only reason why your CXP page is not executing now. > >To overcome this situation I suggest a workaround as illustrated in the >attachment to this mail. You will find a project showing the usage of >CreateObject in a CXP page via a wrapper library. This is what you >need to do: > >1) Add a helpers library to your CXP page. This is done in the application. >config file: > > <helpers lib="com.lib" /> > >2) Add the com.dll target to your project. This library must be available >in the subfolder helpers where your CXP page is. This library links >against the ascom10.lib and implements a Wrapper for the function >CreateObject(); The wrapper can be used from the CXP page. > >3) In the CXP page use the wrapper. > >As I said, the missing linkage to the COM/ActiveX subsystem is a short- >coming on our side and will be corrected. However, using the approach >as outlined here has a very neat sideeffect, which is you can implement unit >tests in the helpers folder from where you can verify your VFP code >bridged to Xbase++. Having the connection to your buisiness logic available >from helpers libraries therefore introduces a very strong abstraction layer. > >In case something is unclear or you need further assistance, please >come back to this newsgroup. > >With my best regards, samplesv.zip samplesv.zip |
| Andreas Herdt | Re: How to use DLL from within CXP Page on Mon, 24 Nov 2014 13:11:29 +0100 |
| Stacy Violett | Re: How to use DLL from within CXP Page on Mon, 24 Nov 2014 16:47:40 +0100 |
| Andreas Herdt | Re: How to use DLL from within CXP Page on Fri, 28 Nov 2014 19:15:50 +0100 Hi Stacy, Let me please start with the idea on how to utilize VFP buisiness logic from an Xbase++ application. Xbase++ has built in a COM/ActiveX layer with which you are able to instantiate and automate ActiveX objects such as word. A COM instance in Xbase++ is encapsulated by an object of the class AutomationObject, ComObject or XbpActiveXControl. Forget about these classes immediately because they are not important now. You can find a nice introduction about that topic in Programming Guide -> ActiveX Overview in the Xbase++ online documentation. For example, if you want automate Microsoft Word, then you instantiate word (more specific a proxy in this case) with the function CreateObject() in the same way as you would do so from FoxPro: oWord := CreateObject( "word.application" ) This is possible, because Microsoft Word is registered with the ProgId word.application. You can do exactly the same with any other application that has a registered ProgId on the system. This is also true for your VFP application with your buisiness logic. If the VFP app is registered then you could instantiate and use it for example with this line of code: oVfpCom1 := CreateObject( "vfpcom1.vfpcom1" ) oVfpCom1:test1() Forget about Xbase++ and CXP now, you should first achive exactly this with FoxPro. Register your app as COM server and utilize the same COM server from another VFP application. The benefit is, you need not leave the area you are used to, yet. And you can test and maintain your code from a VFP environment and need not expect any possible side effects from a tool chain you are not compfortable with, yet. After this is done we come back to Xbase++ Andreas Herdt Alaska Software -------------------------------------------------------------------- Technical Support: support@alaska-software.com News Server: news.alaska-software.com Homepage: http://www.alaska-software.com WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm Fax European Office: +49 (0) 61 96 - 77 99 99 23 Fax US Office: +1 (646) 218 1281 -------------------------------------------------------------------- "Stacy Violett" wrote in message news:1c54150f$73e6cc5a$26845@news.alaska-software.com... > Andreas, > > Please do not feel rushed. > > I am excited to have your help moving this forward and helping us > understand where things are at between cxp and vfp for the moment. > > We are also very glad Alaska Software is taking up the VFP torch with > Polar Fox. > > Thank you again for your help. > > > Andreas Herdt wrote in message news:27c412f5$27f8f597$110ca@news.alaska- > software.com... >>Hi Stacy, >> >>Please give me some time to create a more detailed guideline. Please >>expect more info during this week. Here just some things that need >>to be covered: >> >>* The VFP solution must have been properly registered as COM >> server before it can be used from Xbase++. >>* No Xbase++ runtime libraries and header files requires to be >> copied to the helpers folder. >> >>I have to beg for some patience... helperssample.zip helperssample.zip |
| Stacy Violett | Re: How to use DLL from within CXP Page on Tue, 02 Dec 2014 02:55:11 +0100 Andreas, Everything looks great, making sense to me but the final step is seeming to fail in the cxp test and I am unable to see why. Your zip file un-touched will rebuild and create everything I need as advertised. Tracing this I see the com object and line 10 of main.prg displays the value 'AutomationObject' I can toy with the return value of dllmain.prg to return Hello World from unittest.exe by sending a return of o:test1() vs returning o All of this works great while running and/or tracing unittest.exe I run default.cxp from browser as follows http://localhost/website/default.cxp *-- right click on web page response and view source below, returns as NIL not application object as expected <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859- 1"/> </head> <body> <h1>Hello</h1> <p>The following shouldn't be NIL:</p> <p>NIL</p> </body> </html> Thank you for the examples and this is helping me greatly to understand the process from the ground up. Stacy Andreas Herdt wrote in message news:40c95b3b$47c995c6$1733c1@news.alaska- software.com... >Hi Stacy, > >Let me please start with the idea on how to utilize VFP buisiness logic >from an Xbase++ application. > >Xbase++ has built in a COM/ActiveX layer with which you are able >to instantiate and automate ActiveX objects such as word. A COM >instance in Xbase++ is encapsulated by an object of the class >AutomationObject, ComObject or XbpActiveXControl. Forget about >these classes immediately because they are not important now. You >can find a nice introduction about that topic in Programming Guide -> >ActiveX Overview in the Xbase++ online documentation. > >For example, if you want automate Microsoft Word, then you instantiate >word (more specific a proxy in this case) with the function CreateObject() >in the same way as you would do so from FoxPro: > > oWord := CreateObject( "word.application" ) > >This is possible, because Microsoft Word is registered with the ProgId >word.application. > >You can do exactly the same with any other application that has a >registered ProgId on the system. This is also true for your VFP application >with your buisiness logic. If the VFP app is registered then you could >instantiate and use it for example with this line of code: > > oVfpCom1 := CreateObject( "vfpcom1.vfpcom1" ) > oVfpCom1:test1() > >Forget about Xbase++ and CXP now, you should first achive exactly this >with FoxPro. Register your app as COM server and utilize the same >COM server from another VFP application. The benefit is, you need not leave >the area you are used to, yet. And you can test and maintain your code from >a VFP environment and need not expect any possible side effects from a tool >chain you are not compfortable with, yet. > >After this is done we come back to Xbase++ |
| Andreas Herdt | Re: How to use DLL from within CXP Page on Tue, 02 Dec 2014 19:28:08 +0100 Hi Stacy, Thank you very much for the updated info. We now have the proof that your VFP application is registered to serve as Com Server. And we have the proof that the Com Server can be utilized by Xbase++. (We also have the proof that utilizing your Com Server does not work yet from a CXP page Andreas Herdt
Alaska Software
--------------------------------------------------------------------
Technical Support: support@alaska-software.com
News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm
Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
--------------------------------------------------------------------
"Stacy Violett" wrote in message
news:240723d3$462220d9$2584d8@news.alaska-software.com...
> Andreas,
>
> Everything looks great, making sense to me but the final step is seeming
> to fail in the cxp test and I am unable to see why.
>
> Your zip file un-touched will rebuild and create everything I need as
> advertised. Tracing this I see the com object and line 10 of main.prg
> displays the value 'AutomationObject'
>
> I can toy with the return value of dllmain.prg to return Hello World from
> unittest.exe by sending a return of o:test1() vs returning o
>
> All of this works great while running and/or tracing unittest.exe
>
> I run default.cxp from browser as follows
> http://localhost/website/default.cxp
>
> *-- right click on web page response and view source below, returns as NIL
> not application object as expected
>
> <!DOCTYPE html>
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-
> 1"/>
> </head>
> <body>
> <h1>Hello</h1>
> <p>The following shouldn't be NIL:</p>
> <p>NIL</p>
> </body>
> </html>
>
>
> Thank you for the examples and this is helping me greatly to understand
> the process from the ground up.
>
>
> Stacy
>
>
> Andreas Herdt wrote in message news:40c95b3b$47c995c6$1733c1@news.alaska-
> software.com...
>>Hi Stacy,
>>
>>Let me please start with the idea on how to utilize VFP buisiness logic
>>from an Xbase++ application.
>>
>>Xbase++ has built in a COM/ActiveX layer with which you are able
>>to instantiate and automate ActiveX objects such as word. A COM
>>instance in Xbase++ is encapsulated by an object of the class
>>AutomationObject, ComObject or XbpActiveXControl. Forget about
>>these classes immediately because they are not important now. You
>>can find a nice introduction about that topic in Programming Guide ->
>>ActiveX Overview in the Xbase++ online documentation.
>>
>>For example, if you want automate Microsoft Word, then you instantiate
>>word (more specific a proxy in this case) with the function
> CreateObject()
>>in the same way as you would do so from FoxPro:
>>
>> oWord := CreateObject( "word.application" )
>>
>>This is possible, because Microsoft Word is registered with the ProgId
>>word.application.
>>
>>You can do exactly the same with any other application that has a
>>registered ProgId on the system. This is also true for your VFP
> application
>>with your buisiness logic. If the VFP app is registered then you could
>>instantiate and use it for example with this line of code:
>>
>> oVfpCom1 := CreateObject( "vfpcom1.vfpcom1" )
>> oVfpCom1:test1()
>>
>>Forget about Xbase++ and CXP now, you should first achive exactly this
>>with FoxPro. Register your app as COM server and utilize the same
>>COM server from another VFP application. The benefit is, you need not
> leave
>>the area you are used to, yet. And you can test and maintain your code
> from
>>a VFP environment and need not expect any possible side effects from a
> tool
>>chain you are not compfortable with, yet.
>>
>>After this is done we come back to Xbase++ ;-)
>>
>>In Xbase++ the COM/ActiveX capabilites are not enabled by default. To
>>use COM you need to link against ascom10.lib. This done and your
> application
>>comes up then the Xbase++ runtime libraries ascom10.dll and ascom10c.dll
>>are loaded with the Xbase++ application.
>>
>>With the workbench create a new project (console applicaton or windows
>>application) and have following procedure main in the prg:
>>
>>============= snip ==================
>>#include "activex.ch"
>>
>>PROCEDURE Main()
>> LOCAL oVfpCom1
>> oVfpCom1 := CreateObject( "vfpcom1.vfpcom1" )
>> oVfpCom1:test1()
>>RETURN
>>============= snap ==================
>>
>>Position the Mouse over activex.ch then press CTRL+ Left Mouse Button.
>>Activex.ch will open up in the editor. One of the first line is
>>#pragma library( "ascom10.lib" ). This means that if you require COM
> support
>>in Xbase++, just include activex.ch in your prg source file. You now can
>>Compile and debug the Xbase++ application. Just Press F10 and stop over
>>the line where CreateObject is executed. You will realize in the variable
>>window
>>that oVfpCom1 is an object encapsulating your VFP application. Hurray,
> step
>>one is done ;-)
>>
>>You can have exactly the same code in a CXP page. However, you
> encountered
>>a linker error informing you that CreateObject is an unresolved external
>>symbol.
>>You will receive the same link error with an exe target when you remove
> the
>>#include
>>in the sample above.
>>
>>The reason is because ascom10.lib is not linked against a CXP page by
>>default.
>>Even worse: It is not allowed to use the #pragma library statement in a
> CXP
>>page.
>>CXP is very restrictive regarding link libraries. So we need a solution
>>which
>>makes things slightly more complicated on one side, but which introduces
> an
>>abstraction level to your VFP buisiness logic that can be very handsome.
>>
>>It is now time to extract the attached process to a place below the
>>documentroot
>>of your webserver ;-)
>>
>>From the folder website load project.xpj into the workbench and have a
> look
>>at the
>>project manager.
>>
>>You will realize three targets, which is website.web, vfpappwrapper.dll
> and
>>unittest.exe
>>
>>In dllmain of vfpappwrapper.dll you find following code:
>>
>>================== snip ==================
>>#include "activex.ch"
>>
>>FUNCTION GetComObject(cProcId)
>> LOCAL o
>> o := CreateObject(cProcId)
>>RETURN(o)
>>================= snap ===================
>>
>>You will realize that the function GetComObject() serves as wrapper for
> the
>>function
>>CreateObject(). Because it is a dll target, we have no restrictions on
> what
>>libraries
>>are allowed to be linked against the binary target.
>>
>>In main.prg of unittest.exe you find the following:
>>
>>=================== snip =====================
>>#pragma library( "vfpappwrapper.lib" )
>>
>>PROCEDURE Main
>>
>> ? "Hello"
>> ? "The following shouldn't be NIL:"
>> ? GetComObject("vfpcom1.vfpcom1")
>>
>>RETURN
>>=================== snap =====================
>>
>>The executable target utilizes the wrapper dll to initialize COM/ActiveX
>>komponents. You see that up to now nothing is done with CXP. You can
>>implement all code in unittest.exe. Rebuild the complete project and use
>>the debugger to debug unittest.exe verifying what you have coded.
>>
>>We are ready for our final step, which is the CXP page.
>>
>>Open application.config from website.web. You find this:
>>
>>================= snip ========================
>><helpers lib="vfpappwrapper.lib" />
>>================= snap ========================
>>
>>This XML fragment makes your wrapper library getting linked to the
>>CXP page. A library which is added to the CXP in this way must be
>>found in a subfolder with the name helpers. Luckyly we have already put
>>the dll to the correct folder ;-) Because the wrapper dll is bound to the
>>CXP page in this way we now can do the following in default.cxp:
>>
>>================= snip =======================
>><html>
>><head>
>> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-
> 1"/>
>></head>
>><body>
>>
>> <h1>@('Hello')</h1>
>> <p>The following shouldn't be NIL:</p>
>> <p>@(GetComObject( "vfpcom1.vfpcom1" ))</p>
>>
>></body>
>></html>
>>================= snap =======================
>>
>>You will realize that we are doing exactly the same what we have
> previously
>>done in our unittest, now from within a CXP page.
>>
>>That's it, try it out. I suggest you do so step by step, in case of any
>>trouble
>>we have a clear path how we will nail down problems. Starting from your
>>COM server used in your VFP application ending in the CXP page, where
>>we hopefully deal with CXP specific issues only.
>>
>>One last word:
>>
>>In your attamp you have copied the VFP application and FoxPro runtime
>>to the helpers folder. Because the VFP app has been registered as COM
>>server, this should not be a requirement. At the end the decision where
> to
>>have this part of the solution is up to you.
>>
>>You have also copied activex.ch, ascom10.lib and ascom10.dll to the
>>helpers folder. This is definitive wrong.
>>
>>When you create binary target such as vfpappwrapper.dll and use the dll
>>from unittest, then the Xbase++ headers and binaries are found according
>>the environment variable settings in PATH, INCLUDE and LIB.
>>
>>If Xbase++ include files or runtime libraries need to be found from the
> CXP
>>page, they are found in the include and lib folder of the CXP
> installation.
>>
>>PLUS: Not having the binaries in the helpers folder reduces the size of
> the
>>attatchment if the solution shall be posted to the news server ;-)
>>
>>Hope this give you a good kick off.
>>
>>Have a nice weekend.
>>
>>With my best regards, |
| Stacy Violett | Re: How to use DLL from within CXP Page on Tue, 02 Dec 2014 23:31:03 +0100 Andreas, Thank you for the directions: >Select the target website.web as active target in the project manager and >Press F9 which executes the CXP page in the debugger. Upon debugging the cxp page from the workbench, I am getting a message a http://localhost:5000/website/default.cxp Error code: ERR_CONNECTION_REFUSED I will research with help here internally about our IIS setup and get back to you with more if it turns out I still need further help. Thank you sir, Stacy Andreas Herdt wrote in message news:67de703$5ed1619a$11c62@news.alaska- software.com... >Hi Stacy, > >Thank you very much for the updated info. > >We now have the proof that your VFP application is registered to serve >as Com Server. And we have the proof that the Com Server can be >utilized by Xbase++. > >(We also have the proof that utilizing your Com Server does not work >yet from a CXP page |
| Andreas Herdt | Re: How to use DLL from within CXP Page on Wed, 03 Dec 2014 09:11:24 +0100 |
| Stacy Violett | Re: How to use DLL from within CXP Page on Fri, 05 Dec 2014 23:15:25 +0100 |
| Stacy Violett | Re: How to use DLL from within CXP Page on Sat, 06 Dec 2014 01:29:51 +0100 |
| Till Warweg | Re: How to use DLL from within CXP Page on Thu, 11 Dec 2014 18:06:22 +0100 Dear Stacy,
First of all, I'm sorry I took so long to reply.
To be frank, I've never had to manually configure my firewall
for CXP debugging. Instead, I just pick "Allow Access" from the
security warning dialog that opens when I start debugging
for the first time. You don't get this dialog, do you? Does this
mean you're using an alternative firewall, for example, in
some anti-virus program?
In any case, I can see in my own firewall rules shows that
allowing access seems to establish two firewall rules - one
for UDP and one for TCP.
Coming back to the original problem with using vfpcom1
from within your CXP page, could you please give a quick
summary of your current status? You said that you suspect
your VFP DLL to not be registered correctly?
For your reference, these were the steps I used to set up the
example for usage with CXP:
1. Opened an administrator shell/command line
2. Copied the example to c:\inetpub\wwwroot\stacy
3. CD'ed to c:\inetpub\wwwroot\stacy\helpers folder
4. Tried to register vfpcom1.dll with
regsvr32 vfpcom1.dll (c:\windows\syswow64 variant!)
4.0 This failed because the VFP runtime in folder helpers
was incomplete (and this particular machine hadn't
seen VFP beforehand)
4.1 Copied fresh VFP9 runtime files to c:\inetpub\wwwroot\
stacy\helpers and tried again. This time, regsvr32.exe
responded with "DllRegisterServer succeeded"!
5. Opened the Xbase++ Workbench (admin flavor!) and
loaded the project files (c:\inetpub\wwwroot\stacy\
project.xpj).
6. With "website.web" active in the top/left panel, I pressed
F8 (debugger step command). This brought up the
firewall/security dialog we've just discussed.
7. Clicked "Allow Access".
8. Successively pressed F8 until I could verify that
CreateObject() returned an object and that I can
access its properties.
Let's compare notes Regards, Till Warweg [Alaska Software] -------------------------------------------------------------------- Technical Support: support@alaska-software.com News Server: news.alaska-software.com Homepage: http://www.alaska-software.com KnowledgeBase: http://www.alaska-software.com/kb -------------------------------------------------------------------- "Stacy Violett" schrieb im Newsbeitrag news:7ef6a3d2$759fb727$7ff30@news.alaska-software.com... > Andreas - update and second post here, note prior question about UDP or > TCP on opening port 5000 for debugging cxp... > > Have test results for you, excluding the F9 debug piece > > Test 1) msxml2 > I have completed rebuilding the test project using your suggestion for > alternate com object as follows: > <p>@(GetComObject( "msxml2.domdocument.6.0" ))</p> > > *-- getting good result in unittest.exe and also from .cxp page > *-- display source shows as expected > <!DOCTYPE html> > <html> > <head> > <meta http-equiv="Content-Type" content="text/html; charset=iso-8859- > 1"/> > </head> > <body> > <h1>Hello</h1> > <p>The following shouldn't be NIL:</p> > <p>AutomationObject</p> > </body> > </html> > > > > Test 2) with vfpcom1.dll > result of test 1) and your previous comments about credentials are leading > me to believe somehow I am not getting vfpcom1.dll registered properly > > I unregistered and re-registered with administrator priviliges > Also, we attempted running from a new virtual directory with admin > credentials and still get the result of NIL for the vfpcom1.dll from the > cxp page. > > so my results for test 2 are still the same as before > displays automationobject from unittest.exe as expected > displays NIL as result for call to > <p>@(GetComObject( "vfpcom1.vfpcom1" ))</p> > > Thanks Andreas, > > > > Stacy Violett wrote in message news:51f30ef$45a00712$7c423@news.alaska- > software.com... >>Andreas - can you tell me which type of protocol we need to use when >>opening port 5000 on our firewall? >> >>UDP or TCP >> >> >>Andreas Herdt wrote in message news:4069931e$3bcc1c06$10a10@news.alaska- >>software.com... >>>Hi Stacy, >>> >>>The unability to connect to the DevWebServer may have its root >>>cause in the firewall which does not allow this connection. In more >>>detail: The DevWebServer must be able to open the port 5000 to >>>listen for incoming connections. >>> >>>On a clean install starting an application which requires to open >>>a listening socket will result in a message box onc asking the user >>>for confirmation on opening such a socket. >>> >>>Attention: Debugging CXP is not affected by any IIS setting. >>> >>>Hope this helps, |
| Stacy Violett | Re: How to use DLL from within CXP Page on Thu, 11 Dec 2014 18:50:15 +0100 Till, very interesting morning here at Black Mountain Software. My friend and co-hort Chad Newman happened to be in town for a few days, normally he works from Minnesota. I explained the issue and he took a look at the website. It turns out the virtual directory needed to have a reduction in rights basically. The sample is working beautifully! The problem resolution: windows server 2012 1) Open the virtual directory in server manager in the right pane - view virtual directories go to advanced settings removed a physical path credential reference 2) Also enabled directory browsing Basically, we first made sure that a simple .asp page would function along with unregister and reregister of the com control. As to your debugging notes and instructions, I will follow through and explore your suggestions because it will be a great asset being able to debug from within cxp page. Thanks much Till. Thanks also to Andreas, Eric Lendvai as well to helping us reach this point. It will allow VFP developers to cover pieces that are planned in Polar Fox but not yet available. My feet are on solid ground again. Stacy Till Warweg wrote in message news:1a076557$2b75cd52$1cee9f@news.alaska- software.com... >Dear Stacy, > > First of all, I'm sorry I took so long to reply. > >To be frank, I've never had to manually configure my firewall >for CXP debugging. Instead, I just pick "Allow Access" from the >security warning dialog that opens when I start debugging >for the first time. You don't get this dialog, do you? Does this >mean you're using an alternative firewall, for example, in >some anti-virus program? > >In any case, I can see in my own firewall rules shows that >allowing access seems to establish two firewall rules - one >for UDP and one for TCP. > >Coming back to the original problem with using vfpcom1 >from within your CXP page, could you please give a quick >summary of your current status? You said that you suspect >your VFP DLL to not be registered correctly? > >For your reference, these were the steps I used to set up the >example for usage with CXP: > >1. Opened an administrator shell/command line >2. Copied the example to c:\inetpub\wwwroot\stacy >3. CD'ed to c:\inetpub\wwwroot\stacy\helpers folder >4. Tried to register vfpcom1.dll with > regsvr32 vfpcom1.dll (c:\windows\syswow64 variant!) >4.0 This failed because the VFP runtime in folder helpers > was incomplete (and this particular machine hadn't > seen VFP beforehand) >4.1 Copied fresh VFP9 runtime files to c:\inetpub\wwwroot\ > stacy\helpers and tried again. This time, regsvr32.exe > responded with "DllRegisterServer succeeded"! >5. Opened the Xbase++ Workbench (admin flavor!) and > loaded the project files (c:\inetpub\wwwroot\stacy\ > project.xpj). >6. With "website.web" active in the top/left panel, I pressed > F8 (debugger step command). This brought up the > firewall/security dialog we've just discussed. >7. Clicked "Allow Access". >8. Successively pressed F8 until I could verify that > CreateObject() returned an object and that I can > access its properties. > >Let's compare notes |
| Till Warweg | Re: How to use DLL from within CXP Page on Fri, 12 Dec 2014 16:59:27 +0100 Stacy, Interesting morning, indeed. Rights issues are often a pain to deal with, especially from a distance. Special kudos to Chad for picking this particular time for coming over |
| Andreas Herdt | Re: How to use DLL from within CXP Page on Tue, 16 Dec 2014 16:50:46 +0100 |
In Xbase++ the COM/ActiveX capabilites are not enabled by default. To
use COM you need to link against ascom10.lib. This done and your application
comes up then the Xbase++ runtime libraries ascom10.dll and ascom10c.dll
are loaded with the Xbase++ application.
With the workbench create a new project (console applicaton or windows
application) and have following procedure main in the prg:
============= snip ==================
#include "activex.ch"
PROCEDURE Main()
LOCAL oVfpCom1
oVfpCom1 := CreateObject( "vfpcom1.vfpcom1" )
oVfpCom1:test1()
RETURN
============= snap ==================
Position the Mouse over activex.ch then press CTRL+ Left Mouse Button.
Activex.ch will open up in the editor. One of the first line is
#pragma library( "ascom10.lib" ). This means that if you require COM support
in Xbase++, just include activex.ch in your prg source file. You now can
Compile and debug the Xbase++ application. Just Press F10 and stop over
the line where CreateObject is executed. You will realize in the variable
window
that oVfpCom1 is an object encapsulating your VFP application. Hurray, step
one is done 
Let's work on that)
We need to figure out why there is a difference invoking the Com Server
from a desktop application differs in the IIS scenario. For this I have
tried using a different COM component. I decided to use one that comes
automatically with the operating system installation to avoid side effects
that derive from a possibly wrong COM component registration.
I have modified the sample to use following ProgId:
msxml2.domdocument.6.0
I can observe on a Windows 7 operating system with a local IIS 7 installed
that the Com component can be successfully instantiated. I suggest you to
try this also and thus avoid side effects from your own component.
Following Scenarios should work:
* Instantiate the Com component from the desktop application (unittest.exe)
* Doing the same from the CXP page using the Debugger (website.web
description below)
* Doing the same from CXP page via IIS and CXP infrastructure (website.web)
Using the debugger for debugging CXP pages:
Select the target website.web as active target in the project manager and
Press F9 which executes the CXP page in the debugger.
The important thing to understand here is that when a CXP page is debugged
then a development web server is started that builds and executes the CXP
page. At the same time the default web browser is started too with an URL
suitable to connect to devwebserver.exe's default port which is 5000.
(Use a sample from the websamples collection to get a feeling how the
debugger behaves. I suggest using colors.cxp. Unload any project, then load
colors.cxp in the editor and select Debug from the editors context menu)
The debugger should stop execution at the first executable line in the
CXP page, you can press F9 a second time to continue execution.
Please observe whether the Com server can be instantiated now. The main
point here is that in this case we do not deal with the complexity that is
introduced with the IIS. The devwebserver is executed as ordenario
application acting with your (Stacy) credentials.
The last test is with the IIS in the background. Execute website.web with
Shift+F9 which simply starts the webbrowser using an URL pointing to
the IIS 7 and your CXP page.
In case all tests except the last one runs through means to figure out
how to configure IIS 7 and /or the application pool to allow the COM
instantiation.
You could try to run the application pool with your (Stacy) credentials. In
this case the Com components should be instantiated the same way you
are doing from the unittest.exe.
Please do the three tests, first with the Microsoft XML component then
with your VFP component and compare the results.
I hope this helps.
With my best regards,