Hi all,

Can a Visual Basic or C  program call a DLL that has been created by xBase 
1.9? and if so how?

The reason I ask is that  I have a project which I am geting involved in 
where we need to communicate between my xbase environment and a VB/C 
application. The rules and processing for reservations are contained within 
the xbase application which need to be shared with the VB/C application. Any 
ideas would greatly be appreciated.

Kind Regards
Nestor

Hello nestor,

> Can a Visual Basic or C  program call a DLL that has been created by
> xBase 1.9? and if so how?
> 
> The reason I ask is that  I have a project which I am geting involved
> in where we need to communicate between my xbase environment and a
> VB/C application. The rules and processing for reservations are
> contained within the xbase application which need to be shared with
> the VB/C application. Any ideas would greatly be appreciated.

Others here have out of process COM server implementations which will support 
your goal.  Some might even have a solution to allow in-process use.  Both 
of these options can be technically complicated to implement.  

Personally, I lean towards SOAP web services which can be easily implemented 
with the XB2.NET library.  If you create a WSDL, VB.NET can just reference 
the web service and VS will create the appropriate function wrappers automatically. 
 Makes it about as easy to call a web service as using a COM object.  Web 
services have the advantage of easily supporting network calls from non-Windows 
hosts.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC

Hi Rodd,

Thanks for the tip...I will look into the SOAP web services.

Kind Regards,
Nestor

"Rodd Graham" <rgraham@grahamautomation.com> wrote in message 
news:6c56a9223b2ec8ca4fb1f7339fe2@news.alaska-software.com...
> Hello nestor,
>
>> Can a Visual Basic or C  program call a DLL that has been created by
>> xBase 1.9? and if so how?
>>
>> The reason I ask is that  I have a project which I am geting involved
>> in where we need to communicate between my xbase environment and a
>> VB/C application. The rules and processing for reservations are
>> contained within the xbase application which need to be shared with
>> the VB/C application. Any ideas would greatly be appreciated.
>
> Others here have out of process COM server implementations which will 
> support your goal.  Some might even have a solution to allow in-process 
> use.  Both of these options can be technically complicated to implement.
> Personally, I lean towards SOAP web services which can be easily 
> implemented with the XB2.NET library.  If you create a WSDL, VB.NET can 
> just reference the web service and VS will create the appropriate function 
> wrappers automatically. Makes it about as easy to call a web service as 
> using a COM object.  Web services have the advantage of easily supporting 
> network calls from non-Windows hosts.
>
> Regards,
>
> Rodd Graham, Consultant
> Graham Automation Systems, LLC
>
>

Hi Rodd,

I've Looked at the sample within XB2.NET  using SOAPEXEC.PRG and 
WEBSERVE.PRG and found them easy to follow. I believe I can do what I 
require very easily with this.

My only Concern is how does a VB program make the calls to the WEBSERVE.EXE 
program. I need to be able to explain what they need to do to be able to 
communicate with my web server once I complete it. I realize that once the 
web server is started that it will be visible to VB but how do they address 
the webserver and make use the procedure within the webserver example:

PROCEDURE SOAP_SaveMessage( oIn, oOut )
   Local oClient := ThreadObject()   a reference to the xbHTTPThread 
object
   Local cString

   if Empty(oIN:GetVar("UserName")) .or. Empty(oIN:GetVar("Message"))
       one of the required parameters is missing - send back an 
appropriate fault response.
      oOUT:SetFault("Client", "Client request is missing some parameters")
   else
      cString := "= SOAP REQUEST: " + oIN:Action + CRLF +;
                 "Date: " + DTOS(Date()) + ", Time: " + Time() + ", Client 
IP: " + oClient:InetNtoA(oClient:RemoteAddr) + CRLF +;
                 "UserName: " + oIN:GetVar("UserName") + CRLF +;
                 "Message:" + CRLF +;
                 oIN:GetVar("Message") + CRLF

      if xbSaveToFile( cString, oClient:Parent:RootDir + SOAP_LOG )
         oOUT:SetVar("Status"    , .T.)
         oOUT:SetVar("StatusText", "SAVED")
      else
         oOUT:SetVar("Status"    , .F.)
         oOUT:SetVar("StatusText", "ERROR: MESSAGE NOT SAVED")
      endif
   endif
   Return
==================================
Any help on this would greatly be appreciated.
I do not have experience in VB and this is why I am asking these question.

Kind Regards,
Nestor

"Rodd Graham" <rgraham@grahamautomation.com> wrote in message 
news:6c56a9223b2ec8ca4fb1f7339fe2@news.alaska-software.com...
> Hello nestor,
>
>> Can a Visual Basic or C  program call a DLL that has been created by
>> xBase 1.9? and if so how?
>>
>> The reason I ask is that  I have a project which I am geting involved
>> in where we need to communicate between my xbase environment and a
>> VB/C application. The rules and processing for reservations are
>> contained within the xbase application which need to be shared with
>> the VB/C application. Any ideas would greatly be appreciated.
>
> Others here have out of process COM server implementations which will 
> support your goal.  Some might even have a solution to allow in-process 
> use.  Both of these options can be technically complicated to implement.
> Personally, I lean towards SOAP web services which can be easily 
> implemented with the XB2.NET library.  If you create a WSDL, VB.NET can 
> just reference the web service and VS will create the appropriate function 
> wrappers automatically. Makes it about as easy to call a web service as 
> using a COM object.  Web services have the advantage of easily supporting 
> network calls from non-Windows hosts.
>
> Regards,
>
> Rodd Graham, Consultant
> Graham Automation Systems, LLC
>
>

Hello nestor,

> My only Concern is how does a VB program make the calls to the
> WEBSERVE.EXE program. I need to be able to explain what they need to
> do to be able to communicate with my web server once I complete it. I
> realize that once the web server is started that it will be visible to
> VB but how do they address the webserver and make use the procedure
> within the webserver example:

> Any help on this would greatly be appreciated.
> I do not have experience in VB and this is why I am asking these
> question.

If it is VB.NET, then just create a WSDL description XML of the web service 
that your web server returns.  Then just make a reference to the URL from 
Visual Studio.  VS will load the WSDL and create function wrappers that the 
VB application can call natively.

I use Altova XML Suite to build/manage WSDL but it is kind of pricey.  Prior 
to Altova, I just made the web service in VS.NET using stub functions that 
did nothing.  Then I just downloads the WSDL that VS generated.

If the VB is prior to .NET, probably best to procure a web service call library 
to speed the development.  Alternatively, there are examples on this NG for 
making SOAP calls using Microsoft COM objects.

One limitation of Web Services:  There is a lot of call overhead (HTTP, XML) 
that will limit your performance.  If your solution requires call roundtrips 
in milliseconds or 20+ calls a second, Web Services implemented in Xbase++ 
will be hard pressed to keep up.  Otherwise, Web Services are a great multiplatform 
standard for remote procedure calls.

Regards,

Rodd Graham, Consultant
Graham Automation Systems, LLC

"nestor" <nestor@softwareclinic.co.za> wrote in
news:3b572cee$2b69c6d5$a5a@news.alaska-software.com: 

> I've Looked at the sample within XB2.NET  using SOAPEXEC.PRG and 
> WEBSERVE.PRG and found them easy to follow. I believe I can do what I 
> require very easily with this.
> 
> My only Concern is how does a VB program make the calls to the
> WEBSERVE.EXE program. I need to be able to explain what they need to
> do to be able to communicate with my web server once I complete it.

See attached client side samples for VB and C#

The attached samples call a SOAP function RB_DownloadSO passing the 
following params:
 
Client = "MyClient"
CustNum = "CUST-099"
OrderNum = "ORD001"
BONum = ""
DataArray = {"AAA^BBB^CCC^DDD^EEE", "111^222^333"}
Delimiter = "^"

Best regards,
Boris Borzic

news://news.Xb2.NET
http://www.Xb2.NET
http://www.SQLExpress.net
industrial strength Xbase++ development tools

----
This is the SOAP server side function written in Xbase++, Xb2.NET and 
SQLExpress:

// Download a sales order
//
// parameters:
//    Client     - client name
//    CustNum    - customer number
//    OrderNum   - order number
//    BONum      - BO number
//    DataArray  - an array containing the order to download. The array 
//                 elements can be a char delimited string or an array 
//                 of fields.
//    Delimiter  - optional delimiter used in DataArray in case the 
//                 fields are passed as a string (default is "^")
//
// returns:
//    Result     - integer where 0 = success and negative = failure
//

PROCEDURE SOAP_RB_DownloadSO( oIN, oOUT )
   Local cClient   := oIN:GetVar("Client")
   Local cCustNum  := oIN:GetVar("CustNum")
   Local cOrderNum := oIN:GetVar("OrderNum")
   Local cBONum    := oIN:GetVar("BONum")
   Local aData     := oIN:GetVar("DataArray")
   Local cDelim    := oIN:GetVar("Delimiter")

   DEFAULT IFEMPTY cClient TO ""

   if Empty(cOrderNum) .or. Empty(aData) .or. ValType(aData) != "A"
      oOut:SetFault("Client", ;
    	    	"Client request contains invalid parameters")
      Return
   endif

   if ! CanDownload( cCustNum, cOrderNum, cBONum, cClient), cClient )
      oOut:SetFault("Client", ;
    	    	"Unable to download - order already exists")
      Return
   endif

   PostDownload( aData, cDelim, oOut )

   Return

//-------------------------------------------------------
static function PostDownload( aData, cDelim, oSoapOut )
   Local i, nFields, oStmt
   Local cTimeStamp := "SOAP:" + Time()

   DEFAULT IFEMPTY cDelim  TO "^"

   BEGIN_TRANSACTION_SEQUENCE

   oStmt := DefaultSQLConnection():NewStatement()

   for i := 1 to Len(aData)
      if ValType(aData[i]) == "C"
         // the fields are passed as a character delimited string
         nFields := NFields(aData[i], cDelim)
         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
     	    	   MakeFieldList(nFields) + ;
               ") values (0,'" + cTimeStamp + "'," + ;
    	    	   Caret2SQL(aData[i],cDelim) + ")"
         if oStmt:Execute() == SQL_XPP_ERROR
            break
         endif
      else
         // the fields are passed as an array
         nFields := Len(aData[i])
         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
    	    	   MakeFieldList(nFields) + ;
               ") values (0,'" + cTimeStamp + "'" +;
    	    	   Replicate(",?", nFields) + ")"
         if oStmt:Execute(aData[i]) == SQL_XPP_ERROR
            break
         endif
      endif
   next

   END_TRANSACTION_SEQUENCE

   oStmt:Destroy()

   if TRANSACTION_FAILED
      oSoapOut:SetFault(, "Transaction failed")
      Return .f.
   endif
   oSoapOut:SetVar("Result", 0)
   Return .t.

Hi Borris,

Thank you for your response....Unfortunately the vb sample was blocked and 
stripped from your email as unsafe. it would be better if you renamed it as 
a .txt file.

Kind regards,
Nestor


"Boris Borzic" <ng-at-sqlexpress-dot-net> wrote in message 
news:Xns9A5F53334DACASQLExpress@80.154.33.133...
> "nestor" <nestor@softwareclinic.co.za> wrote in
> news:3b572cee$2b69c6d5$a5a@news.alaska-software.com:
>
>> I've Looked at the sample within XB2.NET  using SOAPEXEC.PRG and
>> WEBSERVE.PRG and found them easy to follow. I believe I can do what I
>> require very easily with this.
>>
>> My only Concern is how does a VB program make the calls to the
>> WEBSERVE.EXE program. I need to be able to explain what they need to
>> do to be able to communicate with my web server once I complete it.
>
> See attached client side samples for VB and C#
>
> The attached samples call a SOAP function RB_DownloadSO passing the
> following params:
>
> Client = "MyClient"
> CustNum = "CUST-099"
> OrderNum = "ORD001"
> BONum = ""
> DataArray = {"AAA^BBB^CCC^DDD^EEE", "111^222^333"}
> Delimiter = "^"
>
> Best regards,
> Boris Borzic
> -- 
> news://news.Xb2.NET
> http://www.Xb2.NET
> http://www.SQLExpress.net
> industrial strength Xbase++ development tools
>
> ----
> This is the SOAP server side function written in Xbase++, Xb2.NET and
> SQLExpress:
>
>  Download a sales order
> 
>  parameters:
>     Client     - client name
>     CustNum    - customer number
>     OrderNum   - order number
>     BONum      - BO number
>     DataArray  - an array containing the order to download. The array
>                  elements can be a char delimited string or an array
>                  of fields.
>     Delimiter  - optional delimiter used in DataArray in case the
>                  fields are passed as a string (default is "^")
> 
>  returns:
>     Result     - integer where 0 = success and negative = failure
> 
>
> PROCEDURE SOAP_RB_DownloadSO( oIN, oOUT )
>   Local cClient   := oIN:GetVar("Client")
>   Local cCustNum  := oIN:GetVar("CustNum")
>   Local cOrderNum := oIN:GetVar("OrderNum")
>   Local cBONum    := oIN:GetVar("BONum")
>   Local aData     := oIN:GetVar("DataArray")
>   Local cDelim    := oIN:GetVar("Delimiter")
>
>   DEFAULT IFEMPTY cClient TO ""
>
>   if Empty(cOrderNum) .or. Empty(aData) .or. ValType(aData) != "A"
>      oOut:SetFault("Client", ;
>        "Client request contains invalid parameters")
>      Return
>   endif
>
>   if ! CanDownload( cCustNum, cOrderNum, cBONum, cClient), cClient )
>      oOut:SetFault("Client", ;
>        "Unable to download - order already exists")
>      Return
>   endif
>
>   PostDownload( aData, cDelim, oOut )
>
>   Return
>
> //-------------------------------------------------------
> static function PostDownload( aData, cDelim, oSoapOut )
>   Local i, nFields, oStmt
>   Local cTimeStamp := "SOAP:" + Time()
>
>   DEFAULT IFEMPTY cDelim  TO "^"
>
>   BEGIN_TRANSACTION_SEQUENCE
>
>   oStmt := DefaultSQLConnection():NewStatement()
>
>   for i := 1 to Len(aData)
>      if ValType(aData[i]) == "C"
>          the fields are passed as a character delimited string
>         nFields := NFields(aData[i], cDelim)
>         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
>            MakeFieldList(nFields) + ;
>               ") values (0,'" + cTimeStamp + "'," + ;
>           Caret2SQL(aData[i],cDelim) + ")"
>         if oStmt:Execute() == SQL_XPP_ERROR
>            break
>         endif
>      else
>          the fields are passed as an array
>         nFields := Len(aData[i])
>         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
>           MakeFieldList(nFields) + ;
>               ") values (0,'" + cTimeStamp + "'" +;
>           Replicate(",?", nFields) + ")"
>         if oStmt:Execute(aData[i]) == SQL_XPP_ERROR
>            break
>         endif
>      endif
>   next
>
>   END_TRANSACTION_SEQUENCE
>
>   oStmt:Destroy()
>
>   if TRANSACTION_FAILED
>      oSoapOut:SetFault(, "Transaction failed")
>      Return .f.
>   endif
>   oSoapOut:SetVar("Result", 0)
>   Return .t.
>
>


--------------------------------------------------------------------------------


>
>
>

"nestor" <nestor@softwareclinic.co.za> wrote in
news:78145e4a$3bcefa47$2aa@news.alaska-software.com: 

> Thank you for your response....Unfortunately the vb sample was blocked
> and stripped from your email as unsafe. it would be better if you
> renamed it as a .txt file.

see attached...

Best regards,
Boris Borzic

news://news.Xb2.NET
http://www.Xb2.NET
http://www.SQLExpress.net
industrial strength Xbase++ development tools

Hi Boris,
Received it all ok....Will examine and show to my fellow VB developer...VB 
is sure harder to read than xbase...I can understand some of it and I hope 
the VB programmer can fill in the blanks.
Thank you very much for your effort.

Kind Regards,
Nestor

"Boris Borzic" <ng-at-sqlexpress-dot-net> wrote in message 
news:Xns9A5F89E48726DSQLExpress@80.154.33.133...
> "nestor" <nestor@softwareclinic.co.za> wrote in
> news:78145e4a$3bcefa47$2aa@news.alaska-software.com:
>
>> Thank you for your response....Unfortunately the vb sample was blocked
>> and stripped from your email as unsafe. it would be better if you
>> renamed it as a .txt file.
>
> see attached...
>
> Best regards,
> Boris Borzic
> -- 
> news://news.Xb2.NET
> http://www.Xb2.NET
> http://www.SQLExpress.net
> industrial strength Xbase++ development tools
>
>

Hi Nestor
   I hope the approach of renaming a file with a txt extension worked. I 
had a client with a similar problem and renaming the exe file with a txt 
extension and sending it to him failed miserably. I thought that he was 
doing something improperly so I had him forward my email back to me and 
lo and behold the program would not run! I just got a black screen with 
a rapidly blinking cursor. I sent him a new version renamed to a pdf and 
it worked fine. It seems that one of our systems (his or mine) was 
making assumptions about files that had a txt extension (like maybe 
assuming they were 7bit??)
Garry

nestor wrote:
> Hi Borris,
> 
> Thank you for your response....Unfortunately the vb sample was blocked and 
> stripped from your email as unsafe. it would be better if you renamed it as 
> a .txt file.
> 
> Kind regards,
> Nestor
> 
> 
> "Boris Borzic" <ng-at-sqlexpress-dot-net> wrote in message 
> news:Xns9A5F53334DACASQLExpress@80.154.33.133...
>> "nestor" <nestor@softwareclinic.co.za> wrote in
>> news:3b572cee$2b69c6d5$a5a@news.alaska-software.com:
>>
>>> I've Looked at the sample within XB2.NET  using SOAPEXEC.PRG and
>>> WEBSERVE.PRG and found them easy to follow. I believe I can do what I
>>> require very easily with this.
>>>
>>> My only Concern is how does a VB program make the calls to the
>>> WEBSERVE.EXE program. I need to be able to explain what they need to
>>> do to be able to communicate with my web server once I complete it.
>> See attached client side samples for VB and C#
>>
>> The attached samples call a SOAP function RB_DownloadSO passing the
>> following params:
>>
>> Client = "MyClient"
>> CustNum = "CUST-099"
>> OrderNum = "ORD001"
>> BONum = ""
>> DataArray = {"AAA^BBB^CCC^DDD^EEE", "111^222^333"}
>> Delimiter = "^"
>>
>> Best regards,
>> Boris Borzic
>> -- 
>> news://news.Xb2.NET
>> http://www.Xb2.NET
>> http://www.SQLExpress.net
>> industrial strength Xbase++ development tools
>>
>> ----
>> This is the SOAP server side function written in Xbase++, Xb2.NET and
>> SQLExpress:
>>
>>  Download a sales order
>> 
>>  parameters:
>>     Client     - client name
>>     CustNum    - customer number
>>     OrderNum   - order number
>>     BONum      - BO number
>>     DataArray  - an array containing the order to download. The array
>>                  elements can be a char delimited string or an array
>>                  of fields.
>>     Delimiter  - optional delimiter used in DataArray in case the
>>                  fields are passed as a string (default is "^")
>> 
>>  returns:
>>     Result     - integer where 0 = success and negative = failure
>> 
>>
>> PROCEDURE SOAP_RB_DownloadSO( oIN, oOUT )
>>   Local cClient   := oIN:GetVar("Client")
>>   Local cCustNum  := oIN:GetVar("CustNum")
>>   Local cOrderNum := oIN:GetVar("OrderNum")
>>   Local cBONum    := oIN:GetVar("BONum")
>>   Local aData     := oIN:GetVar("DataArray")
>>   Local cDelim    := oIN:GetVar("Delimiter")
>>
>>   DEFAULT IFEMPTY cClient TO ""
>>
>>   if Empty(cOrderNum) .or. Empty(aData) .or. ValType(aData) != "A"
>>      oOut:SetFault("Client", ;
>>        "Client request contains invalid parameters")
>>      Return
>>   endif
>>
>>   if ! CanDownload( cCustNum, cOrderNum, cBONum, cClient), cClient )
>>      oOut:SetFault("Client", ;
>>        "Unable to download - order already exists")
>>      Return
>>   endif
>>
>>   PostDownload( aData, cDelim, oOut )
>>
>>   Return
>>
>> //-------------------------------------------------------
>> static function PostDownload( aData, cDelim, oSoapOut )
>>   Local i, nFields, oStmt
>>   Local cTimeStamp := "SOAP:" + Time()
>>
>>   DEFAULT IFEMPTY cDelim  TO "^"
>>
>>   BEGIN_TRANSACTION_SEQUENCE
>>
>>   oStmt := DefaultSQLConnection():NewStatement()
>>
>>   for i := 1 to Len(aData)
>>      if ValType(aData[i]) == "C"
>>          the fields are passed as a character delimited string
>>         nFields := NFields(aData[i], cDelim)
>>         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
>>            MakeFieldList(nFields) + ;
>>               ") values (0,'" + cTimeStamp + "'," + ;
>>           Caret2SQL(aData[i],cDelim) + ")"
>>         if oStmt:Execute() == SQL_XPP_ERROR
>>            break
>>         endif
>>      else
>>          the fields are passed as an array
>>         nFields := Len(aData[i])
>>         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
>>           MakeFieldList(nFields) + ;
>>               ") values (0,'" + cTimeStamp + "'" +;
>>           Replicate(",?", nFields) + ")"
>>         if oStmt:Execute(aData[i]) == SQL_XPP_ERROR
>>            break
>>         endif
>>      endif
>>   next
>>
>>   END_TRANSACTION_SEQUENCE
>>
>>   oStmt:Destroy()
>>
>>   if TRANSACTION_FAILED
>>      oSoapOut:SetFault(, "Transaction failed")
>>      Return .f.
>>   endif
>>   oSoapOut:SetVar("Result", 0)
>>   Return .t.
>>
>>
> 
> 
> --------------------------------------------------------------------------------
> 
> 
>>
>>
> 
>

Hi Garry,

Renaming the file in our case worked fine. It was a prg file that was
renamed to a txt extention. And we just renamed it back to a .prg.

Kind regards
Nestor

"Garry Allen" <gallen.dbmc@kingston.net> wrote in message 
news:2091e5b3$2888553f$574@news.alaska-software.com...
> Hi Nestor
>   I hope the approach of renaming a file with a txt extension worked. I 
> had a client with a similar problem and renaming the exe file with a txt 
> extension and sending it to him failed miserably. I thought that he was 
> doing something improperly so I had him forward my email back to me and lo 
> and behold the program would not run! I just got a black screen with a 
> rapidly blinking cursor. I sent him a new version renamed to a pdf and it 
> worked fine. It seems that one of our systems (his or mine) was making 
> assumptions about files that had a txt extension (like maybe assuming they 
> were 7bit??)
> Garry
>
> nestor wrote:
>> Hi Borris,
>>
>> Thank you for your response....Unfortunately the vb sample was blocked 
>> and stripped from your email as unsafe. it would be better if you renamed 
>> it as a .txt file.
>>
>> Kind regards,
>> Nestor
>>
>>
>> "Boris Borzic" <ng-at-sqlexpress-dot-net> wrote in message 
>> news:Xns9A5F53334DACASQLExpress@80.154.33.133...
>>> "nestor" <nestor@softwareclinic.co.za> wrote in
>>> news:3b572cee$2b69c6d5$a5a@news.alaska-software.com:
>>>
>>>> I've Looked at the sample within XB2.NET  using SOAPEXEC.PRG and
>>>> WEBSERVE.PRG and found them easy to follow. I believe I can do what I
>>>> require very easily with this.
>>>>
>>>> My only Concern is how does a VB program make the calls to the
>>>> WEBSERVE.EXE program. I need to be able to explain what they need to
>>>> do to be able to communicate with my web server once I complete it.
>>> See attached client side samples for VB and C#
>>>
>>> The attached samples call a SOAP function RB_DownloadSO passing the
>>> following params:
>>>
>>> Client = "MyClient"
>>> CustNum = "CUST-099"
>>> OrderNum = "ORD001"
>>> BONum = ""
>>> DataArray = {"AAA^BBB^CCC^DDD^EEE", "111^222^333"}
>>> Delimiter = "^"
>>>
>>> Best regards,
>>> Boris Borzic
>>> -- 
>>> news://news.Xb2.NET
>>> http://www.Xb2.NET
>>> http://www.SQLExpress.net
>>> industrial strength Xbase++ development tools
>>>
>>> ----
>>> This is the SOAP server side function written in Xbase++, Xb2.NET and
>>> SQLExpress:
>>>
>>>  Download a sales order
>>> 
>>>  parameters:
>>>     Client     - client name
>>>     CustNum    - customer number
>>>     OrderNum   - order number
>>>     BONum      - BO number
>>>     DataArray  - an array containing the order to download. The array
>>>                  elements can be a char delimited string or an array
>>>                  of fields.
>>>     Delimiter  - optional delimiter used in DataArray in case the
>>>                  fields are passed as a string (default is "^")
>>> 
>>>  returns:
>>>     Result     - integer where 0 = success and negative = failure
>>> 
>>>
>>> PROCEDURE SOAP_RB_DownloadSO( oIN, oOUT )
>>>   Local cClient   := oIN:GetVar("Client")
>>>   Local cCustNum  := oIN:GetVar("CustNum")
>>>   Local cOrderNum := oIN:GetVar("OrderNum")
>>>   Local cBONum    := oIN:GetVar("BONum")
>>>   Local aData     := oIN:GetVar("DataArray")
>>>   Local cDelim    := oIN:GetVar("Delimiter")
>>>
>>>   DEFAULT IFEMPTY cClient TO ""
>>>
>>>   if Empty(cOrderNum) .or. Empty(aData) .or. ValType(aData) != "A"
>>>      oOut:SetFault("Client", ;
>>>        "Client request contains invalid parameters")
>>>      Return
>>>   endif
>>>
>>>   if ! CanDownload( cCustNum, cOrderNum, cBONum, cClient), cClient )
>>>      oOut:SetFault("Client", ;
>>>        "Unable to download - order already exists")
>>>      Return
>>>   endif
>>>
>>>   PostDownload( aData, cDelim, oOut )
>>>
>>>   Return
>>>
>>> //-------------------------------------------------------
>>> static function PostDownload( aData, cDelim, oSoapOut )
>>>   Local i, nFields, oStmt
>>>   Local cTimeStamp := "SOAP:" + Time()
>>>
>>>   DEFAULT IFEMPTY cDelim  TO "^"
>>>
>>>   BEGIN_TRANSACTION_SEQUENCE
>>>
>>>   oStmt := DefaultSQLConnection():NewStatement()
>>>
>>>   for i := 1 to Len(aData)
>>>      if ValType(aData[i]) == "C"
>>>          the fields are passed as a character delimited string
>>>         nFields := NFields(aData[i], cDelim)
>>>         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
>>>            MakeFieldList(nFields) + ;
>>>               ") values (0,'" + cTimeStamp + "'," + ;
>>>           Caret2SQL(aData[i],cDelim) + ")"
>>>         if oStmt:Execute() == SQL_XPP_ERROR
>>>            break
>>>         endif
>>>      else
>>>          the fields are passed as an array
>>>         nFields := Len(aData[i])
>>>         oStmt:SQLString := "insert into dnload (dnloaded,timestmp" +;
>>>           MakeFieldList(nFields) + ;
>>>               ") values (0,'" + cTimeStamp + "'" +;
>>>           Replicate(",?", nFields) + ")"
>>>         if oStmt:Execute(aData[i]) == SQL_XPP_ERROR
>>>            break
>>>         endif
>>>      endif
>>>   next
>>>
>>>   END_TRANSACTION_SEQUENCE
>>>
>>>   oStmt:Destroy()
>>>
>>>   if TRANSACTION_FAILED
>>>      oSoapOut:SetFault(, "Transaction failed")
>>>      Return .f.
>>>   endif
>>>   oSoapOut:SetVar("Result", 0)
>>>   Return .t.
>>>
>>>
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>>
>>>
>>

Hi Nestor,

I think the easy way can be using WM_COPYDATA see 2 samples here
http://www.xbwin.com/download/ot4xb/Samples/TestSkype/
http://www.xbwin.com/download/ot4xb/Samples/TestWmCopyData/

Another option can be using DDE
See the TestDDEML sample in you DevCon CD or here
http://www.xbwin.com/download/WinApi_Tutor.zip

xb2net/SOAP also a good option specially if the server is not in the same machine

My favorite when both ends running in the same desktop is WM_COPYDATA, the only requisite is that data must be marshalized or also you can combine shared memory if you need to transfer large amounts of data.

Also if you want to avoid headaches and save time I can build you the interface using a C++ standard DLL with the callable funcions for the C/VB app and the PRG to link with you Xbase++ app.

Also  with a small extra work the exposed interface can be an ActiveX, but the only advantadge is that can be callable also from scripting. In both cases the price will be unexpensive as not so mutch developing time involved.

Regards,
Pablo Botella

Hello Nestor,

dll no, exe yes. Take a look at Documents / COM Server on www.xcockpit.com.

Best regards,

Michael

> Can a Visual Basic or C  program call a DLL that has been created by xBase 
> 1.9? and if so how?

Xbase++ built DLLs rely on the Xbase++ runtime. That's why it is not 
possible to call Xbase++ functions contained in (e.g) XppRT1.DLL directly 
from VB or any other external environment.

FWIW, I am about to finalize a COM server providing the entire Xbase++ 
runtime to COM clients. In terms of VB code this means:

 wa = CreateObject( "DbWorkArea" )
 ret = wa.DbUsearea( TRUE, "DBFNTX", "Customer.dbf" )
 ret = wa.LastRec()

I'm still busy with splitting the Xbase++ runtime into several namespaces. 
When done, the entire Xbase++ runtime is available in any COM compatible 
environment.

Conclusion, yes, it is possible to call into Xbase++ from C or VB. However, 
it is not possible without a COM server, that loads the Xbase++ runtime.

Regards,
--
Hannes

Hi Hannes,

We would be very interested in your effort to allow the xbase language to
be used a a .net slave which, IMVHO, is where it should be. We can already
translate xBase++ code to C# to about 87% accuracy; but it would be very
handy to be able to use the rest of the code as unmamaged.

Do you have a time-table or expected cost for your product? Happy to
discuss this off-line is you want to reply to my email address.

I am now in a reasonable position to compare the productivity between using
xBase++ and c# as I swap between one and the other on a regular basis.
Guess which one wins hands down. The clue is it is the the one with
intellisense, code snippets ann completion. 

But I am responsible for a lot of xBase code that I would dearly love to be
able to use under a .net umbrella.

Regards
	Mark


>> Can a Visual Basic or C  program call a DLL that has been created by xBase 
>> 1.9? and if so how?
> 
> Xbase++ built DLLs rely on the Xbase++ runtime. That's why it is not 
> possible to call Xbase++ functions contained in (e.g) XppRT1.DLL directly 
> from VB or any other external environment.
> 
> FWIW, I am about to finalize a COM server providing the entire Xbase++ 
> runtime to COM clients. In terms of VB code this means:
> 
>  wa = CreateObject( "DbWorkArea" )
>  ret = wa.DbUsearea( TRUE, "DBFNTX", "Customer.dbf" )
>  ret = wa.LastRec()
> 
> I'm still busy with splitting the Xbase++ runtime into several namespaces. 
> When done, the entire Xbase++ runtime is available in any COM compatible 
> environment.
> 
> Conclusion, yes, it is possible to call into Xbase++ from C or VB. However, 
> it is not possible without a COM server, that loads the Xbase++ runtime.
> 
> Regards,

Mark,

Have you looked at xbScript OLE edition?

Ron

"mark carew" <markcarew@magicwanddept.com.au> wrote in message 
news:m2sko04rmbsh.1kofd9jv51u0n.dlg@40tude.net...
>
> Hi Hannes,
>
> We would be very interested in your effort to allow the xbase language to
> be used a a .net slave which, IMVHO, is where it should be. We can already
> translate xBase++ code to C# to about 87% accuracy; but it would be very
> handy to be able to use the rest of the code as unmamaged.
>
> Do you have a time-table or expected cost for your product? Happy to
> discuss this off-line is you want to reply to my email address.
>
> I am now in a reasonable position to compare the productivity between 
> using
> xBase++ and c# as I swap between one and the other on a regular basis.
> Guess which one wins hands down. The clue is it is the the one with
> intellisense, code snippets ann completion.
>
> But I am responsible for a lot of xBase code that I would dearly love to 
> be
> able to use under a .net umbrella.
>
> Regards
> Mark
>
>
>>> Can a Visual Basic or C  program call a DLL that has been created by 
>>> xBase
>>> 1.9? and if so how?
>>
>> Xbase++ built DLLs rely on the Xbase++ runtime. That's why it is not
>> possible to call Xbase++ functions contained in (e.g) XppRT1.DLL directly
>> from VB or any other external environment.
>>
>> FWIW, I am about to finalize a COM server providing the entire Xbase++
>> runtime to COM clients. In terms of VB code this means:
>>
>>  wa = CreateObject( "DbWorkArea" )
>>  ret = wa.DbUsearea( TRUE, "DBFNTX", "Customer.dbf" )
>>  ret = wa.LastRec()
>>
>> I'm still busy with splitting the Xbase++ runtime into several 
>> namespaces.
>> When done, the entire Xbase++ runtime is available in any COM compatible
>> environment.
>>
>> Conclusion, yes, it is possible to call into Xbase++ from C or VB. 
>> However,
>> it is not possible without a COM server, that loads the Xbase++ runtime.
>>
>> Regards,

Ron,

after having written the xharbour docs, I certainly would love to see a 
thread safe xHarbour product. I admire the scripting capabilities of 
xbScript, but don't see its success when I look into details. IMO, there is 
still some work to do in data type mapping. VT_RECORD is just one example 
that is not supported and disallows a VB user to exchange user defined data 
types between VB and xbScript.

Regards,
--
Hannes

"Ron Pinkas" <Ron_remove_this_@xHarbour.com> schrieb im Newsbeitrag 
news:53440c3c$64d77ed1$b4ed@news.alaska-software.com...
> Mark,
>
> Have you looked at xbScript OLE edition?
>
> Ron
>
> "mark carew" <markcarew@magicwanddept.com.au> wrote in message 
> news:m2sko04rmbsh.1kofd9jv51u0n.dlg@40tude.net...
>>
>> Hi Hannes,
>>
>> We would be very interested in your effort to allow the xbase language to
>> be used a a .net slave which, IMVHO, is where it should be. We can 
>> already
>> translate xBase++ code to C# to about 87% accuracy; but it would be very
>> handy to be able to use the rest of the code as unmamaged.
>>
>> Do you have a time-table or expected cost for your product? Happy to
>> discuss this off-line is you want to reply to my email address.
>>
>> I am now in a reasonable position to compare the productivity between 
>> using
>> xBase++ and c# as I swap between one and the other on a regular basis.
>> Guess which one wins hands down. The clue is it is the the one with
>> intellisense, code snippets ann completion.
>>
>> But I am responsible for a lot of xBase code that I would dearly love to 
>> be
>> able to use under a .net umbrella.
>>
>> Regards
>> Mark
>>
>>
>>>> Can a Visual Basic or C  program call a DLL that has been created by 
>>>> xBase
>>>> 1.9? and if so how?
>>>
>>> Xbase++ built DLLs rely on the Xbase++ runtime. That's why it is not
>>> possible to call Xbase++ functions contained in (e.g) XppRT1.DLL 
>>> directly
>>> from VB or any other external environment.
>>>
>>> FWIW, I am about to finalize a COM server providing the entire Xbase++
>>> runtime to COM clients. In terms of VB code this means:
>>>
>>>  wa = CreateObject( "DbWorkArea" )
>>>  ret = wa.DbUsearea( TRUE, "DBFNTX", "Customer.dbf" )
>>>  ret = wa.LastRec()
>>>
>>> I'm still busy with splitting the Xbase++ runtime into several 
>>> namespaces.
>>> When done, the entire Xbase++ runtime is available in any COM compatible
>>> environment.
>>>
>>> Conclusion, yes, it is possible to call into Xbase++ from C or VB. 
>>> However,
>>> it is not possible without a COM server, that loads the Xbase++ runtime.
>>>
>>> Regards,
>
>

mark carew <markcarew@magicwanddept.com.au> wrote in
news:m2sko04rmbsh.1kofd9jv51u0n.dlg@40tude.net: 

> We would be very interested in your effort to allow the xbase language
> to be used a a .net slave which, IMVHO, is where it should be. We can
> already translate xBase++ code to C# to about 87% accuracy; but it
> would be very handy to be able to use the rest of the code as
> unmamaged. 

I have one client here in Toronto that has been doing this since 2003. They 
use Xb2.NET SOAP to execute Xbase++ functions from C#. It has been very 
successful for them!

An added bonus of using SOAP is that your Xbase++ code does not need to 
reside on the same machine as the C# application. This provides you with 
the opportunity to do simple load distribution.

Best regards,
Boris Borzic

news://news.Xb2.NET
http://www.Xb2.NET
http://www.SQLExpress.net
industrial strength Xbase++ development tools

Mark,

thank you for your interest. I'm currently running this VB code in my test 
lab:

Sub TestYukonXppRtl()
  Dim rtl As Object ' rtl = the Xbase++ runtime
  Dim wa As Object  ' wa = a work area

  Dim c As String
  Dim a As Variant

  Set rtl = CreateObject("YukonXppRtl")
  ret = rtl.DbeLoad("DBFDBE")
  ret = rtl.DbeLoad("NTXDBE")
  ret = rtl.DbeBuild("DBFNTX", "DBFDBE", "NTXDBE")

  Set wa = rtl.dbUsearea(,"DBFNTX", "Customer")
  ret = wa.lastRec()

  a = wa.DbStruct()
  c = wa.lastname
  c = wa.firstname
End Sub

I have named my software "The Yukon Project". It is quite complex, but I 
believe that I have resolved my goal to incorporate the Xbase++ runtime into 
COM, or unmanaged .NET

The above code runs fine but I still have to complete the documentation and 
resolve some quirks in the usage of SAFEARRAY holding VARIANTs of IDispatch.

I'll announce availability soon. (I'm not a friend of announcing unavailable 
software)

Regards,
--
Hannes


"mark carew" <markcarew@magicwanddept.com.au> schrieb im Newsbeitrag 
news:m2sko04rmbsh.1kofd9jv51u0n.dlg@40tude.net...
>
> Hi Hannes,
>
> We would be very interested in your effort to allow the xbase language to
> be used a a .net slave which, IMVHO, is where it should be. We can already
> translate xBase++ code to C# to about 87% accuracy; but it would be very
> handy to be able to use the rest of the code as unmamaged.
>
> Do you have a time-table or expected cost for your product? Happy to
> discuss this off-line is you want to reply to my email address.
>
> I am now in a reasonable position to compare the productivity between 
> using
> xBase++ and c# as I swap between one and the other on a regular basis.
> Guess which one wins hands down. The clue is it is the the one with
> intellisense, code snippets ann completion.
>
> But I am responsible for a lot of xBase code that I would dearly love to 
> be
> able to use under a .net umbrella.
>
> Regards
> Mark
>
>
>>> Can a Visual Basic or C  program call a DLL that has been created by 
>>> xBase
>>> 1.9? and if so how?
>>
>> Xbase++ built DLLs rely on the Xbase++ runtime. That's why it is not
>> possible to call Xbase++ functions contained in (e.g) XppRT1.DLL directly
>> from VB or any other external environment.
>>
>> FWIW, I am about to finalize a COM server providing the entire Xbase++
>> runtime to COM clients. In terms of VB code this means:
>>
>>  wa = CreateObject( "DbWorkArea" )
>>  ret = wa.DbUsearea( TRUE, "DBFNTX", "Customer.dbf" )
>>  ret = wa.LastRec()
>>
>> I'm still busy with splitting the Xbase++ runtime into several 
>> namespaces.
>> When done, the entire Xbase++ runtime is available in any COM compatible
>> environment.
>>
>> Conclusion, yes, it is possible to call into Xbase++ from C or VB. 
>> However,
>> it is not possible without a COM server, that loads the Xbase++ runtime.
>>
>> Regards,

Excellant!! Looking forward to it.

Hi All,
You guys are amazing...I really appreciate all of these good suggestions. I 
will visit and review these suggestions. The one that seems interesting to 
my untrained eye is Hannes Ziegler com server with xbase imbedded. I would 
feel more at home with something like that since I am more at home with pure 
xbase solutions. Please let me know how far you are with your finalization 
of your work.
Kind Regards,
Nestor
"nestor" <nestor@softwareclinic.co.za> wrote in message 
news:3ef3237e$59e277b8$d61e@news.alaska-software.com...
> Hi all,
>
> Can a Visual Basic or C  program call a DLL that has been created by xBase 
> 1.9? and if so how?
>
> The reason I ask is that  I have a project which I am geting involved in 
> where we need to communicate between my xbase environment and a VB/C 
> application. The rules and processing for reservations are contained 
> within the xbase application which need to be shared with the VB/C 
> application. Any ideas would greatly be appreciated.
>
> Kind Regards
> Nestor
>

Hannes you told about this (in the same NG? or to me in an email) almost 
around a year ago. I have been waiting...

I am sure Steffen/Till/Andreas too must be working on something similar.

Anand

"nestor" <nestor@softwareclinic.co.za> wrote in message 
news:4da24348$6bc3c124$1c331@news.alaska-software.com...
> Hi All,
> You guys are amazing...I really appreciate all of these good suggestions. 
> I will visit and review these suggestions. The one that seems interesting 
> to my untrained eye is Hannes Ziegler com server with xbase imbedded. I 
> would feel more at home with something like that since I am more at home 
> with pure xbase solutions. Please let me know how far you are with your 
> finalization of your work.
> Kind Regards,
> Nestor
> "nestor" <nestor@softwareclinic.co.za> wrote in message 
> news:3ef3237e$59e277b8$d61e@news.alaska-software.com...
>> Hi all,
>>
>> Can a Visual Basic or C  program call a DLL that has been created by 
>> xBase 1.9? and if so how?
>>
>> The reason I ask is that  I have a project which I am geting involved in 
>> where we need to communicate between my xbase environment and a VB/C 
>> application. The rules and processing for reservations are contained 
>> within the xbase application which need to be shared with the VB/C 
>> application. Any ideas would greatly be appreciated.
>>
>> Kind Regards
>> Nestor
>>
>
>

Anand,

you are invited to test the software I am developing.

What I'm doing is to give Xbase++ programmers FULL access to the
Windows platform SDK. The software I'm developing is VERY COMPLEX, but you
can test it already, if you wish to do so.

I call my software "The Yukon project"

The "Yukon project" is nothing more than enabling an Xbase++ programmer to 
get full access to the Windows platform SDK using PRG code only. If you have 
ever read the documentation of the Windows platform SDK, you know what I 
mean.

Do you have time for testing my software?
--
Hannes

PS: Be assured, Steffen/Till/Andreas do NOT understand the needs of an 
Xbase++ user.


"Anand Gupta" <anandg_remove_thisATcoral.in> schrieb im Newsbeitrag 
news:2f238fe9$2149a4c3$e59c@news.alaska-software.com...
> Hannes you told about this (in the same NG? or to me in an email) almost 
> around a year ago. I have been waiting...
>
> I am sure Steffen/Till/Andreas too must be working on something similar.
>
> Anand
>
> "nestor" <nestor@softwareclinic.co.za> wrote in message 
> news:4da24348$6bc3c124$1c331@news.alaska-software.com...
>> Hi All,
>> You guys are amazing...I really appreciate all of these good suggestions. 
>> I will visit and review these suggestions. The one that seems interesting 
>> to my untrained eye is Hannes Ziegler com server with xbase imbedded. I 
>> would feel more at home with something like that since I am more at home 
>> with pure xbase solutions. Please let me know how far you are with your 
>> finalization of your work.
>> Kind Regards,
>> Nestor
>> "nestor" <nestor@softwareclinic.co.za> wrote in message 
>> news:3ef3237e$59e277b8$d61e@news.alaska-software.com...
>>> Hi all,
>>>
>>> Can a Visual Basic or C  program call a DLL that has been created by 
>>> xBase 1.9? and if so how?
>>>
>>> The reason I ask is that  I have a project which I am geting involved in 
>>> where we need to communicate between my xbase environment and a VB/C 
>>> application. The rules and processing for reservations are contained 
>>> within the xbase application which need to be shared with the VB/C 
>>> application. Any ideas would greatly be appreciated.
>>>
>>> Kind Regards
>>> Nestor
>>>
>>
>>
>
>

Hannes,

> What I'm doing is to give Xbase++ programmers FULL access to the
> Windows platform SDK.

This is yet another completely separate subject.  BTW, how is it 
different than Cockit, and/or WinAPI.lib?

Ron

Ron,

>> What I'm doing is to give Xbase++ programmers FULL access to the
>> Windows platform SDK.
>
> This is yet another completely separate subject.  BTW, how is it 
> different than Cockit, and/or WinAPI.lib?

the difference is that NO declaration is required for using:

- all API functions
- more than 2000 structures (typedef struct)
- more than 1400 enumerations (typedef enum)
- more than 25000 #define constants (#define)
- more than 1400 IUnknown based COM interfaces (interfaces that do no comply 
with automation))

This requires only 3.5 MB of DLLs (compare this with the file sizes of 
Cockpit or WinAPI.lib, both of which provide maybe 300 API functions plus 80 
structures. I did not count).

In addition

- all COM automation interfaces are supported (IDispatch)
- all COM interfaces (IUnknown and IDispatch) are bi-directional, i.e. they 
can be called by an Xbase++ application OR by an external process complying 
with COM (e.g Visual Basic). That is: COM automation servers can be 
implemented with PRG code.

The Yukon project I'm working at since I've discontinued writing xHarbour 
docs pushes dynamic programming to an extreme: a programmer is given the 
choice to LOAD or to DECLARE everything that is available with the Windows 
platform SDK.

Loaded items are (by nature) slower than Declared (or compiled) items. 
However, loaded data is cached, so that the load overhead occurs only on 
intial creation of an item. That is: a programmer has the choice to 
implement PRG code or to use the data provided with the Windows platform SDK 
(Yukon project). The increased load time is the expense for saved 
programming time.

IMO, "programming time" is more expensive than "load time" with today's 
computers (we live in the 2-4GB RAM world today ). FWIW, I have already 
saved tens of hours of programming time just by loading the numeric value of 
#define constants from their symbolic names, rather than looking-up their 
values in *.h files (the Xbase++ preprocessor cannot process *.h files). 
When I found the "right" #define constant, I declared it in a *.ch file 
(Same with typedef struct, typedef enum, interfaces).

HTH,
--
Hannes

Hannes,

>>> What I'm doing is to give Xbase++ programmers FULL access to the
>>> Windows platform SDK.
>>
>> This is yet another completely separate subject.  BTW, how is it 
>> different than Cockit, and/or WinAPI.lib?
>
> the difference is that NO declaration is required for using:
>
> - all API functions
> - more than 2000 structures (typedef struct)
> - more than 1400 enumerations (typedef enum)
> - more than 25000 #define constants (#define)
> - more than 1400 IUnknown based COM interfaces (interfaces that do no 
> comply with automation))
>
> This requires only 3.5 MB of DLLs (compare this with the file sizes of 
> Cockpit or WinAPI.lib, both of which provide maybe 300 API functions plus 
> 80 structures. I did not count).

FWIW, WinAPI.lib is 400kb, which includes full C compiler debug info, 
accounting for probably more than half that size. While I didn't count the 
number of functions, structures, etc., it appears to cover everything we 
needed to produce a product as extensive as VXH.exe and VXH.lib, sporting 
practically all current gadgets, controls,  etc., as evident by it's Visual 
Studio look & feel.

> In addition
>
> - all COM automation interfaces are supported (IDispatch)
> - all COM interfaces (IUnknown and IDispatch) are bi-directional, i.e. 
> they can be called by an Xbase++ application OR by an external process 
> complying with COM (e.g Visual Basic). That is: COM automation servers can 
> be implemented with PRG code.

For the record, OleServer.lib has been doing all of the above, for long 
time, and is 225kb (including full C debug info). As I previously explained, 
it supports full bi directional functionality, including events bindings, 
and full in-process OLE server functionality, without requering any code 
modifications, at all.

> The Yukon project I'm working at since I've discontinued writing xHarbour 
> docs pushes dynamic programming to an extreme: a programmer is given the 
> choice to LOAD or to DECLARE everything that is available with the Windows 
> platform SDK.

IIUC, "LOAD", then R/T access to Win-SDK, has been available for long time, 
by means of DllCall(). In xHarbour this is complemeneted by native C 
Straucures support, and in Xbase++ with Cockpit, or your xbStruct.

Static support has also been available long time, by means of WinAPI.lib in 
xHarbour, and Cockpit in Xbase++.

> Loaded items are (by nature) slower than Declared (or compiled) items. 
> However, loaded data is cached, so that the load overhead occurs only on 
> intial creation of an item. That is: a programmer has the choice to 
> implement PRG code or to use the data provided with the Windows platform 
> SDK (Yukon project). The increased load time is the expense for saved 
> programming time.
>
> IMO, "programming time" is more expensive than "load time" with today's 
> computers (we live in the 2-4GB RAM world today ). FWIW, I have already 
> saved tens of hours of programming time just by loading the numeric value 
> of #define constants from their symbolic names, rather than looking-up 
> their values in *.h files (the Xbase++ preprocessor cannot process *.h 
> files). When I found the "right" #define constant, I declared it in a *.ch 
> file (Same with typedef struct, typedef enum, interfaces).

I believe there are few applications to produce .ch files from .h headers in 
general, and for Windows SDK in specific. Given the practically full support 
for C headers syntax (possible with PP), automation of such task appears 
more attractive to me, especially since human time, is indeed so much more 
expensive.

To clarify, I was asking my questions not because I had any points to make, 
but rather because I was truly interested in hearing in your thoughts. 
Similarly my input might be argumentative by nature, but not by choice. 

Best regards,

Ron

Ron,

> FWIW, WinAPI.lib is 400kb, which includes full C compiler debug info, 
> accounting for probably more than half that size. While I didn't count the 
> number of functions, structures, etc., it appears to cover everything we 
> needed to produce a product as extensive as VXH.exe and VXH.lib, sporting 
> practically all current gadgets, controls,  etc., as evident by it's 
> Visual Studio look & feel.

I'm not quite sure why VXH becomes an issue just because I explained 
implementational details about a software to you, that is not available yet. 
We did not discuss VXH issues, did we?

> To clarify, I was asking my questions not because I had any points to 
> make, but rather because I was truly interested in hearing in your 
> thoughts. Similarly my input might be argumentative by nature, but not by 
> choice. 

You are the first to learn implementational details about my Yukon project 
because I know that you understand the details. Apparently, you have no 
idea about the multi-threaded architecture of Xbase++. It appears that you 
are narrow minded and NOT able to see the far reaching consequences of what 
I'm up to.

I am working towards integrating the xBase language into Visual Studio 
(sorry, I don't need Visual xHarbour, neither do I need Visual Xbase++. 
Don't you think it is a waste of time to implement VXH?).

IMO, there was ABSOLUTELY no reason to come up with VXH as argument against 
my Yukon project. The implementation of Visual Tools is too expensive. Why 
not integrate the xBase language into an existing programming tool. The only 
reason why this did not happen yet is: there are too many C/C++ programmers 
developing xBase, who have absolutely NO CLUE what the xBase programming 
language is all about.

FWIW, both of us have agreed to disagree in many circumstances. Apparently 
the xBase programming language is something we have in common. IMO, I am an 
expert for the xBase language, and I believe you are an expert in the C 
programming language.

Take from this what you want, but (please) take it wisely.

Regards,
--
Hannes

Hannes,

>> FWIW, WinAPI.lib is 400kb, which includes full C compiler debug info, 
>> accounting for probably more than half that size. While I didn't count 
>> the number of functions, structures, etc., it appears to cover everything 
>> we needed to produce a product as extensive as VXH.exe and VXH.lib, 
>> sporting practically all current gadgets, controls,  etc., as evident by 
>> it's Visual Studio look & feel.
>
> I'm not quite sure why VXH becomes an issue just because I explained 
> implementational details about a software to you, that is not available 
> yet. We did not discuss VXH issues, did we?

I believe it was very clear that VXH was mentioned only to substantiate 
the scope of WinAPI.lib coverage of the Win SDK. This was clearly supposed 
to answer your references to the supposedly low number of functions covered.

>> To clarify, I was asking my questions not because I had any points to 
>> make, but rather because I was truly interested in hearing in your 
>> thoughts. Similarly my input might be argumentative by nature, but not by 
>> choice. 
>
> You are the first to learn implementational details about my Yukon project 
> because I know that you understand the details. Apparently, you have no 
> idea about the multi-threaded architecture of Xbase++. It appears that you 
> are narrow minded and NOT able to see the far reaching consequences of 
> what I'm up to.

I don't believe I made any reference to Xbase++ architecture, nor did I 
attempt to criticize or minimize your intentions.

> I am working towards integrating the xBase language into Visual Studio 
> (sorry, I don't need Visual xHarbour, neither do I need Visual Xbase++. 
> Don't you think it is a waste of time to implement VXH?).

Surely I'm not objective. Just as you would if I asked you, the same 
question, about your project[s]. For the majority of developers on earth, we 
both are wasting our time. 

> IMO, there was ABSOLUTELY no reason to come up with VXH as argument 
> against my Yukon project. The implementation of Visual Tools is too 
> expensive. Why not integrate the xBase language into an existing 
> programming tool. The only reason why this did not happen yet is: there 
> are too many C/C++ programmers developing xBase, who have absolutely NO 
> CLUE what the xBase programming language is all about.

I never stated any reason, as an argument against any of your projects. I'm 
an avid supporter of ALL xBase related projects.

> FWIW, both of us have agreed to disagree in many circumstances. Apparently 
> the xBase programming language is something we have in common. IMO, I am 
> an expert for the xBase language, and I believe you are an expert in the C 
> programming language.

I don't believe we argued anything in this thread, and I'm not aware of any 
such disagreement.

[FWIW, I'm first and foremost a Clipper Developer, I only learned C to 
protect my huge investment in Clipper code.]

> Take from this what you want, but (please) take it wisely.

Thanks,

Ron

Ron

> For the majority of developers on earth, we both are wasting our time. 

Sigh 

Hannes


"Ron Pinkas" <Ron_remove_this_@xHarbour.com> schrieb im Newsbeitrag 
news:7781a0bc$1a14f5e9$163c@news.alaska-software.com...
> Hannes,
>
>>> FWIW, WinAPI.lib is 400kb, which includes full C compiler debug info, 
>>> accounting for probably more than half that size. While I didn't count 
>>> the number of functions, structures, etc., it appears to cover 
>>> everything we needed to produce a product as extensive as VXH.exe and 
>>> VXH.lib, sporting practically all current gadgets, controls,  etc., as 
>>> evident by it's Visual Studio look & feel.
>>
>> I'm not quite sure why VXH becomes an issue just because I explained 
>> implementational details about a software to you, that is not available 
>> yet. We did not discuss VXH issues, did we?
>
> I believe it was very clear that VXH was mentioned only to substantiate 
> the scope of WinAPI.lib coverage of the Win SDK. This was clearly supposed 
> to answer your references to the supposedly low number of functions 
> covered.
>
>>> To clarify, I was asking my questions not because I had any points to 
>>> make, but rather because I was truly interested in hearing in your 
>>> thoughts. Similarly my input might be argumentative by nature, but not 
>>> by choice. 
>>
>> You are the first to learn implementational details about my Yukon 
>> project because I know that you understand the details. Apparently, you 
>> have no idea about the multi-threaded architecture of Xbase++. It appears 
>> that you are narrow minded and NOT able to see the far reaching 
>> consequences of what I'm up to.
>
> I don't believe I made any reference to Xbase++ architecture, nor did I 
> attempt to criticize or minimize your intentions.
>
>> I am working towards integrating the xBase language into Visual Studio 
>> (sorry, I don't need Visual xHarbour, neither do I need Visual Xbase++. 
>> Don't you think it is a waste of time to implement VXH?).
>
> Surely I'm not objective. Just as you would if I asked you, the same 
> question, about your project[s]. For the majority of developers on earth, 
> we both are wasting our time. 
>
>> IMO, there was ABSOLUTELY no reason to come up with VXH as argument 
>> against my Yukon project. The implementation of Visual Tools is too 
>> expensive. Why not integrate the xBase language into an existing 
>> programming tool. The only reason why this did not happen yet is: there 
>> are too many C/C++ programmers developing xBase, who have absolutely NO 
>> CLUE what the xBase programming language is all about.
>
> I never stated any reason, as an argument against any of your projects. 
> I'm an avid supporter of ALL xBase related projects.
>
>> FWIW, both of us have agreed to disagree in many circumstances. 
>> Apparently the xBase programming language is something we have in common. 
>> IMO, I am an expert for the xBase language, and I believe you are an 
>> expert in the C programming language.
>
> I don't believe we argued anything in this thread, and I'm not aware of 
> any such disagreement.
>
> [FWIW, I'm first and foremost a Clipper Developer, I only learned C to 
> protect my huge investment in Clipper code.]
>
>> Take from this what you want, but (please) take it wisely.
>
> Thanks,
>
> Ron
>

Hi Hannes

Thanks so much for the offer. I would love to. My boss (Rajesh) reads the NG 
as well, I hope he allots me some time for the same, once am over with the 
new-financial-year rollover which started on 1st Apr. (In India our 
Financial year is 1-Apr to 31st-Mar)

If I recall correctly you were working on a project where I could make my 
Xb++ app accessible from a .NET and/or other apps by making the xbase++ 
Applicaion with very few lines changes work as a COM/ActiveX component. I 
have been looking forward for that for longggg....

Anand

"Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
news:690faf5$7d2d7828$ba3e@news.alaska-software.com...
> Anand,
>
> you are invited to test the software I am developing.
>
> What I'm doing is to give Xbase++ programmers FULL access to the
> Windows platform SDK. The software I'm developing is VERY COMPLEX, but you
> can test it already, if you wish to do so.
>
> I call my software "The Yukon project"
>
> The "Yukon project" is nothing more than enabling an Xbase++ programmer to 
> get full access to the Windows platform SDK using PRG code only. If you 
> have ever read the documentation of the Windows platform SDK, you know 
> what I mean.
>
> Do you have time for testing my software?
> --
> Hannes
>
> PS: Be assured, Steffen/Till/Andreas do NOT understand the needs of an 
> Xbase++ user.
>
>
> "Anand Gupta" <anandg_remove_thisATcoral.in> schrieb im Newsbeitrag 
> news:2f238fe9$2149a4c3$e59c@news.alaska-software.com...
>> Hannes you told about this (in the same NG? or to me in an email) almost 
>> around a year ago. I have been waiting...
>>
>> I am sure Steffen/Till/Andreas too must be working on something similar.
>>
>> Anand
>>
>> "nestor" <nestor@softwareclinic.co.za> wrote in message 
>> news:4da24348$6bc3c124$1c331@news.alaska-software.com...
>>> Hi All,
>>> You guys are amazing...I really appreciate all of these good 
>>> suggestions. I will visit and review these suggestions. The one that 
>>> seems interesting to my untrained eye is Hannes Ziegler com server with 
>>> xbase imbedded. I would feel more at home with something like that since 
>>> I am more at home with pure xbase solutions. Please let me know how far 
>>> you are with your finalization of your work.
>>> Kind Regards,
>>> Nestor
>>> "nestor" <nestor@softwareclinic.co.za> wrote in message 
>>> news:3ef3237e$59e277b8$d61e@news.alaska-software.com...
>>>> Hi all,
>>>>
>>>> Can a Visual Basic or C  program call a DLL that has been created by 
>>>> xBase 1.9? and if so how?
>>>>
>>>> The reason I ask is that  I have a project which I am geting involved 
>>>> in where we need to communicate between my xbase environment and a VB/C 
>>>> application. The rules and processing for reservations are contained 
>>>> within the xbase application which need to be shared with the VB/C 
>>>> application. Any ideas would greatly be appreciated.
>>>>
>>>> Kind Regards
>>>> Nestor
>>>>
>>>
>>>
>>
>>
>

Hi Anand,

please refer to my private mail

Regards,
--
Hannes

> Thanks so much for the offer. I would love to. My boss (Rajesh) reads the 
> NG as well, I hope he allots me some time for the same, once am over with 
> the new-financial-year rollover which started on 1st Apr. (In India our 
> Financial year is 1-Apr to 31st-Mar)
>
> If I recall correctly you were working on a project where I could make my 
> Xb++ app accessible from a .NET and/or other apps by making the xbase++ 
> Applicaion with very few lines changes work as a COM/ActiveX component. I 
> have been looking forward for that for longggg....
>
> Anand
>
> "Hannes Ziegler" <hz@knowleXbase.com> wrote in message 
> news:690faf5$7d2d7828$ba3e@news.alaska-software.com...
>> Anand,
>>
>> you are invited to test the software I am developing.
>>
>> What I'm doing is to give Xbase++ programmers FULL access to the
>> Windows platform SDK. The software I'm developing is VERY COMPLEX, but 
>> you
>> can test it already, if you wish to do so.
>>
>> I call my software "The Yukon project"
>>
>> The "Yukon project" is nothing more than enabling an Xbase++ programmer 
>> to get full access to the Windows platform SDK using PRG code only. If 
>> you have ever read the documentation of the Windows platform SDK, you 
>> know what I mean.
>>
>> Do you have time for testing my software?
>> --
>> Hannes
>>
>> PS: Be assured, Steffen/Till/Andreas do NOT understand the needs of an 
>> Xbase++ user.
>>
>>
>> "Anand Gupta" <anandg_remove_thisATcoral.in> schrieb im Newsbeitrag 
>> news:2f238fe9$2149a4c3$e59c@news.alaska-software.com...
>>> Hannes you told about this (in the same NG? or to me in an email) almost 
>>> around a year ago. I have been waiting...
>>>
>>> I am sure Steffen/Till/Andreas too must be working on something similar.
>>>
>>> Anand
>>>
>>> "nestor" <nestor@softwareclinic.co.za> wrote in message 
>>> news:4da24348$6bc3c124$1c331@news.alaska-software.com...
>>>> Hi All,
>>>> You guys are amazing...I really appreciate all of these good 
>>>> suggestions. I will visit and review these suggestions. The one that 
>>>> seems interesting to my untrained eye is Hannes Ziegler com server with 
>>>> xbase imbedded. I would feel more at home with something like that 
>>>> since I am more at home with pure xbase solutions. Please let me know 
>>>> how far you are with your finalization of your work.
>>>> Kind Regards,
>>>> Nestor
>>>> "nestor" <nestor@softwareclinic.co.za> wrote in message 
>>>> news:3ef3237e$59e277b8$d61e@news.alaska-software.com...
>>>>> Hi all,
>>>>>
>>>>> Can a Visual Basic or C  program call a DLL that has been created by 
>>>>> xBase 1.9? and if so how?
>>>>>
>>>>> The reason I ask is that  I have a project which I am geting involved 
>>>>> in where we need to communicate between my xbase environment and a 
>>>>> VB/C application. The rules and processing for reservations are 
>>>>> contained within the xbase application which need to be shared with 
>>>>> the VB/C application. Any ideas would greatly be appreciated.
>>>>>
>>>>> Kind Regards
>>>>> Nestor
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

Nestor,

You should be able to compile your core processing code (non UI code) into a 
COM Server, withOUT any code modifications,  with xHarbour Builder, then use 
that core DLL from both Xbase 1.9 as well as VB or any other COM capable 
platform.

Ron

" <nestor@softwareclinic.co.za> wrote in message 
news:3ef3237e$59e277b8$d61e@news.alaska-software.com...
> Hi all,
>
> Can a Visual Basic or C  program call a DLL that has been created by xBase 
> 1.9? and if so how?
>
> The reason I ask is that  I have a project which I am geting involved in 
> where we need to communicate between my xbase environment and a VB/C 
> application. The rules and processing for reservations are contained 
> within the xbase application which need to be shared with the VB/C 
> application. Any ideas would greatly be appreciated.
>
> Kind Regards
> Nestor
>

Ron

I would have loved to try xbH as well, but no-more new tries on xBase 
products. I did tried xHB when it was launched initially (I tried Visual 
FlagShip as well few months ago). Xbase++ well I work only on products (our 
company is a product company). I can't afford to change/test/deploy/re-test 
acrss 5,000+ customers location again.

.net developers are available in huge quantum in this part of the world and 
so are Java guys.

I have been slowly hiring people and moving things in that direction.Hannes 
solution, if it see's the light of the day will be a great one.

I also intend  build a team on Adobe's AIR and/or MS-Silverlight.

Ron how about a hosted xHB site, where-in people can upload their codes, 
your site compiles (since you mentioned its a straight re-compile) and 
download the EXE file !

Anand

"Ron Pinkas" <Ron_remove_this_@xHarbour.com> wrote in message 
news:1e224138$406dab27$2988a@news.alaska-software.com...
> Nestor,
>
> You should be able to compile your core processing code (non UI code) into 
> a COM Server, withOUT any code modifications,  with xHarbour Builder, then 
> use that core DLL from both Xbase 1.9 as well as VB or any other COM 
> capable platform.
>
> Ron
>
> " <nestor@softwareclinic.co.za> wrote in message 
> news:3ef3237e$59e277b8$d61e@news.alaska-software.com...
>> Hi all,
>>
>> Can a Visual Basic or C  program call a DLL that has been created by 
>> xBase 1.9? and if so how?
>>
>> The reason I ask is that  I have a project which I am geting involved in 
>> where we need to communicate between my xbase environment and a VB/C 
>> application. The rules and processing for reservations are contained 
>> within the xbase application which need to be shared with the VB/C 
>> application. Any ideas would greatly be appreciated.
>>
>> Kind Regards
>> Nestor
>>
>
>

Hi Anand,

> I would have loved to try xbH as well, but no-more new tries on xBase
> products. I did tried xHB when it was launched initially (I tried Visual
> FlagShip as well few months ago). Xbase++ well I work only on products 
> (our
> company is a product company). I can't afford to 
> change/test/deploy/re-test
> acrss 5,000+ customers location again.
>
> .net developers are available in huge quantum in this part of the world 
> and
> so are Java guys.
>
> I have been slowly hiring people and moving things in that 
> direction.Hannes
> solution, if it see's the light of the day will be a great one.
>
> I also intend  build a team on Adobe's AIR and/or MS-Silverlight.
>
> Ron how about a hosted xHB site, where-in people can upload their codes,
> your site compiles (since you mentioned its a straight re-compile) and
> download the EXE file !

Not sure if I get all your points, and also I suspect some confusion of 
terms, between the few posts in this thread.

1. The O.P. asked about a way to make available existing Xbase++ code, to 
VB or C. I responded that xHarbour Builder can compile any valid 
Clipper/Xbase++ code (not utilizing [G]UI), practicaly unmodied, into a 
generic OLE Server DLL, which can then be used by VB, C, as well as any 
other OLE compilant platforms.

2. Hannses, answered that he's working on a way to expose the complete 
Xbase++ RTL, as an OLE Server.
    a. This is not exactly what the O.P. was looking for.
    b. FWIW, the complete xHarbour RTL (probaly complete overlap of Xbase++ 
RTL) is already available as an OLE Server.

3. Mark Carew responded to Hannes:

<<<
We would be very interested in your effort to allow the xbase language to
be used a a .net slave which, IMVHO, is where it should be. We can already
translate xBase++ code to C# to about 87% accuracy; but it would be very
handy to be able to use the rest of the code as unmamaged.
>>>

   a. This is a completley different issue than 1 or 2 above. Thus I pointed 
Mark at xbScript, which does provides the xBase language as an MS 
ActiveScript engine, thus available to any OLE capable platform.

As to your suggestion, I'll gladly provide a DLL OLE for any Xbase++ utility 
code. F.e I did that recently with xmlfile.prg which was posted on this NG, 
by Peter Alderliesten few weeks back. VBScript sample will look like this:

-----------------------------------------------------------------------------------------------------
   DIM XMLServer, XMLDoc

   SET XMLServer = CreateObject( "XMLFile" )
   SET XMLDoc = XMLServer.xmlDoc.New()

   XMLDoc.read( "test.xml" )
   XMLDoc.write( "mytest.xml" )

   msgbox "'test.xml' was processed into 'mytest.xml'."
-----------------------------------------------------------------------------------------------------

Basically I just had to ADD, folowing lines to top of xmlfile.prg:

-----------------------------------------------------------------------------------------------------
#ifdef __XHARBOUR__
   #pragma BEGINDUMP
      #define CLS_Name "XMLFile"
      #define CLS_ID   "{FFF3B20C-2413-49c8-AEE6-9FA68518A1DA}"
      #include "OleServer.h"
   #pragma ENDDUMP

   #include "hbclass.ch"

   REQUEST HB_GT_NUL_DEFAULT

    TODO: Review, Xbase++ ?
   #xtranslate Var2Char( <x> ) => CStr( <x> )
   #xtranslate AnsiToUnicode( <s> ) => AnsiToWide( <s> )
   #xtranslate UnicodeToAnsi( <s> ) => WideToAnsi( <s> )
   #xtranslate IsTextUnicode( <s>, <len> ) => ( Chr(0) $ <s> )
   #xtranslate MsgBox( <msg>,<title> ) => Alert( StrTran( <msg>, Chr(13) + 
Chr(10), ";" ) )
#endif
-----------------------------------------------------------------------------------------------------

I also had to add 4 ENDMETHOD statements, because xHarbour INLINE Methods 
require an ENDMETHOD terminator. Finally I had to split 1 line because 
xHarbour does not like multiple method declaration in a single line.

The modified source, as well as the VBScript test sample are attached. If 
anyone intrested, and unless the author of the code objects (no copyright 
notice present in the source, nor at the post), I'll be happy to provide a 
link for the resulting compiled OLE Server (xmlfile.dll[48kb] + 
xhbdll.dll[2.5mb]).

Ron 

Ron,

> As to your suggestion, I'll gladly provide a DLL OLE for any Xbase++ utility 
> code. F.e I did that recently with xmlfile.prg which was posted on this NG, 
> by Peter Alderliesten few weeks back. VBScript sample will look like this:
> 
> -----------------------------------------------------------------------------------------------------
>    DIM XMLServer, XMLDoc
> 
>    SET XMLServer = CreateObject( "XMLFile" )
>    SET XMLDoc = XMLServer.xmlDoc.New()
> 
>    XMLDoc.read( "test.xml" )
>    XMLDoc.write( "mytest.xml" )
> 
>    msgbox "'test.xml' was processed into 'mytest.xml'."
> -----------------------------------------------------------------------------------------------------
> 
> Basically I just had to ADD, folowing lines to top of xmlfile.prg:
> 
> -----------------------------------------------------------------------------------------------------
> #ifdef __XHARBOUR__
>    #pragma BEGINDUMP
>       #define CLS_Name "XMLFile"
>       #define CLS_ID   "{FFF3B20C-2413-49c8-AEE6-9FA68518A1DA}"
>       #include "OleServer.h"
>    #pragma ENDDUMP
> 
>    #include "hbclass.ch"
> 
>    REQUEST HB_GT_NUL_DEFAULT
> 
>     TODO: Review, Xbase++ ?
>    #xtranslate Var2Char( <x> ) => CStr( <x> )
>    #xtranslate AnsiToUnicode( <s> ) => AnsiToWide( <s> )
>    #xtranslate UnicodeToAnsi( <s> ) => WideToAnsi( <s> )
>    #xtranslate IsTextUnicode( <s>, <len> ) => ( Chr(0) $ <s> )
>    #xtranslate MsgBox( <msg>,<title> ) => Alert( StrTran( <msg>, Chr(13) + 
> Chr(10), ";" ) )
> #endif
> -----------------------------------------------------------------------------------------------------
> 
> I also had to add 4 ENDMETHOD statements, because xHarbour INLINE Methods 
> require an ENDMETHOD terminator. Finally I had to split 1 line because 
> xHarbour does not like multiple method declaration in a single line.
> 
> The modified source, as well as the VBScript test sample are attached. If 
> anyone intrested, and unless the author of the code objects (no copyright 
> notice present in the source, nor at the post), I'll be happy to provide a 
> link for the resulting compiled OLE Server (xmlfile.dll[48kb] + 
> xhbdll.dll[2.5mb]).

Well I am glad I am writing "transportable" code...
Just tell me: this way you met the xmlDoc class available to other
programming environments, is that corect?
- I suppose that means that the xHarbour runtime has to be supplied as
well?
- Do I have to register anything on the workstation?
- What happens if bigger parts of code, including - say - multithreading is
compiled this way?  

Peter

Peter,

> Well I am glad I am writing "transportable" code...
> Just tell me: this way you met the xmlDoc class available to other
> programming environments, is that corect?

If I understand your question correctly, then yes, as an OLE Dll, it's 
available to any platform supporting OLE.

> - I suppose that means that the xHarbour runtime has to be supplied as
> well?

The xhbdll.dll is the complete RTL.

> - Do I have to register anything on the workstation?

Yes, like any OLE Dll, you must register it as follows:

   RegSvr32 xmlfile.dll

Or using registration support of Installers.

> - What happens if bigger parts of code, including - say - multithreading 
> is
> compiled this way?

Sorry no support for Xbase++ M/T, but any functioning code, as large as you 
have, will be supported the same way.

Ron