Interfacing with a .dll
Tim Stone
have to first register the CalledBack procedure with the .dll and that will
then provide it with an address to write the XML documents. Then I need to
connect, and after that I can start interacting.
I am providing my xHarbour code below, and comments with the .dll functions
as provided to me, and then my DLL32 FUNCTION statements.
Of course, its not working ( yet ). Does anyone see errors ? First, here
is the instruction I received:
"You receive the XML doc, Hello, for example in YOUR called back procedure
in YOUR program. The pointer passed thru to your program from wcap.dll is
the address location in memory for a complete XML document. You will need to
copy it to local memory in your program, a String or Buffer type. "
Now, here is my code so far:
FUNCTION main // wpac
LOCAL pFunc := HB_FuncPtr( "CalledBack" )
PRIVATE wcap := LoadLibrary( "wcap.dll" )
PRIVATE cXMLDoc := ""
// Register the procedure
WCAPRegisterReceive( pFunc )
// Connect to the server
WCAPConnectAs( 'localhost', 17943, 1 )
IF WCAPConnected()
MsgInfo( "Looks OK" )
ENDIF
// Receive Hello
MsgInfo( cXMLDoc )
WCAPDisconnect( )
FreeLibrary( wcap )
QUIT
RETURN NIL
PROCEDURE CalledBack( PC )
cXMLDoc := PC
RETURN NIL
// Register the callback procedure for wcap.dll to use for replies
// Declare Sub WCAPRegisterReceive Lib "wcap.dll" _ (ByVal lpRcvProcedure As
Long)
DLL32 FUNCTION WCAPRegisterReceive( lpRcvProcedure AS LONG ) AS PASCAL FROM
"WCAPRegisterReceive" LIB wcap
// Establish connection to DIAL
// Declare Function WCAPConnect Lib "wcap.dll" _ (ByVal lpszHost As String,
ByVal lPort As Long) As Boolean
DLL32 FUNCTION WCAPConnectAs(lpszHost AS LPSTR, lPort AS LONG, Autostart AS
LONG ) AS BOOL PASCAL FROM "WCAPConnectAs" LIB wcap
// Query if connection to DIAL is established
// Declare Function WCAPConnected Lib "wcap.dll" () As Boolean
DLL32 FUNCTION WCAPConnected() AS BOOL PASCAL FROM "WCAPConnected" LIB wcap
// End connection with DIAL
// Declare Sub WCAPDisconnect Lib "wcap.dll" ()
DLL32 FUNCTION WCAPDisconnect() AS BOOL PASCAL FROM "WCAPDisconnect" LIB
wcap
// Send wcap document request to DIAL
// Declare Sub WCAPSend Lib "wcap.dll" (ByVal lpszXMLDoc As String)
DLL32 FUNCTION WCAPSend(lpszXMLDoc As String) AS LPSTR PASCAL FROM
"WCAPSend" LIB wcap
// Start DIAL server
//Declare Function WCAPStartServer Lib "wcap.dll" () As Boolean
DLL32 FUNCTION WCAPStartServer( ) AS BOOL PASCAL FROM "WCAPStartServer" LIB
wcap
dlzc
On Sep 29, 5:10 pm, "Tim Stone" <timst...@masterlinksoftware.com>
wrote:
> I have a need to interface with a .dll used to transfer XML
> docs to me.
...
> Now, here is my code so far:
...
> // Register the callback procedure for wcap.dll to use for replies
> // Declare Sub WCAPRegisterReceive Lib "wcap.dll" _ (ByVal lpRcvProcedure As
> Long)
> DLL32 FUNCTION WCAPRegisterReceive( lpRcvProcedure AS LONG ) AS PASCAL FROM
> "WCAPRegisterReceive" LIB wcap
You'd probably find easier translating from the "vb" interface.
Here is a post from the old newsgroup, that might help:
<QUOTE, Mindaugas Kavaliauskas, "Using DLL functions", 2005mar18>
Hello,
Juanjo wrote:
> > I Have to communicate with a Fiscal Controler to issue my invoices.. I have
> > a windows 32 bits dll with all the functions I need..
> >
> > I had also a clipper lib which I am using right now with my clipper
> > application. I am now finishing my conversion to xharbour and all I have
> > left to do is this part...
> >
> > the function are like this
> >
> > handle=Openfiscalport ( com port)
> > senddatapacket ( handle, string with data)
> > closefiscalport (handle)
Functions for geting parameter and setting return value depends on
parameter/value type.
PROC main()
LOCAL handle
handle := Openfiscalport(1)
senddatapacket(handle, "data string")
closefiscalport(handle)
RETURN
#pragma begindump
#include "hbapi.h"
#include "FiscalControler.h"
HB_FUNC( OPENFISCAL ) {
hb_retnl( (LONG) Openfiscal(hb_parni(1)) );
}
HB_FUNC( SENDDATAPACKET ) {
hb_retl( senddatapacket( (HANDLE) hb_parnl(1), hb_parcx(2) ) );
}
HB_FUNC( CLOSEFISCALPORT ) {
hb_retl( closefiscalport( (HANDLE) hb_parnl(1) ) );
}
#pragma enddump
<END QUOTE>
... this was a C-based 32 bit dll for a fiscal printer.
As another response, this was also posted by another person:
<QUOTE, Jonas Gediminas, "Using DLL functions", 2005mar21>
Juanjo wrote:
> Hello Jonas
>
> I am currently on a similar aproach. Using what32 calldll, but I cant figure
> out what the parameters are for this function...
>
>
>> shLibKrnl32 := LoadLibrary("KERNEL32.DLL")
>> CallProc(GetProcAddress(shLibKrnl32, "MultiByteToWideChar"), 0, 0,
>
> pcStr, -1, pnPtrWide, LEN(pcStr) + 1)
>
> could you point me how to use the parameters of CallProc ?
CallProc params:
first - ProcAddr, and then all params for Your dll function.
I think You need find what32 calldll help or take a look at source.
<END QUOTE>
Maybe you can get a more closely directed response, if you cannot dope
anything out of this.
David A. Smith
Ron Pinkas
xHarbour functions (and prg level function address as returned by
HB_FuncPtr ) are not directly callable by generic DLLs. You must create a C
function that call your prg function. You will also need to create another C
function to call the DLL, so it can pass the address of your callback C
wrapper.
Ron
"Tim Stone" <tims...@masterlinksoftware.com> wrote in message
news:I6KdnRRQ_cLrSD7R...@giganews.com...
Tim Stone
"Ron Pinkas" <Ron.Pinkas_...@xHarbour.com> wrote in message
news:i810lj$l9$1...@news.eternal-september.org...
Ella
Tim,
Maybe you know the C compiler used to generate that dll... someone
might post sample wrappers.
Ella
> Ouch ... since I'm not a C programmer, that could be a problem.
>
>
>
Tim Stone
much.
Perhaps someone has a reference in writing wrappers for an xHarbour app.
"Ella" <ella....@xharbour.com> wrote in message
news:01d039ab-687f-45bb...@k10g2000yqa.googlegroups.com...
dlzc
On Sep 30, 10:01 am, "Tim Stone" <timst...@masterlinksoftware.com>
wrote:
> My guess it was written in Delphi ... about 8 years ago,
> and not updated much.
>
> Perhaps someone has a reference in writing wrappers
> for an xHarbour app.
You mean other than the one I posted, and the source code for things
like what32?
It won't change the fact that you will have to create a mediator
application that *does not* require xHarbour to be called by the DLL.
I'd suggest that the mediator application negotiate with this DLL,
accept (at least) a file name to place the XML into, and then your
xHarbour app simply parses the resulting file for "FAIL" if the
operation times out or simply does not work.
If you can't drive up the offramp, sometimes you have to drive around
a bit.
David A. Smith
Ron Pinkas
used by the DLL, which in general follow Windows calling conventions.
xHarbour itself is already full of examples for calling PRG functions from C
code, as well as calling DLLs and passing function pointers. Tim will simply
need to find some C programmer which is familiar with the xHarbour API to
implement this interface.
"Ella" <ella....@xharbour.com> wrote in message
news:01d039ab-687f-45bb...@k10g2000yqa.googlegroups.com...
>
Tim Stone
I've been a subscribing member of xHarbour.com since the very beginning
...never missed a beat. You benefit with $$$ for that.
I've also been the recipient of your less then helpful comments in the past,
but I've chosen to support this community anyway with my subscription.
I do have some holes in my knowledge, and I don't pretend otherwise. On the
rare times I ask for some guidance, it would be nice to have a response that
points me to specifics, not some sarcastic retort that says "find someone
who knows what he's doing".
I can't think of anyone more knowledgeable then you about the xHarbour API,
and the examples you mention exist, but apparently it would be far too much
for you to simply take a moment to give me the specfics.
I do find it interesting that you tell me on the one hand that calling a
.prg from a .dll "can't be done" and on the other, you tell me lots of
people do it.
I know clearly where I won't get the help I need. Sorry for even asking.
At least now you have guided me to one course of action. When my
subscription comes up for renewal in a couple of months, I'll break a long
standing tradition and let it lapse ! I always thought we were paying for
support service and the convenience of bundling ! I'll just move to the
straight GNU version and get any help I need on the FWH forum ( which is
VERY helpful, btw).
And in the future, if you don't like the questions people pose, because they
are beneath you, consider the fact that you had many years to develop
comprehensive documentation and it didn't happen. I always check the docs
first, and revert to questions only when I realize the topics / commands /
functions are not documented or the examples that are provided no longer
work.
Tim
"Ron Pinkas" <Ron.Pinkas_...@xHarbour.com> wrote in message
news:i83429$4um$1...@news.eternal-september.org...
Enrico Maria Giordano
"Tim Stone" <tims...@masterlinksoftware.com> ha scritto nel messaggio
news:u8ydnZntM7OfyTbR...@giganews.com...
> I do have some holes in my knowledge, and I don't pretend otherwise. On
> the rare times I ask for some guidance, it would be nice to have a
> response that points me to specifics, not some sarcastic retort that says
> "find someone who knows what he's doing".
I just reread Ron's answer and honestly I didn't find it sarcastic. Maybe a
language problem? Please keep in mind that English is not Ron (nor mine)
mother tongue.
EMG
--
EMAG Software Homepage: http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: http://www.emagsoftware.it/tbosg
The EMG Music page: http://www.emagsoftware.it/emgmusic
Reinaldo
<e.m.giord...@emagsoftware.it> wrote:
> "Tim Stone" <timst...@masterlinksoftware.com> ha scritto nel messaggionews:u8ydnZntM7OfyTbR...@giganews.com...
Tim, perhaps you are bit overwhelm after searching for solutions for a
while. It is comprehensible. I've felt the same way.
But I agree with Enrico; I think Ron gave a perfect/legitimate answer
(regardless of mother tongues).
In other words, perhaps by offering to pay a C programmer with
knowledge of the API, you will get the solution you seek. Possibly
sooner. It only makes sense and it is the fair thing. Don't get me
wrong -that person is not me. :-) I wish I could help but your need
is a bit above my head. Sorry. But keep knocking, the door will open
at some point.
Reinaldo.
Ron Pinkas
I'm sorry if my answers are not always helpful, I can only assure you my
intent is to help. I can not find anything sarcastic in my reply, and again
I would like it perfectly clear that I was NOT intending to appear sarcastic
in any way.
1. PRG functions can NOT be directly called from Generic DLLs, they must be
WRAPPED by C code which uses the Clipper/xHarbour EXTEND API.
2. While such C code is very simple to construct for anyone familiar with
the API it still requires CUSTOM, HAND MADE code tailored to the specifics
of the DLL calling convention and most importantly ARGUMENTS passed.
3. Someone familiar with the DLL conventions must know which Function Name
will be called, and what specific arguments will be passed.
4. He/she must then hand code such C function which accepts that exact
number and type of arguments.
5. He/she must then convert those passed argument values to Clipper/xHarbour
ITEMS.
6. He/she must then PUSH the SYMBOL for PRG FUNCTION to be called, followed
by a NIL ITEM, and finally the converted argument items onto the xHarbour
STACK, using the xHarbour API.
7. He/she will call the xHarbour PRG function using the hb_vmFunction() or
hb_vmDo().
8. If the PRG function returns a value that should be returned to the DLL,
then the xHarbour hb_stackReturnItem() value will need to be extracted into
a matching C type and returned to the DLL.
An example of calling a PRG Function from C code is:
hb_execFromArray() in \xharbour\source\vm\eval.c
The problem with explaining all this is that it is completely redundant for
anyone familiar with the EXTENDED API, yet it' is still of no value to the
average person which does NOT code in C and/or does not know the
Clipper\xHarbour EXTEND API.
I'm sorry, I know that this is still probably not vey helpful but this is
the best I could do.
I was trying to avoid this frustration by directly recommending that you
find someone familiar with the subject to develop the interface code for
you.
Good luck,
Ron
"Tim Stone" <tims...@masterlinksoftware.com> wrote in message
news:u8ydnZntM7OfyTbR...@giganews.com...
Tim Stone
1) I don't learn by turning over the problem to someone else. I'm pretty
decent at looking at documentation and samples and learning new skills.
2) I was confused by your initial response that said it couldn't be done,
then by your comment that a C programmer could do it, and now you seem to be
saying it can't be done, but it can. That is quite confusing.
3) I'd love to know more about the xHarbour EXTEND API, but could anyone
point me to a reference for it ? Supposedly the online reference available
to those of us who do subscribe was supposed to be kept current, but my
searches there yield nothing on functions I see suggested.
4) Hiring someone to do the job would be considered, but so far what I've
seen is "that's not my area of expertise".
5) Support is redundant. I document everything about my software in the
manual, online, and even have demonstration videos. I still get the same
calls over and over. Because people pay me to support them, I suppose
that's fair even if it gets frustrating sometimes.
6) "xHarbour itself is already full of examples for calling PRG functions
from C code, as well as calling DLLs and passing function pointers." I
would love to see those examples. I haven't found them.
Maybe I'm just tired. I have full responsibility for family members who are
approaching death, and also helping my kids' families. Because I have paid
consistently over the years, I didn't think some guidance where the
documentation doesn't exist might be OK. In fact, it was Patrick who
encouraged me to post the questions here in the first place.
Tim
"Ron Pinkas" <Ron.Pinkas_...@xHarbour.com> wrote in message
news:i8fqvl$so7$1...@news.eternal-september.org...
Ron Pinkas
> 1) I don't learn by turning over the problem to someone else. I'm pretty
> decent at looking at documentation and samples and learning new skills.
There's practically infinite pool of documentation and samples when it comes
to the C language, and xHarbour itself is one such huge sample in itself.
This is the very way I learned C myself.
> 2) I was confused by your initial response that said it couldn't be done,
> then by your comment that a C programmer could do it, and now you seem to
> be saying it can't be done, but it can. That is quite confusing.
Sorry, but I never said it could not be done. Here is my original unedited
response:
--------------------------------------------------------------------------------------------------------
xHarbour functions (and prg level function address as returned by
HB_FuncPtr ) are not directly callable by generic DLLs. You must create a C
function that call your prg function. You will also need to create another C
function to call the DLL, so it can pass the address of your callback C
wrapper.
--------------------------------------------------------------------------------------------------------
The above response is as short, concise, definite, and clear, as I can
imagine.
> 3) I'd love to know more about the xHarbour EXTEND API, but could anyone
> point me to a reference for it ? Supposedly the online reference available
> to those of us who do subscribe was supposed to be kept current, but my
> searches there yield nothing on functions I see suggested.
Interfacing and/or extending xHarbour programs with C is not considered a
subject for the xHarbour Reference Manual. This subject is generally
reserved for system level programmers, such as 3rd party extensions
publishers etc. The xHarbour EXTEND API is 100% Clipper compatible and the
CA-Clipper Technical Reference is an excellent starting point. You may also
want to read \xharbour\doc\howtoext.txt. Finally, the complete xHarbour RTL
is an example in itself of extending xHarbour with C, so that practically
every xHarbour function, such as let's say ADEL() is a complete sample.
> 4) Hiring someone to do the job would be considered, but so far what I've
> seen is "that's not my area of expertise".
Sorry, but I can't respond except to guestimate that you should get multiple
replies if you post here a specific job offer with the needed details.
> 5) Support is redundant. I document everything about my software in the
> manual, online, and even have demonstration videos. I still get the same
> calls over and over. Because people pay me to support them, I suppose
> that's fair even if it gets frustrating sometimes.
Sure. :-)
> 6) "xHarbour itself is already full of examples for calling PRG functions
> from C code, as well as calling DLLs and passing function pointers." I
> would love to see those examples. I haven't found them.
There are numerous samples, in source\vm\eval.c as well as vm.c, classes.c,
arrayshb.c, and many many others.
> Maybe I'm just tired. I have full responsibility for family members who
> are approaching death, and also helping my kids' families.
I'm very sorry to hear of your hardship, and wish you and your family the
best.
> Because I have paid consistently over the years, I didn't think some
> guidance where the documentation doesn't exist might be OK. In fact, it
> was Patrick who encouraged me to post the questions here in the first
> place.
Many thanks for your long time support. For what it's worth, the project you
are considering is far from being something that "some guidance" could help
you achieve. Additionally there's no amount of documentation that I could
think of that would help anyone that does not find the existing docs and
sample sufficient. In other words the missing piece is not something we
failed to document but rather a whole set of skills.
Best wishes,
Ron
Tim Stone
better understand C, and study what you outlined. I am heading in that
direction. I do think there will be more need to "extend" xHarbour in a
direction that allows us to stay connected with other systems which is what
this is all about. The problem I'm dealing with is readily, and easily,
accomplished in VB or Delphi. More companies are seeking products that
integrate/interface, and they readily provide examples in VB. Its not the
wave of the future, but rather, the necessity of today.
Thanks.
"Ron Pinkas" <Ron.Pinkas_...@xHarbour.com> wrote in message
news:i8gl07$pj7$1...@news.eternal-september.org...