I just updated my wwWebSvcGenerator because the webservice that my VFP application connects with just disabled TLS 1.0. I am able to connect now with the web service but my code is failing on calls to wwDotNetBridge.GetProperty() whenever a .net object property is supposed to be returned.
loCoursePresentation = loSvc.oBridge.GetProperty( loResult, "resultObject" )
I discovered that the code seems to work when I change the code to instead call to wwDotNetBridge.GetPropertyEx()
loCoursePresentation = loSvc.oBridge.GetPropertyEx( loResult, "resultObject" )
Is this the recommended method? It's not throwing any exceptions but I haven't had the time to step through all the code to ensure I'm getting all the correct values back yet.
![](https://weblog.west-wind.com/images/Sponsors/Websurge-Display.png)
What is the error when it fails?
It should work with either. In fact, there should be no reason to use the Ex
version as even the nesting has been integrated into the non-ex version. Unless you're using a really old version of the WSDL generator.
+++ Rick ---
It's definitely failing consistently. The error reported is:
Here's the code that causes it:
loCoursePresentation = .NULL.
loResult = loSvc.GetCoursePresentation( tcCourseNumber, tcFiscalYear, tcPresentationNumber )
IF this.tiCallSucceed( loResult )
*!* loCoursePresentation = loSvc.oBridge.GetPropertyEx( loResult, "resultObject" )
loCoursePresentation = loSvc.oBridge.GetProperty( loResult, "resultObject" )
IF TYPE([loCoursePresentation]) = T_OBJECT
This.oCoursePresentation = loCoursePresentation
If I change that to:
loCoursePresentation = .NULL.
loResult = loSvc.GetCoursePresentation( tcCourseNumber, tcFiscalYear, tcPresentationNumber )
IF this.tiCallSucceed( loResult )
loCoursePresentation = loSvc.oBridge.GetPropertyEx( loResult, "resultObject" )
*!* loCoursePresentation = loSvc.oBridge.GetProperty( loResult, "resultObject" )
IF TYPE([loCoursePresentation]) = T_OBJECT
This.oCoursePresentation = loCoursePresentation
The call works fine.
loSvc is the InterfaceAdapterProxy created with:
loSvc = CREATEOBJECT( [InterfaceAdapterProxy],[V4] )
I can't recall when wwDotnetBridge was updated but at some point the two methods were consolidated to work off the single version. Note the non-ex version is case sensitive, while the ex version is I think and that might account for the difference. Make sure you match the API method you're calling exactly.
Also it returns only Properties not Fields. If the type is named resultObject
I suspect that's not a property, but a field based on naming convention.
It's different mechanisms. One is using the base .NET reflection retrieval by type and name lookup which is more efficient but more finicky as it has to match more closely based on visibility and exact name. The other uses InvokeMember()
which is more generic but less performant and handles a few things like case sensitivity and different binding methods for more lenient access, plus the hierarchical syntax. The new version of the non-ex version handles the hierarchical syntax now by forwarding to the ex version if I recall but the base method call still goes through the different APIs.
+++ Rick ---
The webservice documentation states the following for the server responses:
ServiceResult
ServiceResult is used to encapsulate responses from the server.
It contains two properties: string[] resultMessages and object resultObject. resultObject will contain the object returned by the request, and will vary from operation to operation.
The documentation describes resultObject as an object and this makes sense, because depending on the resultObject requested it usually has both fields and objects.
Bottom line for me right now, is that it's working fine with every GetPropertyEx() call so I'm happy. Thanks for your assistance.
![](https://weblog.west-wind.com/images/Sponsors/MarkdownMonster-Display.png)
LOL - yeah that's my bad!
It's been some time since I've looked at the Proxy Generator and honestly I've forgotten how much of that works.
It's probably due for an update so the latest wwDotnetBridge is used etc. but hard to justify since SOAP services are increasingly rare these days.
+++ Rick ---