Jump to content
News about the LabVIEW Wiki! ×

X___

Members
 View Profile  See their activity

  • Content Count

    38

  • Joined

  • Last visited

  • Days Won

    2

X___ last won the day on May 10 2018

X___ had the most liked content!

Community Reputation

4

About X___

  • Rank
    More Active

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    1995

Recent Profile Visitors

1,019 profile views
  1. X___
    Sending moral support your way...
  2. X___
    OK so the connection to a Jupyter notebook works, great. I can define a variable in the notebook and read its value in LV. Now how do I send something to the notebook from LV? 🙂
  3. X___
    Let us know when it is posted on VIPM's package list.
  4. X___
    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.
  5. X___
    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.
  6. X___
    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...
  7. X___
    Thanks. I'll keep an eye on it.
  8. X___
    @The Q In the manual, you write (7.3 Methods): 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)...
  9. X___
    @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!
  10. X___
    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.
  11. X___
    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...
  12. X___
    No issues with the examples.
  13. X___
    All this being said, now I am completely unable to create a QControl, wherever I try to save it...
  14. X___
    @flarn2006This is the Wizard's code. Not mine.
  15. X___
    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...
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept