LVOOP Factory pattern problem with child class changing after coming out of case structure

[dpnsw]

I must be doing something wrong but can't work it out.

I am trying to create a child object (see bottom row of Class Hierarchy) using a case structure based on a enum variable.

When I trace the code I have the "ssh" Connection Type and it executes the correct case and I can see that the SSH.lvclass has been created but when it gets to the outside of the case Case Structure it is suddenly an SFTP.lvclass object. The actual wire when I click on it in the diagram also reports as SFTP.lvclass wven though the VI it is going into is definately the ultimate parent object of UserInterface-all.lvclass.

I have tried deleting the wire and putting it in again but it always go back to SFTP.lvclass.

What am I missing?

My class structure is

Actual code

many thanks  David

[tst]

---

@dpnsw wrote:
...but when it gets to the outside of the case Case Structure it is suddenly an SFTP.lvclass object.

---

It should be coerced to connection, since that's the type that's common to both wires going into the tunnel. The VI you call after that is irrelevant, since data type is almost always determined by the source and because inputs of the parent type can take children.

I would suggest changing the wire appearance in the class properties for these classes. That should show you things more clearly.

Also, do a cleanup just to make sure you don't have overlapping code.

If that doesn't help, see if you can upload actual code.

[dpnsw]

Hi tst,

What do you mean by coerced to connection? I just tried typecasting "to more specific class" but that doesn't seem to make any difference.

I have rechecked everything and if I delete the wire from the SFTP object leading out of the case structure then the object wire out of case structure suddenly becomes and SCP.lvclass object. If I delete that wire it then becomes a Portforwarding object and then a netConf object and if I delete that it finally becomes a ssh object.

Basically the wire takes on the lowest value of my enum that feeds the case structure (excluding zero which is what ssh is). At no point does it take on the value of the

I have tried to attach the project zipped to this post but it runs to about 2.5Meg. The problematic VI is the Open.vi under the UserInterface-all class

[drjdpowell · Accepted solution]

---

@dpnsw wrote:

I have rechecked everything and if I delete the wire from the SFTP object leading out of the case structure then the object wire out of case structure suddenly becomes and SCP.lvclass object. If I delete that wire it then becomes a Portforwarding object and then a netConf object and if I delete that it finally becomes a ssh object.

---

I think you may be confusing the wire name (taken from the names on one of the constants) with the wire type (which will be the common parent of all the constants).  Rename your constants, as something other than their class names, and you will see.

[dpnsw]

Hi drjdpowell,

I don't think so (and I say that without alot of confidence because this is my first LVOOP project).

I traced the application running and the key difference between the ssh and sftp classes is that (at the moment) the ssh class has a connection reference inside it whilst the sftp class has nothing.

When I run the VI and use probes.

On the inside of the class structure I can see that the correct object is created and the connection reference is there (It is the 3rd cluster visible in the probe) 1st cluster is the UserInterface-all cluster, 2nd cluster is the connection cluster and 3rd is the ssh cluster.

On the outside of the Case Structure I am suddenly looking at an SFTP object because not only does the wire report as that BUT in the probe window it is called SFTP.lvclass and there are only 2 clusters of data in the probe (no connection reference).

[drjdpowell]

Probes match the edit-time wire type (not the run-time object type) and take the wire name (not the object class name).  Rename your constants.

[dpnsw]

Hi drjdpowell,

OK I have done that and see what you mean BUT when the data exits the case structure whilst the probe tells me that  the name of the probe matches the object name and the Actual data type says both are the correct SSH.lvclass the "Ref-ssh-Conn" variable which is an element in the SSH class is not present on the wire outside the Case Structure.

The screen capture shows 6 probes.

Number [3] is correct and is on the inside of the Case.

Number [4] is the SFTP constant which is not exectued (that is correct)

Number 5 is the wire outside the Case Structure which doesn't have the "Ref-ssh-Conn" any more even though it says it's the correct object.

I have checked the Probe display window and the Ref-ssh-Conn is not there plus I have run the whole VI and I can see all the values polulate. When the ssh connection is made I get the Ref and use the accessor to store it but the probe can't see it and when I try and retrieve it the value is just all 0's and so when I try to confirm the connection is up using "Is Connected.vi" it fails.

Somehow in crossing to the outside of the case structure LabVIEW is gobbling my data and I can't figure out why.

[dkfire]

Can't you show us where these probes are on the block diagram?

And what does the Context Help windows show you when you hover over the wire?

I can't see your code, as I'm "only" on LabVIEW 2014 SP1.

[GregFreeman · Accepted solution]

---

@dpnsw wrote:

Hi drjdpowell,

Number 5 is the wire outside the Case Structure which doesn't have the "Ref-ssh-Conn" any more even though it says it's the correct object.

...

Somehow in crossing to the outside of the case structure LabVIEW is gobbling my data and I can't figure out why.

---

This is completely expected. As was mentioned earlier, they get coerced to the common parent. What it is showing is that the runtime type is correct and is still known, but the probes will not show all the child data. To prove the data is still there, I suggest creating a dynamic dispatch VI in the parent and override it in your SSH child class. You will find that VI gets called and all the data is there. 

I am guessing the probe can't show the child data because the runtime type is decided, well, at runtime, so the probe would have to be dynamic. The best it can do is show "hey, here is the name of the runtime object on the wire. I've got it and know what it is. If you dynamic dispatch, I will call the VI for the correct class. If you call too more specific and cast to the SSH child class, it will succeed. But, the best I can do for the object data in the probe is show you what I know at compile time, which is the base object, because you could have picked any one of the children to come out of the case structure"

Am I correct in guessting the Ref-ssh-connection is in the child class, while the other data the probe shows is in the parent?

[dpnsw]

Hi GregFreeman,

Thank you for the explanation. I do understand that now.

Apologies to drdjpowell that I didn't understand what he was saying.

This time I ran the program and traced again in a VI which I already had and was Dynamic Dispatch (the bit that handles the connection part) and sure enough the probe window reports the correct object and all the data is there. 

My problem was that I had made an error in the program.

This program is a front end to the RENCI ssh library and whilst I had run the connection constructor I hadn't called the connect method so when I tried "IsConnected" it failed. I was trying to work out why and couldn't see the connection reference and was thinking that was my problem.

A very big thank you to everyone who explained things and apologies that I am a bit slow.

For the sake of completeness and in case it can help someone else who has a similar problem, below is the image of where the probes were. Probe 4 is in the SFTP case that isn't shown and probe 6 was on the other side of the final VI in the picture.