03-19-2018 06:43 AM
Hi,
I have an issue that seems related to the otherwise awesome xTab toolkit from Saphir.
I created an application that opens multiple tab pages, which are really asynchronous running clones of one VI.
When closing a tab with the mouse, I simply receive a user event and then instruct the clone to terminate. This is where things go wrong: as one clone VI terminates, Oftentimes another clone VI crashes and simply disappears. As if the garbage collector thinks that the crashing clone is owned by the one I terminated. This behaviour is pretty consistent, but I cannot reproduce it 100%. If I undock the tabs, the behaviour disappears. However, closing an undocked window can still invoke a docked tab to crash!
I created a test project, but haven't yet managed to make that reproduce the issue.
Any suggestions, people?
BTW. Is there a way to retreive the owner of a vi ref? Maybe that would reveal that the garbage collector is to blame..
Aart-Jan
Solved! Go to Solution.
03-19-2018 11:53 AM
Spent yet another day on it, but finally achieved some progress!
I noticed that a terminating independent VI will kill all xtab async VI references! This independent VI reads the xTab properties through a global variable of the xtab reference.
Using LV2015 32bits
03-19-2018 12:40 PM - edited 03-19-2018 12:46 PM
Got it pretty much figured out:
Any top level VI that uses property nodes that return VI references of the tab windows will subsequently kill those VIs upon termination. That seems pretty nasty. I am not yet sure if there are more property nodes that invoke this behaviour.
I cannot reproduce this simply by using the VI references without xTab, so it is not Labview built-in behaviour.
Aart-Jan
03-19-2018 01:12 PM
Hello Aart_Jan,
As far as you are the first to describe this behavior, I really like to find and fix this issue.
I'm not sure to get the whole picture of your dynamic loading mechanism. Anyway, the behavior you are describing let me think about an issue related to VI Reference lifetime management.
When you create a new tab which part of your code does the dynamic run of the VI displayed in the tab ?
Did you glance at the project example provided with the XTab ? If so does your loading mechanism is really different ?
Look forward to hearing from you.
03-20-2018 07:47 AM
I use GOOP classes that have an asynchronous VI (the ActiveObject template). Each instance of the class has its own (clone) asynchronous VI that is ideal for creating interfaces in xTab. As these VI's are called by reference, they are top level. When I call one of the before mentioned property nodes in one of these (top level) VI's, all returned VI references will be killed once that calling VI terminates.
So it will be easy to reproduce: make a VI that opens some tabs in xTab using a call by reference reentrant VI. Call one of the offending property nodes and then terminate that tab/VI. So I did: see attached example.
03-20-2018 08:55 AM
Armed with my new knowledge I was able to remove the bug from my own application. I simply removed the property node Get/Set ActivePage from the code that is running in the tabbed top-level VI or any of its subvi's.
03-21-2018 04:20 AM
I glanced at your sample code and reproduce the issue. That's a really weird behavior !
I glance at XTab code call when properties are called and can't figure out why these calls cause other VIs to terminate when aborting the one that did the XTab property call...
Note that the behavior depends on the property called and on the tab position in the XTab.
Question : does the call of XTab properties inside the inserted VI is important for you ?
03-21-2018 07:55 AM
@aartjan wrote:
I cannot reproduce this simply by using the VI references without xTab, so it is not Labview built-in behaviour.
Aart-Jan
And yet you could! The issue lies within the Inserted VI property from the subpanel class.
That super naughty property kind of transfers the inserted VI reference ownership to the VI calling the property node.
So basically in your case, when you use the GetAllViRef property node in one of your pages (that calls into Inserted VI inside the XTab), all the pages VIs are then owned by that very page, so when this latter exits the memory, all the other pages are dumped at that time.
I can only echo what Olivier recommends - your page VIs should not know about the XTab and should be pretty much stand-alone. It creates a high coupling between the pages and the hosting VI and in this case messes up with the pages lifetimes.
You have many ways to achieve what you want, one of them would be to send a user event to the main VI that so it returns the information needed about the pages and just forwards them back to the requesting page.
--Eric
Eric M. -  Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer -  Certified LabWindows™/CVI Developer 
Neosoft Technologies inc.
03-22-2018 03:57 AM
Thank you Eric for the highlight (+1 kudo 
).
I wasn't aware of this LV "feature" (shame on me 
)
Good day everybody
03-22-2018 06:29 AM
If I can avoid a 2 hours (or way more) headache like I had when I discovered this, then it is my pleasure 🙂
Eric M. -  Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer -  Certified LabWindows™/CVI Developer 
Neosoft Technologies inc.