Jump to content

The Q

Members
  • Content Count

    34
  • Joined

  • Last visited

  • Days Won

    4

The Q last won the day on April 14

The Q had the most liked content!

Community Reputation

11

About The Q

  • Rank
    More Active

Profile Information

  • Gender
    Male
  • Location
    Northern Utah

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2018
  • Since
    2007

Recent Profile Visitors

1,098 profile views
  1. Well I guess you could pass the reference to each button and the slider individually into the constructor VI without them being in the cluster. You would have to add the references to the QControl class through a manual bundle in the constructor and edit the Event Handler accordingly. If that is the case I would recommend starting a new QControl and inheriting from Slider and then passing in the slider reference as normal. Then pass the references for the buttons as extra inputs with manual bundle. That way each button and slider can be positioned separately.
  2. The last straw that made me abandon XControls forever and create the QControl Toolkit was the trouble I was having using XControls with Actor Framework and PPLs. At first I just encountered weird behavior problems, then sporadic crashes, and finally the inability to build the application. With more work and headache I probably could have found workarounds and continued using XControls but it just wasn't worth it.
  3. True with any controls. Just make sure the z-order makes sense. In your case you probably want the string control in front of the cluster holding the scrollbar, instead of having the string in the cluster with it.
  4. Thank you for asking a lot of good questions. I have got NI to start a QControl Enthusiasts community group. Some of your questions and suggestions would make great topics there if you are willing to add them. The Link is: https://forums.ni.com/t5/QControl-Enthusiasts/gp-p/5383?profile.language=en
  5. I tried to make it so you could do it from a new project but it always had problems (that is why I warn against it in the tutorial, it wouldn't work every time). I'm going to put some time into making this better.
  6. That is true. I have thought about using the "Not shown as Icons" to get the same look as a Invoke Node or even creating an Xnode (but I have never created one of those before). A polymorphic would give you a list of the VIs included in it but not the ones inherited from the class hierarchy which are available too. A cool tool that does give you all of the methods available is MGI's Class Method Browser (MGI's Website | LabVIEW Tools Network). I do need to add some more templates and scripting. One of which would be to help make Properties from the items in the State Data. New Method templates could be helpful too.
  7. Weird because the wizard calls the same code the examples call.
  8. As I stated before, I don’t know what the replacement for XControls will look like in NXG. However, the work you spend writing XControls now will likely have to be repeated when rehosting that functionality to NXG later. QControls are all regular, plain G under the hood and therefore there is a higher likelihood that they could be portable to NXG. I have attempted to port the whole toolkit to NXG a while ago but have not tried recently. I don’t know what it would take to make a NXG QControl Toolkit but I do think it will be possible. If it can be done, then time spent now on creating QControls might still be usable in NXG.
  9. 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.
  10. 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.
  11. @flarn2006 sorry I didn’t know about your tool. It would have saved me time. I created one of my own. Your’s looks better though and has more features. @Francois Normandin and I discussed the lag on first call and I am adding a fix to do a post install mass compile to see if that fixes it. @X___, I’m sorry there have been so many problems. I’ll take a look at the folder code tonight. As for using the checkboxes, the wizard uses the Tree Single Selection QControl to be seen as an example. I’m not sure why the performance is so bad for you as I have not seen that anywhere else. If it is better for user experience, I could remove the use of that QControl in the wizard. The wizard also uses the Steps QControl for the tab disabling and the StatusHistory QControl for the status string during the creation scripting process. Has there been issues with those as well?
  12. Well, I have a similar computer but I’m not running as a VM. Could that be it?
  13. I can’t seem to duplicate the lag or the popup dialog problem. I wonder if it has to do with your LabVIEW being 64bit. I don’t have LabVIEW 64bit installed right now. I’ll have to install it and give it a try.
  14. I tested to a shared folder on my laptop and it worked fine. Not sure what the folder problem is.
  15. I'm glad you were able to figure out the folder problem. It was working for me on the desktop. You say it has trouble on a network drive? I'll have to find some way to test that. As for the tree, I don't see the same latency. Is it the same every time you launch the wizard?
×
×
  • Create New...

Important Information

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