07-28-2021 04:27 PM
Hi Guys,
I have a ill-formed question. I was trying to use interface messaging but now with Send Message And Wait For Response.vi, which has an output being a variant. Previously, I had been enjoying the fact that interface messages do not couple actors at all (see here, for a related discussion).
I was trying to achieve the same no coupling between actors that interface messaging allows, but now with synchronous messaging based off Send Message And Wait For Response.vi. The issue that I'm currently running into seems to be that since the output of Send Message And Wait For Response.vi is a variant, it would seem to be that the calling actor has to know (i.e, is coupled) to its callee and somehow externally know that the callee is putting a string into its output.
Is there a way to send a synchronous message that doesn't use variants? I was kind of hoping to create a message that outputs the correct data type already.
This might be a poorly phrased question, or even fundamentally wrong that I want that behavior...
Solved! Go to Solution.
07-28-2021 05:29 PM
Well the actor sending the message needs to process the return data somehow, so it kind of has to know what type to expect.
07-29-2021 04:35 AM
Send Message and Wait for Response.vi must have a quite general output, e.g. an variant, so that it can handle all kinds of outputs. But normaly this variant is hiden. In the Do Core.vi of the interface (IF) reply message You pack the outputs of our Vi in a variant and in Send some reply Message.vi, you unpack them again.
It certainly makes sense if the output of your Send reply Msg.vi fits to the IF VI. Because the IF implementing actor simply overwrites the IF VI, it knows nothing about this packing and unpacking process and provides the correct data type, in your case string.
P.S.
I am currently converting a project from abstract messages to IF technique, and I am realy excited about this new possibility in LabVIEW! I am deleting a lot of code from my project: abstract messages, their child classes, member variables in classes, their get and set methods. If the names of IF VIs and connector pane fits to the caller Vis, I don't even have to touch the caller except to add the interface in properties.
07-29-2021 07:38 AM
@Taggart wrote:
Well the actor sending the message needs to process the return data somehow, so it kind of has to know what type to expect.
Yeah, I was thinking about that -- it might be just be the way that it is. No way to do a synchronous message that doesn't output a variant, but instead outputs the type of data needed? That way, the message itself enforces the data type at compilation time and would avoid errors regarding data type conversion.
07-29-2021 08:36 AM - edited 07-29-2021 08:47 AM
You are already doing this, if I understand your picture correctly. You just need to connect the string (...or whatever vi of an actor or an interface defines...) as an output of your send a sync msg.vi .
I attach an example. All my UIs inherit from Viewable Actor. Suppose I want to display a frontpanel of an nested actor in my main UI. I want to resize a subpanel before i do this. My application send a sync msg to NA by calling Send Get Bounds and Position.vi. Do Core calls NA member vi Get Bounds and Position. I have to put data in a variant due to interface of Do Core. In Send Get Bounds and Position i convert variant to concrete data types back. The caller gets the disired data types.
07-29-2021 09:31 AM
Ah, I think I'm about to spot my mistake.
What I had been doing (wrongly, I believe): in the actor core of my root actor, calling "Send Message And Wait For Response.vi" with a reply message as its input. I had not been calling
What I think I should be doing (correct, I believe): in the actor core of my root actor, instead calling the send reply message method of my reply message class. That send reply message method itself can do the data formatting, and it fulfils my desire to not do the data formatting in the root actors code.
That sound right?
See new images.
07-29-2021 09:57 AM
I think you are on the right way, but I did not completely understand your last post.
I describe how I proceed with Reply Messages.