09-25-2018 12:27 PM
I've run into this situation a few times and I'm hoping someone can point me in the right direction.
The connector panes match. With the image below you can see the red subVI, which is in a compiled PPL, has a vi reference control as an input and near as I can tell it matches the callback I created just fine. I use this model all the time and already have other callbacks that I use as message handlers that get registered with the same class the red subvi on the right is from.
The only difference I can see between the two references is that the static reference shows as "asynchronous function" while the subvi control is simply "function". I'm not even sure how that difference happens. Other callback references that I've created don't list them as asynchronous when I put them in static reference nodes. All I did to create this VI was right click on the containing library created a new VI. Execution properties haven't been changed and are still set to non-reentrant.
09-25-2018 12:39 PM
From what I can tell it has nothing to do with that asynchronous function listing in the context help. A callback I create in the original library shows up as asynchronous and wires in just fine. Which leads me to thinking there's some issue in the PPL compilation?
09-25-2018 12:44 PM - edited 09-25-2018 01:04 PM
Aaaand I've just noticed that the URL Info type def isn't being namespaced to the lvlibp (So easy to miss that single 'p' absent from the context help). So definitely a PPL compilation issue?
The callback reference has HalComm.lvlibp:Endpoint.lvclass:URL Info.ctl whereas the compiled PPL VI that's supposed to accept the callback registration is just HalComm.lvlib:Endpoint.lvclass:URL Info.ctl
09-25-2018 01:13 PM
My current workaround is I changed the callback definition to accept the plain URL string instead of the URL Info cluster. I then call the same Parse URL function that's called to determine the protocol for the URL within the callback; a duplicated effort but passable for now.