Alaska Software Inc. - How to use DLL from within CXP Page
Username: Password:
AuthorTopic: How to use DLL from within CXP Page
Stacy ViolettHow to use DLL from within CXP Page
on Wed, 19 Nov 2014 17:15:07 +0100
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
Andreas HerdtRe: 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
Stacy ViolettRe: 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
Andreas HerdtRe: How to use DLL from within CXP Page
on Mon, 24 Nov 2014 13:11:29 +0100
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...

  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:57186169$72491cec$ec110@news.alaska-software.com...
> 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,
>
>
Stacy ViolettRe: How to use DLL from within CXP Page
on Mon, 24 Nov 2014 16:47:40 +0100
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...
Andreas HerdtRe: 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++ 

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,

  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
Stacy ViolettRe: 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++ 
>
>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,
Andreas HerdtRe: 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  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,

  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 ViolettRe: 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  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,
Andreas HerdtRe: How to use DLL from within CXP Page
on Wed, 03 Dec 2014 09:11:24 +0100
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,

  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:fde83c7$6d77bdd2$11ef0@news.alaska-software.com...
> 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 :-( 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,
Stacy ViolettRe: How to use DLL from within CXP Page
on Fri, 05 Dec 2014 23:15:25 +0100
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 ViolettRe: How to use DLL from within CXP Page
on Sat, 06 Dec 2014 01:29:51 +0100
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,
Till WarwegRe: 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 ViolettRe: 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 WarwegRe: 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 .

I'm glad to hear you're in working condition now. 

Happy coding,
  Till.

--------------------------------------------------------------------
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:2727a8c7$3c40d928$1d1816@news.alaska-software.com...
> 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  ?
Andreas HerdtRe: How to use DLL from within CXP Page
on Tue, 16 Dec 2014 16:50:46 +0100
Hi Stacy,

With the version Xbase++ 2.00.570 the ActiveX subsystem is linked to CXP 
pages by default. Using that version you will no longer encounter the linker 
error when you are using functions such as CreateObject() or GetObject()

Just for your information.

  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