hooovahh

Search your feelings, you know it to be true. The dark side is the only path forward. (unless someone from NI comes here which does happen but I think this is specific enough of a problem to ask that group) This really does sound like a software limitation, potentially in the kernel. The fact that the 15th device is pluged directly into the cRIO not through a hub is the key piece of information.

I'm curious what USB hardware you are using. It sounds like you have 16 individual devices and might fair better with a single 16 port device. I've used these successfully on Windows, but never had access to one and an RT controller. I know of no reason why this limitation would be there, but NI might and you should probably crosspost here. EDIT: You may also want to update this post with USB devices you were successful with. I haven't found an FTDI, or Prolific chipset that hasn't worked yet.

One work around I've yet to try is I've heard you can set the window to be transparent in the VI properties. And then make it not transparent when the VI starts running. Not sure if this actually works but I've seen it on several of my programs and just haven't looked into fixing it since it is a pretty minor issue that no one has complained about except me.

I've always added new items to the end. It does make organization look a little out of order but functionally I've never had a problem. The 2014 approval dialog does come up once in a while when I'm removing items, and seems to work well. Maybe you are removing, moving, and adding too many items at once and the attempt at preserving values fails. If you do one edit at a time I wonder if you'll see the problem.

eah I know you were specifically asking about picture rings, sorry I can't help on that topic. But I thought showing you an alternate solution that can accomplish a similar UI would help. Having the other functionality that a pict ring gives might be a pain to implement for sure. Having a small window pop up on top when the user clicks a picture box might be difficult since the picture box will be rendered as a separate object and often times is forced to be always on top of all other UI elements, but I think that is limited to a single handle, and a separate VI could be used. I do wish more attention went into the features of the picture ring. Replicating all of the functionality of a picture ring in an XControl seems like alot of work for just a little added functionality.

I've posted this several times now but figured I'd give it a try to see if it works with vector images and the first EMF I tried it on appeared to work. Attached is the .Net image manipulation stuff that demonstrates loading an image into a picture box which supports alpha layer transparencies, ICO and TIF image selection, and zooming with the control which in this demo changes size with the window resize. Here was the last update I made on the dark side. This attached example just has an EMF that is included to test with. Image Manipulation With Ico and Tif Fix emf.zip

Okay well no sense in derailing the conversation more but had success dragging it from explorer, to the BD when it was saved to the desktop, and the downloads folder, maybe I have some other INI keys doing something else.

Oops, so there is apparently an INI key I had that I didn't realize made this work which might be another reason to not use it. You need this: ExternalNodesEnabled=True With that you can wire an array of strings to the VIM I attached earlier in 2015.

Nope you can just drag and drop the VIM I attached to a BD and it works as expected.

That's not true. In 2015 (and several versions back) you could rename a .VI to .VIM and the inputs and outputs would have type propagation throughout the subVI just like it does in 2017. The difference is that in 2016 and older it was implemented as an XNode and had issues with class (something XNodes have a problem with) and as a result working with the XNode and forcing an update also wasn't as easy. Oh and the wires wouldn't break if there was a type problem, it would just not work and tell you the subVI was broken, but wouldn't allow you to see the VI or know which wire types it didn't accept. VIMs worked back then, but not nearly as well as 2017 and I wouldn't really recommend using it. I presented on XNodes and VIMs at NI Week 2016. EDIT: Apparently you also need this in your LabVIEW.ini: ExternalNodesEnabled=True Remove Duplicates 2015.vim

http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B And an idea exchange item to make this easier. https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-right-click-option-to-delete-class-mutation-history/idi-p/2594921

In my typical development cycle I keep looking forward to the next release (2017 SP1) imagining it will fix all of my stability issues. Not that my system is unstable, just that long delays in editing, and saving, make for a painful development process. Oh right positive. Rapid prototype and performance testing with small VIs is fun. For performing some kind of custom filtering, I'll sometimes write it 2 or 3 ways to get the same result, and then throw random data at it and see which performs the best. Then implement that into the main application.

Thanks rolfk for saying what I was thinking. That being said if we are talking about a cRIO with an embedded UI thing in theory things work the way you described, but I simply haven't heard enough from other developers, and haven't had enough experience with it to say one way or another if it behaves differently. YMMV indeed. If you are seeing some reproducible issue I'd ping NI on it. It is possible there is a bug in some UI behavior, or optimization that could be made.

While I do multiple user events, the payload is all Variant, which is again how I can get away with building them into an array and registering for them all at once, or subscribing and unsubscriping to events at runtime.. The scripting code generates the VIs that flatten to, and unflatten from, the type def so everything is still strictly typed, but there is a common payload for all events. If there were N events, all with their own registered case in an event structure I couldn't do this as easily. But I admit other parts of the application would be cleaner.

I don't have a link to someone at R&D claiming this to be so, but I know that some amount of resources are freed up by not showing the UI, this includes even minimizing the window. Now the question remains is there some amount of system resources being used up by a UI not being seen and it is just much less than if the UI is normally shown? No idea and some testing would be needed to know. In extreme cases I do things like write code which keeps track of which UI is being shown, and if it isn't, then to not go into the state in the state machine that would update the UI. I've also done this with tab controls where I know I don't need to update the controls in a tab if that tab isn't being shown. Even so I think the most common case for CPU usage on a UI is a graphs with many data points, or very large MCLB with individual cell coloring or properties, and not for individual scalar controls.

This sounds like a stacking issue as ensegre said, but looking at your decorations, they all have transparent centers, and you should be able to click right through them. I'd first suggest moving it to the back as already suggested. But if that doesn't work try using some other decorations and see how they look. I prefer a system looking UI, and so I often use the System decoration box.

I prefer having N user events, one for each message I want, and one for each reply (if applicable). If the data types are all the same (ie. Variant) you can put these user events into an array, and register for all of them at once. You will have one event case handling all of them, but the point is that you can have a publisher/subscriber model where modules (actors) can subscribe to N of them at once.

The way I handle this is the UI event that is generated when the user interacts with stuff, will generate a user event for some work to be done. Then when I want that work to be done anywhere else in the application, all I need to do is generate that same user event. Now the code that my sequence calls, is the same code that my UI calls. This makes debugging sequence issues pretty easy since I can just manually perform the same steps as what the sequence would be doing, by performing the actions with the UI, which would generate the same user events as the sequence would. It is a lot of upfront work, and does feel like an unnecessary layer of abstraction, until changes in how something behaves is needed, and now I no longer need to update both the code in my UI event case, and the code in another case.

Yeah I'd also suggest testing with an explicit open, read write in parallel, and single close. I'm not certain that the Read/Write will force a blocking call but if this doesn't work then I'd suggest the VIG that you call which forces it to occur serially.

Very cool, I suspect there is probably an Idea Exchange item for this somewhere requesting this feature be native. Thanks for the shout out.

Oh fantastic solution. I used TrueCrypt in the past and had forgotten about it. Glad to see it lives on.

Read from text file, or read from binary file. Of course you won't want to read the whole file at once, you'll run out of memory and crash but you can read it in chunks reading N bytes at a time.

I've seen this before, and I've seen it fixed by adding a small delay before attempting to move the file, as some process wasn't quite done messing with it. I don't think the error is descriptive enough and Duplicate Path doesn't mean what it seems. Another suggestion is to try to use the Windows Move DLL call if this is in Windows. http://forums.ni.com/t5/LabVIEW/Is-it-possible-to-move-files-more-efficiently/m-p/859633#M389528 http://digital.ni.com/public.nsf/allkb/576434CD1B659EE386256F04006909AA This invokes the move operation using the system level calls which I've seen work, when the LabVIEW one hit these types of possible edge cases.

Well at the moment I still do something like: C:\Code\SVN\Database Name\Project Name Sometimes there is only one project in a database, so one level is removed. And sometimes I only have code from SVN so the Code level is removed. Under that I usually have these folders: Actors, Builds (which is excluded from SVN commits), Configurations, Documentation, Sandbox, Shared, Support Files, Validation, Verification. I agree that some users don't have permissions on this more root location, but I've had problems with the path limitation in Windows, especially when building applications or VIPM packages, and having things near the root helps avoid this. I guess one option would be to use symbolic links with mklink or junction to map a path deeper in the public space to one closer to the root. I haven't used it yet but the public documents path would probably be the more correct location for this type of source that all users have access to: C:\Users\Public\Documents Here is a Too Damn Long meme that I've probably made 4 times by now but can never find it when this subject comes up, which honestly is a bit inflated, but does reflect the level of nested folder structure I've seen used in the past.

Attached is an updated version that I think does the same work but in a less Rube Goldberg kind of way, but I think this can be improved more.