XML communication with another program

[TimStone]

I am interfacing with a parts ordering program. The communication via the web is done by the program, and it returns data to my program in XML.

Antonio provided excellent assistance in getting the calling routine setup. First I must do a connection to their program ... and that works fine.
Then I must do a request for a catalog which their program then displays. I find the item I want and "export" it. It is passed to a routine ( CalledBack( cXML, nSize ) ) which is the document ( XMLDoc :LPSTR; Size :INT )

To do a lookup, I use the following routine:

Code: Select all  Expand view  RUN

// Lookup items in the WorldPac catalog
FUNCTION wpacLookUp( cWrkOrd, cVehVin )  //  wpac
 
 MEMVAR cRet
 LOCAL cFndVin := SUBSTR( cVehVin, 1, 10 )
 // Request the catalog 
       ShowCatalog( cFndVin, "Auto Shop Writer" )
 // Now lets parse the data
 IF MsgYesNo( "Save the part to the workorder ?" )
   ParseCatalog( cRet, cWrkOrd )
  ENDIF    
RETURN NIL

ShowCatalog( ) passes a VIN to the other program which then pops up the catalog search system. Once I have selected the parts, and press the Export key, it places an XML doc into the CalledBack value which is as follows:

Code: Select all  Expand view  RUN

// Procedure( XMLDoc :LPSTR; Size :INT )
FUNCTION CalledBack( cXML, nSize )
  MEMVAR cRet
  MsgInfo( cXML )
  cRet := cXML
RETURN NIL

here is the embedded c code for callback

Code: Select all  Expand view  RUN

void __declspec(dllexport) RcvProcedure( char * szXML, LONG lSize )
{
   hb_vmPushSymbol( hb_dynsymGetSymbol( "CALLEDBACK" ) ); // we push the symbol of the function to call
   hb_vmPushNil(); // we push nil for a function, a codeblock for Eval, an object for a method
   hb_vmPushString( szXML, strlen( szXML ) );
   hb_vmPushLong( lSize );
   hb_vmFunction( 2 ); // two parameters supplied to CallBack()
}

This works fine, and the value returned by cRet is the xml document with the proper information. The second part of that function sends the document to my parser which decodes it and places the needed values in a database for further use.

So here is the first problem. I have to delay the decoding because I cannot be sure if the xml doc is yet available to CalledBack( ). I use a YesNo message function for an artificial delay. It would be nice to just be able to pause until I know there is a message in called back. Any idea how to do this ? BTW, CalledBack is actually triggered by the other program.

Secondly, apparently they will send multiple documents, one for each item selected in the catalog, instead of combining them into one XML. I need to be able to capture each one.

I know this is perhaps somewhat vague. However, your questions / comments will help get to a solution. I offer this not only for my help, but I'm sure others have to interface with other programs, and decode XML docs, so perhaps this will help them also.,

[ADutheil]

You can enter a loop monitoring the content of cRet. Your document is something like
<?xml version="1.0" encoding=....?>
<Firstmarker>
whatever
</Firstmarker>

You keep looping untill </Firstmarker> shows up or you reach a timeout of your choice.

[TimStone]

I'm not sure how that would work in the example I gave you. It also requires a continuous loop to parse the xml code.

[ADutheil]

I was thinking about someting like

FUNCTION WaitToParse
LOCAL nTimeOut := 5
LOCAL lRetu := .F.
LOCAL cMark := ""
LOCAL nTok1 := 0

WHILE nTimeOut > 0
IF !empty( cRet )
nTok1 := aTToken( cRet, "<", 2 ) + 1
cMark := subStr( cRet, nTok1, aTToken( cRet, ">", 2 ) - nTok1 )
IF len( cMark ) > 1
cMark := "/" + cMark
IF cMark $ cRet
lRetu := .T.
EXIT
ENDIF
ENDIF
ENDIF
WaitSeconds( .2 )
SysRefresh()
nTimeOut -= .2
ENDDO
IF nTimeOut = 0
msgStop( "TIMEOUT! TRY AGAIN" )
ENDIF
RETURN ( lRetu )

in a MT system.

[TimStone]

I actually handled this a bit differently, but the idea came to me after your post, and as I was thinking about what you contributed.

In this case, the .dll actually calls a function in my program where it stores the xml document. The problem happens when it chains several calls to that function, and each time sends a new document. The timing was such that it was very quick.

I changed this by modifying the called function. Each time it is called, the document it receives is added to an array. At the beginning of the process ( ie. catalog lookup ), the array size is set to 0. Each time it is called ( for example if there are 3 parts returned from the catalog, it is called 3 times, once for each one ), the document is immediately added to the array. Once that process ( the lookup ) is finished, the array is sent for parsing of each element. It works.

Thanks for your input. It helped me get past this hurdle.

Tim