Jump to content
News about the LabVIEW Wiki! Read more... ×

All Activity

This stream auto-updates     

  1. Yesterday
  2. flarn2006

    Hidden editable pixmap control

    What private nodes specifically?
  3. Paul Schumacher

    Launching a new test data sharing platform

    Hi everyone! I'd like to announce the launch of a new service that could be of interest to you. Over at Launcher while building a rocket engine we built a software workflow that worked so well we decided to turn it into a service. We call it CURVE. It’s a tool to visualize, share and manipulate DAQ data in the cloud. We make it easy to share your experiment results online, either privately with your team or for a public audience. We’ve just added support for National Instruments / LabVIEW TDMS files, so giving your experiment data a home online is as easy as drag & drop. We’re now looking for beta-testers, we’re offering a free year of usage after then end of the beta phase for our active early adopters. Check it out! Feel free to shoot me an email if you have any questions: paul@getcurve.io. Thanks for listening! Paul
  4. Rolf Kalbermatter

    Hidden editable pixmap control

    This existed back in LabVIEW 3 already (although you only could create it on a frontpanel with some super private nodes that came available with the new VI server interface in around LabVIEW 6 and crashed LabVIEW back then quite quickly too if you got that far) and I"m pretty sure it is from the Mac only version of LabVIEW alrady (2.x). In fact it seems like the bitmap edit control in the old icon editor, which looks exactly like that, but that icon editor was a dialog written in C inside the LabVIEW core. So while it is functional enough to be used with the LabVIEW internal C dialog API it obviously never received any extra love to adapt it to the property node interface that was later created and to make it useful as a generic LabVIEW control. Since the old default icon editor is still an option to choose, I'm sure that removing it from LabVIEW at this point is also not an option. But making it a fully public control is definitely also not going to happen. For this it is to limited in functionality to even spend half an hour to make it more functional.
  5. Neil Pate

    Set a default path when clicking path browse

    The bug I mentioned is not in the LabVIEW control, it manifests in the Windows file explorer dialogue that pops up.
  6. Ateeq urrehman

    ATOM-RIO

    I want to install ATOM-RIO driver in my ATOM-RIO, but have not this driver.if somebody know from where i download? www.mangotree.cn
  7. Can't you use property node=>Path Text=>Scroll Position instead?
  8. Last week
  9. Neil Pate

    Set a default path when clicking path browse

    Thanks, thats what I ended up doing. It works ok but a Windows bug causes the text to be pushed out of the control, so I had to then applying this fix: http://etchingpathways.blogspot.com/2012/07/labview-simulating-keyboard-events.html
  10. Darren

    Set a default path when clicking path browse

    I don't think there's a way to do it. You'll need to make your own browse button.
  11. Does anybody know if it is possible to configure the path control so that when a user clicks the browse button the file dialogue that pops up has a custom filename pre-populated? You can do this easily with the dialogue prim, but I cannot figure out how to do this with the path control. I thought perhaps there would be an event that is fired off on browse, but it does not appear so. I suppose I could hide the browse button and replace it with a regular button...
  12. I don't care what version of .NET is required. All .NET is banned from my projects and some of my hair has grown back as a result I too have products in 2013 and have found it relatively stable. It was my next choice if I were to be dragged kicking and screaming from 2009 Anyone else prefer an earlier version than 2013?
  13. I think I must have had low glucose at the time (just before lunch). I should've created a simple example, but it turned out I was missing a input to my VI! Grrh! It's working now. Thanks for your help! Bruce
  14. How specifically are you trying to create the folder? I'm using LabVIEW 2016 on Windows 7 and just tried creating a folder named "Blah 1.1" on my desktop. I did it using the "Create Folder" node located in the "File I/O" >> "Adv File Funcs" palette and it worked for me. If you're using Windows 10 and LV 2017, I'm not sure if one of those could be the culprit.
  15. infinitenothing

    Playback file on cRIO

    Yes, what you're doing is super common. It might be worthwhile to use the TDMS file format instead of a spreadsheet file. It's a very easy format for recording and playing back data. I'm a little curious why you're using a CRIO. It's not a bad choice but something a CDAQ could be simpler.
  16. This seems like it should be easy, but I have not been able to create a folder that has decimal/period using LabVIEW. For example, creating a folder named "Blah 1.1" yields a folder named "Blah". I can create the folder directly in Windows so I know it is valid. Has anyone else seen this before? Thanks, Bruce
  17. flarn2006

    Hidden editable pixmap control

    Yeah I guess. For the record I have no need to use it or receive support for it; I was just curious.
  18. David_L

    Hidden editable pixmap control

    Agree with Paul. Assuming that this is some feature that isn't supposed to be there, they'll support this in the way they support any bug. File a bug report that may or may not get fixed in a future version of LabVIEW (likely > 1 year away) then give you a workaround, which is don't use this unstable hidden feature. If it is a feature that is supposed to be there, but buggy, then pretty much the same result, as there's probably not much else they can do for you in the short term other than suggest a different, more stable approach.
  19. paul_cardinale

    Hidden editable pixmap control

    And that support would likely consist of: "Don't try to use that thing. It's broken". In general, there isn't an obligation to support undocumented features.
  20. paul_cardinale

    Hidden editable pixmap control

    Is there really a need for that thing? If so, it wouldn't be very hard to create it as an XControl .
  21. I also use 2013 as my base for most reuse packages. It has the new tunnel options including the valuable "conditional" (fixed over 2012 to have good performance) and Variant Type VIs that are about 100 times faster (than in 2011 at least). The next really useful feature is VIMs in 2017.
  22. Ratataplam

    Playback file on cRIO

    thanks a lot, your suggestions have avoid several attempt
  23. 2013 is my go-to for stable+old. 2010+11 had the new compiler, 12...I dunno what happened with 12, but it sure seemed to be unstable. Its probably a lie that my brain made up, but it always seems like the even years are much worse than the odd years, with the exception being that 2018 seems pretty solid. 2013 has the new compiler (2010) with the performance issues resolved (2012), auto-concatenating terminals (2012), somewhat improved web service scheme, get class instance by name, dotnet CLR got bumped to 4.0 (I know this may be a negative to you ). The only big issue I know of is the attached code comment arrow thing, which results in an instacrash at a later date if you duplicate any multi-frame structure that has one inside. You miss out on custom right click menus (2015), VIMs and read-only DVRs (2017), and the CLI, python node, and type disable structure (2018) -- of these only the custom right click menu is probably helpful.
  24. flarn2006

    Hidden editable pixmap control

    Well if someone causes problems with it, after coming across it in the way I described that doesn't give any kind of warning, wouldn't NI be obligated to provide support?
  25. Playing around with XNodes—though come to think of it, you might be able to do this in a subVI as well, if you can access the diagram of the VI that's calling it. Call Chain maybe?

    ss_GqSztr.png

  26. What should the source code minimum version be? By that I mean the source code of the package manager itself, as it would ideally be open source. Obviously 2009 is my preference but that requires 3rd party toolkits for HTTP and HTTPS; which is not really tenable for most people. Later versions are plagued by stability and performance issues so I guess what I'm asking is what is the minimum stable version of LabVIEW that should be supported based on prevalence.
  1. Load more activity
×

Important Information

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