search

JKISoftware / JKI-State-Machine-Objects

Object-oriented framework for LabVIEW based on the JKI State Machine
BSD 3-Clause "New" or "Revised" License
95 stars 54 forks source link

Cannot launch two dependencies of the same "given name" even after destroying reference of first one #72

Closed nathan-murphy closed 2 years ago

nathan-murphy commented 3 years ago

Describe the bug Stopping a dependency does not clear its Name from the FQN Array, so if you try and launch any subsequent dependency it will have a different name from the one given. This would be fine, but the "FindDependency" function using Name as key will only look at the qualified names, not the given names.

To Reproduce Steps to reproduce the behavior:

  1. Create an SMO (owner)
  2. Launch a Dependent SMO named Child
  3. Stop the Dependency and destroy the reference
  4. Re-launch a Dependent SMO named Child
  5. Try and locate that Dependency using the "FindDependency" using Name as the Key
  6. Get error 42 because the dependency can't be found

Expected behavior I would expect FindDependency using Name as key to search the "Given Name" instead of the FQN.

Additional context Using the 1.4.0_beta branch

francois-normandin commented 3 years ago

Hi @nathan-murphy,

I've tried to reproduce the issue you describe, and the closest I get is to generate a warning "42" when I try to stop and destroy the reference while not "owning" the reference. However, I can get the child to be launched again, and found by name.

My test was performed in SMO 1.3.0 build 56 (latest release), so I've attached the test code for you to run and compare on 1.4beta.

Are you perhaps using the Public API's Stop/Destroy commands? If so, this is a "no-op" call because only the owner can stop and destroy a dependency's reference. If this is the case, you would be creating a second object named Child, which takes a different name. ("Child__001")

Here's a screenshot of the test VI I created. Please let me know if this captures the essence of your issue. Since the dynamic dependency gets "owned" by the caller, only the caller can perform a stop/destroy state change request. To ensure that the owner manages the lifetime of its dependency, only a protected method can be called to terminate the dependency. (Under the hood, it provides the "shared key" that verifies ownership relation)

image

If it does not work in 1.4 beta, then something changed and it's a bug introduced after 1.3.0 If it is working, then I assume my transposition of your report in test code is missing the target. Maybe you can provide example code that reproduces the issue?

best, Francois SMO Issue 72.zip

PS. Please be aware that the beta version 1.4.x might still not have all its features make it to production release. There are configuration management features that are still not fully vetted, or desired as presented. Any feedback on those features would be appreciated.

nathan-murphy commented 3 years ago

Thanks for the additional context.

I tried running this in the 1.4 beta - here's my front panel output: image

Some notes - I modified the SMO base class that is present in the 1.4 branch for the following modifications:

This was all done in LabVIEW 2020. I'll include my source code as well. SMO Issue 72 using Nate's 1.4.zip

francois-normandin commented 2 years ago

This issue is semi-related to Issue #85 , which is fixed in 1.4.0.69.

There was a mishandling of the dictionaries related to Fully Qualified Names in the Unregister Subsystem method keeping track of the name collisions.