X___

Let us know when it is posted on VIPM's package list.

I'm way above my head here, but are you saying that in principle the "clustering" of multiple control is just a convenience trick or is that bringing advantages (such as access to class properties via property nodes) that would be lost otherwise (defining a facade with multiple controls NOT bundled into a cluster)?

Of course, what's missing for this to be even practical, is more flexible way of grouping objects in LabVIEW (that is, one that allows moving things within a group).

Just to put my questions in context, I have developed a simple (well, relatively) way of adding a tip strip to graphs so that long plot names can be read without having the legend size explode. I was  contemplating migrating it to a QControl, but the layout of a Graph (due to its accessory panels) can be quite random, and if everything (graph and tip strip) is put into a cluster, the problem I was raising above would potentially ruin the day in some UI cases.

Sure, but there are cases like this (vertical "scrollbar" over horizontal "scrollbar", but this works also for the opposite situation):

You can "interlace" two XY Graphs and move their "accessory" panels and not have any problems using either one, no matter which one is on top or in the back:

It's just something to keep in mind before being bitten late in the development process.

Unless I am mistaken, the composite control approach of using a cluster will potentially cause problems if such a control happens to be partially overlapping another control (on a VI panel). I tried to "dislocate" the large scrollbar QControl to emulate a moving subcomponent, and put a String control underneath the transparent part of the cluster (separate control) as illustrated below:

Sure enough, this String control is inaccessible at runtime.

Unless I am missing something, that's a caveat users may want to consider before embarking into complex control design...

13 hours ago, The Q said:

 I have got NI to start a QControl Enthusiasts community group. The Link is:

https://forums.ni.com/t5/QControl-Enthusiasts/gp-p/5383?profile.language=en

Thanks. I'll keep an eye on it.

@The Q In the manual, you write (7.3 Methods):

Quote

Unfortunately, classes do not have the option of accessing methods through the Invoke Node. Therefore, Methods must be public and are only accessible by using the VI on the block diagram of the QControl Class’ owning VI.

I don't see any example of a public method in the examples coming with the toolkit, so I am trying to figure out the intended use.

My understanding is that if I want to add a method to a QControl (say, "Add Element"), I need to provide a VI which the user needs to use wherever they want to call that method, rather than having the convenience of using an Invoke Node and connecting the QControl refnum to it (which would be neat, as this would provide a built-in list of methods). Do I get the idea right?

It sounds like a polymorphic VI for those methods could do the trick of providing a list of methods, and using VIs not shown as Icons would bring us close to an Invoke Node:

The VI above has nothing to do with QControls, it's just borrowed from my own approach to the same problem (of native control enhancement), but it shows what I mean.

If that makes sense, I wonder whether this is something that could be added to the Wizard? Something like "New Method from template" that would add a VI to (or create if there is none) a polymorphic VI and let the user define the number of parameters to use for that specific control (or fix that to one, I could live with either option)...

@gb119 Outstanding work!

Just getting started trying it, so bear with the basic comments:

- The automated kernel path search on Windows fails to find ipython.exe located in C:\ProgramData\Anaconda3\Scripts\ipython.exe

Since I have turned off "Enable automatic error handling dialogs" in Options, I couldn't figure out the problem until I dug down into the diagram (luckily that was trivial due to the nice code layout). Maybe a separate tab with an error indicator could help at that early stage?

- Right now each LabVIEW code instance starts a new kernel and stops it upon quitting. This departs from the broader use case mentioned in your intro (remote kernel) and I am not sure whether that is because of the early nature of the project or because that would require a different design (clearly it would, but would it be fundamentally different?). In particular, the seduction for me would be to be able to interact with an existing Jupyter Notebook (having its own kernel already running) or better yet, spawn a Jupyter Notebook. Is that something you have in mind for the future?

I'll go back to testing.

Keep up this great stuff!

On 4/11/2019 at 9:51 AM, X___ said:

Sounds like getting rid of the checkboxes would kill two birds with one stone...

In retrospect, I believe this would be a nice UI tool to define (contextual) menus: starting from a pre-populated template, unchecking boxes would simply remove that item (or sub-menu) from the final control menu.

On 4/12/2019 at 6:56 PM, The Q said:

I'm working hard to try to understand the problems.

I'm currently stepping through the wizard code node-by-node trying to see the path problems you are seeing. 

One thing I see is when you start the new dialog when a project is not open or the project is not saved, the default folder it picks first is the [LabVIEW Default Data Directory]\QControls\[QControl Name]\[QControl Name].lvclass normally this is in the [User Documents]\LabVIEW Data\QControls\[QControl Name]\[QControl Name].lvclass.  This is why you are seeing the "LabVIEW\QControls" coming up as default.  If the wizard is started when a saved project is open then the default path is relative to the project: [Project Path]\[QControl Name]\[QControl Name].lvclass. 

At the VI you showed above, nothing has been created yet.  It has just constructed the path as the destination of the new QControl class and the indicator for the final path shows you where it thinks it ought to be saved.  However, something very wrong is happening for you if it is keeping the "LabVIEW\QControls" in the path.  At this point it should be the have a folder using the class name and the class. 

The destination should be showing you the class name and folder like this:

The error down stream occurs when the path is checked to exist already.  The full path with the new class should not exist yet.  But if your path is just folders that do exist it will pass the error at the check here:

 

So, now why is it not showing the class name and folder?  Does the QControl Name tab let you past without typing the new name?  If the name is blank I could see this being the cause but the Next button should be disabled until you type something in.  (I found an error I should catch as it does let you just type a space and that would be bad too.)  If you do specify a name, I wonder why it is not being passed correctly.  I can see now that the way it is being passed is not robust enough and that will need to be fixed.

After it starts the scripting, if it fails, it does have to be started over.  This could probably be more elegant but if it does error while scripting there is no cleanup code to remove what was partially created.  Maybe I should add this in the future.

I think I understand what I was doing wrong: I was doing those tests (at least some of them) starting from an unsaved new project. You may want to check for that or strongly warn users against trying to use an unsaved project (you probably do, but even though I read the Getting Started Guide, I can't remember having registered this info).

This being said, the sluggishness remains...

On 4/12/2019 at 7:00 PM, The Q said:

Now on to the sluggish behavior problem.  Can you reach the examples in the Example Finder?  In the Example Finder search for QControls and test each of those out and let me know if it is all of them or just the Tree Selector one.  This will help me narrow the problem down.

@X___, I'm sorry this has been a bad experience for you but thank you for your patience and for being a troubleshooter for me.  With your help we can make this event better.

No issues with the examples.

All this being said, now I am completely unable to create a QControl, wherever I try to save it...

@flarn2006This is the Wizard's code. Not mine.

OK, so I must the nightmare of a developer, as I am facing the same new Qcontrol path nonsense again (with the random failure symptom as well to boot).

Let me recap:

- When choosing where to create the QControl, I typically want to choose a new folder, therefore I create one (*) by either typing the name of a new folder I haven't yet created, or using the "browse" button and creating one,  opening the newly created folder and clicking "Select Current Folder"

- The indicator labeled "The final path will be" then reads: "path of the newly created folder\LabVIEW\QControls"

- obviously the next step fails (but does create the two additional folders (LabVIEW and subforder QControls).

(*) Just for kicks, I tried to NOT create a new folder, and use the "QControls" top folder I have saved a few test QControls in and I then get the following error:

That part seems to "work": the wizard requires an EMPTY folder to proceed.

I looked at the Wizard VI that handles that part of the dialog (Update Save Location.vi), and it seems to be explaining part of my issues:

- if the creation fails the first time, that VI will use the last two hierarchy levels of the "final path" and append them to the proposed creation path!? I am not sure I understand the reason for that, but I understand that it doubles down on a first failure...

Since I can't reinitialize this indicator, the only option is to quit the Wizard and start over again. There must be a better approach...

Sounds like getting rid of the checkboxes would kill two birds with one stone...

I just mass-compiled the user.lib and vi.lib\QSI folders.

Same symptom: when I select a category in the tree, it is highlighted right away, but it takes several seconds before the checkbox is checked (off or on).

On a related topic,  I am a bit confused by the disconnect between selecting an item and checking it off. For instance, in the snapshot below, I have the Array class checked off and the Boolean class selected (but not checked off). What would be the purpose of this?

Nope, I tried it in LV 2018 32 bit to the same effect. That may have something to do with my setup (MBP core i7 16 GB SSD running LV 2018 in Windows 7 - VM in Parallels Desktop with 10 GB of dedicated RAM).

Actually, today I have no such folder issues... 😞

Not sure what's different (beside my MacOS 10.14.4 update).

The lag is consistent and persistent.

Also, when the path selection dialog pops up, it is hidden by the Wizard's window. Again, no biggie but not usual (actually I have seen such a behavior in Matlab executable - it might be a Windows thing...).

Thanks. I first tried on a network drive (that's how my MBP folders appear on the Windows VM) and it failed the same way I described, so I tried to simplify the path using the Desktop.

I just tried a different path (C:\Users\X\Downloads\) and of course that worked... Duh.

Another note: the inheritance dialog has a large latency (several seconds) as far as response to user clicks in the tree is concerned. No biggy but not usual...

Old thread, but since interest in the toolkit was rekindled in another thread, I decided to give it a try.

I am facing some trivial issues. When I try to create a new control, saving fails in several steps:

1) in the folder selection page, I am first told that a Qcontrol already exists where I know there is none:

2) When I try to circumvent this problem by creating an additional folder and select that folder, the wizard is obviously confused as to which folder I am choosing, as illustrated below:

Above, I have created a Q Control folder and selected it, but the final path is bogus...

3) While the above isn't flagged as an issue (yet), creating the class fails (as it should):

As a side note, the scrollbar is frozen, so I can't read the full error message...

Thanks for checking.

Tested on a MBP running LV 2018 SP1f2 64 bit in a Windows 7 SP1 VM (Parallels Desktop).

...

A more granular option than a 3 parts 21+GB download can be found here: http://www.ni.com/gate/gb/GB_EVALTLKTSIGPROC/US

The full list of components in the previous suite (2017) is here: http://www.ni.com/white-paper/54231/en/

Having been updated a couple of weeks ago, I am not sure when the equivalent for the 2018 edition will be uploaded, but it provides a good starting point for a systematic search.

Other versions: http://search.ni.com/nisearch/app/main/p/ap/tech/lang/en/pg/1/sn/n8:28,ssnav:pdl/

For more info: http://zone.ni.com/reference/en-XX/help/371361R-01/lvupgrade/labview_features/

For the record, text wrapping in the context Help window has been confirmed by NI support to work as "expected" which means in the following way:

1) if you have a single paragraph with NO carriage return, the text will wrap:

2) If you have a single (isolated) carriage return ANYWHERE in the text (as after the first sentence in the original post), wrapping is suppressed (that's the "expected" behavior according to NI R&D).

For instance, if I press return after the first sentence in the Description above, wrapping is suppressed:

3) You have to introduce carriage returns IN PAIRS, in order to get a new line AND preserve wrapping:

Of course then you get an empty line that you may not necessarily wanted...

I need some help recovering the trick to use so that a long control description is wrapped properly when resizing the Context Help window (which is not the case in the attached example).

I couldn't find anything about this in the Help or in the intertubes, although I can see that I have used some kind of trick in the past to get it to work in some controls.

Thanks.

This is the closest thread I could find to bring up the fact that there is no LabVIEW 2017 version available in the profile drop down menu.