ViBox - XControls datasheet

[Olivier-JOURDAN]

XControls allow LabVIEW developpers to create smart objects with embedded code. At SAPHIR we use this LabVIEW feature in application we develop for our customer and in our product.

As we have already done with our custom probes, we are pleased to share some of them in a free toolkit.

Once the toolkit is installed, you will find a new control palette: SAPHIR >> Vi-Box - XControl

This palette gives access to the following controls

• Xtab:

This control makes easy for you to manage dynamic page in a Tab control. Each page can be detached from the control in order to be displayed in an independant window. And all independant window can be merged with the original control.

The main features are managed by the XControl. Developpers just need to manage VIs displayed in each page and use method to add a new page to the XTab.

Other methods are available to programaticaly act on the XTab:

• Select next/previous page
• Close page
• Detach page
• Merge all windows
• ...

You'll find the code used for this demo https://forums.ni.com/t5/UI-Interest-Group-Documents/Demo-of-dynamic-tabs-reorder-detach-as-in-moder... in the LabVIEW Example Finder

• PlaceHolderString

This control mimics a string control in which a PlaceHolder string could be displayed when the control is empty.

You'll find the code used for this demo https://forums.ni.com/t5/UI-Interest-Group-Documents/Demo-of-PlaceHolder-string/ta-p/3505504 in the LabVIEW Example Finder

Note for users

Feel free to use thes XControls in your application and give us feedback in comments or in the group discussions.

Requirement

• LabVIEW version : 2009 or later
• Operating System : Windows*
• VI Package Manager from JKI - Community Edition For installation process

[Olivier-JOURDAN]

Added User Manual in document attachment. Note that this documentation is available directly from the help menu of LabVIEW when the addon is installed.

[wirebirdlabs]

Fantastic product! Impressive showing of LabVIEW capabilities!

So, hooovahh and I were talking over here, and had some ideas for the API.

A few "wishes" come to mind, having used this toolkit:

1. Ability to enable/disable whether a user is able to a tab.
2. Ability generate a new tab without giving focus to that tab
3. Ability to explicitly set which tab gets focus based on UID, rather than just 'Previous Page' and 'Next Page' methods.

[Olivier-JOURDAN]

Hey Jack,

Thank you for your feedbacks. Just to do some teasing, we have an internal beta that implement your first wish and some other great features like the ability for the user to rename the tab name, the ablity to disblale the detachable property of a tab...

We will be pleased to give you access to this beta to have your feedback before releasing it.

We wille investigate on the other features you mention.

[wirebirdlabs]

Olivier Jourdan wrote:

                       

Hey Jack,

....

We will be pleased to give you access to this beta to have your feedback before releasing it.

                   

Will kindly take you up on this offer -- already contacted you offline

[jlokanis]

I just came across this and have a few questions:

In my application, I have X number of VIs running without showing their FP.  I currently use a VI with just a sub-panel to display one of these VIs at a time.  I have a separate VI with a listbox of all the VIs running (but not displayed) that the user can select to see the FP in the VI with the sub-panel.

What I want to do is use your control instead of the sub-panel.  I still want all my VIs to run in the background without their FPs being visable, but when the user chooses to open the 'viewer' window, I run a VI with your control in it and I add a tab for each hidden VI.  I then let the user navigate the various FPs using your control.  I do not allow them to close them but I do need to programmatically close them if they stop for other reasons.  I also want ot be able to select one for display programmatically.  Finally, I want to be able to name the tabs dynamically.

Is any/all of that possible?

Is there a limit to the number of 'tabs' I can have?

I would also be interested in the beta.

thanks!

-John

[jlokanis]

Ok.  Played with it for a while and I think it will work for me with a few exceptions.  As noted above, we need the ability to programmatically set which tab is selected.  Or as Jack put it:

"Ability to explicitly set which tab gets focus based on UID, rather than just 'Previous Page' and 'Next Page' methods."

I could live with the current implementation if I had the ability to ask it which tab has focus so I could call next page in a loop and check until the correct one was displayed.  But that would be a crude solution.

I also found a few bugs.  The 'PagesName' property is always an empty array, no matter how many tabs are displayed.  Also, I think its name is a typo.  Shouldn't it be 'PageNames'?

The GetRefByName method always returns a value of not found and the SubPanelViRef is also always Not A Refnum.  I suspect both of these bugs are related.

The result of these bugs is it is impossible to prevent adding duplicate tabs without managing the tab list outside of the control.

If you try to manage the tab list outside the control, you must remove items from it when the tabs are closed.  Unfortunately, the close event only fires if the tab is docked.  If the tab is detached and you close it, the close event is not fired and you cannot clean up the tab list.

Finally, the ClosePage method has no inputs.  I need to tell it what page to close.  I am not sure I understand how this is supposed to work.  My assumption is if the inserted VI closes, it is supposed to send the VI hosting the tab control a message to close its tab?  But how can it do that if there is no input to the method?  It appears that it will simply close the currently selected tab, but what if the VI that is closing is not hosted in the currently selected tab?

If any of these issues are fixed in the beta, I would be happy to test them and any new features.  As it is now, I think I will have to wait for further improvements before I can use this control in my application.  Keep up the work and let me know if I can help in any way.

-John

[jlokanis]

One final comment, if you only have one tab, you are still allowed to close it.  But since you cannot detect that there are no tabs left, you cannot take the appropriate action and close the VI that contains the tab control.

I did look at the Example.  It does not use any of the features that I found bugs in.

[wirebirdlabs]

jlokanis wrote:

                       

Ok.  Played with it for a while and I think it will work for me with a few exceptions.  As noted above, we need the ability to programmatically set which tab is selected.  Or as Jack put it:

"Ability to explicitly set which tab gets focus based on UID, rather than just 'Previous Page' and 'Next Page' methods."

                   

Yes, I would still love to see this feature!

[Olivier-JOURDAN]

Hello John, Hello Jack,

I'm still really pleased to hear feedback from XTabs users.

We have a beta that is almost ready to be released. In particular, we have to work on the documentation.

The beta provide lot of new features and has been used successfully by Jack. Following the discussion we had during this beta test, we added the ability to set the focus on any page you want using his unique name. Note that bugs you mention should be also fixed

Feedback and beta test before release is more than welcome

@John : Please e-mail at support@saphir.fr I will send you tha beta package and a project implementing most of the new features.

@Jack : are you interested to give a try to this new version ? Note that we have fix the SLA issue we spoke about early this year

Have a great day,

[wirebirdlabs]

Olivier Jourdan wrote:

@Jack : are you interested to give a try to this new version ? Note that we have fix the SLA issue we spoke about early this year      

Of course! Send it on over; you know where to find me! 🙂

[drjdpowell]

Hello Olivier,

Any idea when the new version will be released?

[Olivier-JOURDAN]

Hello drjdpowell,

We've been really busy these weeks, but we hope to have a final version before the end of the month. These version should fix issues fond on the beta by John.

I'll post on this thread as soon as this version will be available.

Thank you for your patience.

[Olivier-JOURDAN]

Note that the new version of ViBox - XControl is now available through VIPM. Note that you probably have to check for new packages manually to have access to the version 2.1.0.60.

The new user Manual is availble in attachment of this document.

Special thanks to John for his beta test and feedback on this new version

[massimo1167]

Thank You Saphir, thank You Olivier, excelent job!

I'm testing ViBox XControl because I'd like to give my user interface a very useful capability.

But before to embed ViBox XControl into my application I'd like to understand the best way to usit and verify the impact on the stability of my application.

After several tests with the adaptation of parts of the application, I have found a couple of issues:

1) Slowdowns in closing the tab, resulting a error timeout 5042 (Error 5042 occurred at Timeout arrêt VI dynamic).

    When user event "PageClose" is  fired, the vi will be closed with "PV_Gnl_DynamicallyStopEventWhileLoop.vi"; this vi return the error 5042, but I don't know why.

    "PV_Gnl_DynamicallyStopEventWhileLoop.vi" is password protected and I'm not able to understand the reason of timeout.

     May we access to this vi?

2) In your example "PV_Dlg_ViewOnePicture.vi", You call invoke node "FP.close" to close the front panel.

     If I leave this statement I get an error "Error 1149 occurred at Invoke Node in PV_Dlg_DisplayGraph_UI.vi:6940002"

     Possible reason(s): LabVIEW:  Cannot close or set the state of a closed front panel. The front panel must already be open before you close it or set its state.

     Method Name: Front Panel:Close

Is it possible in the future, discard a closepage request? When I select "x" to close page, a user event is fired,

but I can not refuse the request because now the page is already closed and I can only close the VI.

I hope with your help to be able to solve these problems.

Best reagars

Modify1 :

After my post, I build an .exe file of my example, and in this case, although the closure is slowed down, the closure does not return the timeout error.

This is one more reason to understand what "PV_Gnl_DynamicallyStopEventWhileLoop.vi" does.

Modify2 :

I tried to investigate the reasons for the timeout and I discovered that:

a) My VI called dynamically takes approximately 100 ms from the command "Stop <user event>" to the last instruction of VI "Unregister for events."

b) In development mode, "PV_Gnl_DynamicallyStopEventWhileLoop.vi" to stop my 7 instances of the dynamic VI takes from 4900ms to 6500ms.

    The first instance takes 4900ms instead the following from 6500ms to 5900ms.

c) In the runtime mode, "PV_Gnl_DynamicallyStopEventWhileLoop.vi" takes from 1962ms to 1100ms for stopping the seven instances of my dynamic VI.

    In this case the times are always decreasing.

[Olivier-JOURDAN]

Hello massimo,

It's great to hear tha our toolkit could be useful for you.

Concerning the issue you are comming across, the error is due to a "timeout" fired by the function "PV_Gnl_DynamicallyStopEventWhileLoop.vi". This fonction is asking to the VI displayed in the closing tab to stop. This may normaly take less than 100ms in the example provided with the XTab. A Timeout error is fired if the VI is still running 5000ms after asking him to stop. This should normaly never happen. If it happen you should investigate why the stop sequence is so long. Note tha you can replace the way VI is managed (load and stop) and implement your own method (As a side note I think that VIs of the example should be not protected. Think it will be done in the next release of the toolkit).

Concerning the abality to discard the close page event. As far as I know, it's not possible with the curent LV version to create filtered user event. It would be probably possible to implement this behavior, but not sure to have a user friendly solution. Anyway you can perhaps use the closeable property to do a workaround. Let me know if it could be a solution for you.

Have a great day.

Olivier

[massimo1167]

Thanks Olivier for your reply,

as I wrote in previous post, my VI takes about 100ms from the command "Stop <user event>" to the last instruction of VI "Unregister for events", maybe it takes more time to close ref as it use a lot of memory.

Why in the example, to run the reentrant VI, is used  "Auto Dispose Ref = TRUE"?

I'd like to manage by myself the way to load and stop the VI, for this reason I'd like to take a look inside to

"PV_Gnl_DynamicallyStopEventWhileLoop.vi", but as I told You, this is the only VI to be protected and then I don't know I just have to handle the way to close the reentrant VI , or if I have to manage something inherent xtab.

May You send me a copy of not protected example VI as it is planned for next release of the toolkit.

Thanks again and congratulations for the excellent work.

Have a nice day

Massimo

[Olivier-JOURDAN]

Hello massimo,

Here is the diagram of PV_Gnl_DynamicallyStopEventWhileLoop.vi

As you can see, there's no magic things happening here. We just generate the "stop" user event that ask VI loaded in Tab to stop. When this is done, we check that the stop is effective with "Wait for VI Close". There's nothing related to XTab.

Next toolkit release will provide this VI without password.

AutodiposeRefVi is set to TRUE to have the Vi ref released properly at the end of the VI execution.

You can change the way to handle the Load and Stop of the VI displayed in XTab but I don't think this will change the time your VI take to stop. By the way, could you confirm that the original example is working right ?

Great day,

Olivier

[massimo1167]

Thank You very much for your quick reply.

The original example i working right, now my implementation too, I've just increased the time out even if in runtime mode, the time to stop is about 2000ms.

Maybe the timeout is related to the amout of memory used by the VI to closed.

I'm waiting for next release of this great toolkit.

Have a nice day.

Massimo

[Tecloder]

Hello Olivier,and thanks for toolkit,it's really useful.

And I still have some question about  "PV_Gnl_DynamicallyStopEventWhileLoop.vi"

To put it briefly, my project is consist of main.vi and sub.vi

main -  scan device in connected,and list it

sub - device's parameter display&control

In normal operation,it will be following steps

1.Open main.vi

2.Open some sub-vi with xtab

3.Close main.vi

4.UI close

In sub.vi , i choose "OpenG - Read/Write Panel from INI"

to save/load my sub-data. just like "preset"

and now if i open main.vi and

1.open sub.vi and do nothing

                    or

2.open sub.vi and run Write Panel from INI.vi(write)

then close main vi,UI will fiinished succeed without any error

but

if when i open sub.vi and run "Read Panel from INI.vi"

after i close main.vi , i always got error 1

============================

Error 1 occurred at Generate User Event in PV_Gnl_DynamicallyStopEventWhileLoop.vi:2->Main.vi

Possible reason(s):

LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.

====================================

here's error part of my code(i'm sure that error was created by this part)

i've try open two sub.vi at the same time

"do nothing"

"run Read Panel from INI"

and close mai.vi

error always occur when the sub.vi(have run Read Panel from INI)'refference

get in to the PV_Gnl_DynamicallyStopEventWhileLoop.vi

i've checked sub-vi's refference,and it's alwayse keep the same value after running "Read Panel..."

I don't know how to fix the error,may you told my why will the error occur?

sorry for my poor english,and thanks again for your toolkit

have a nice day

[Tecloder]

[Olivier-JOURDAN]

Hello Tecloder,

Actualy, your issue is not related to XTab. "PV_Gnl_DynamicallyStopEventWhileLoop.vi" is used to stop VI displayed in tab when a tab is closed or when the application stops. In the example provided with the XTab, we choose to communicate with these VIs using a UserEvent. If you look at my previous message, you can see how the UserEvent is get back from the VI we want to stop. Your error seems to be due to a wrong value in GenerateUserEvent.

I encourage you to check the value of the UserEvent on both sides of your code. Why in some different conditions this value seems to be wrong.

Anyway, I'm not sure that your issue is related to the OpenG VI.

Finaly, I'd encourage you to check that in any case the VI displayed in the Xtab are correctly closed when you stop your app (i.e : check if there are not reserved).

Have a good day.