hooovahh

You posted your first question to the forums on a Saturday (morning time in US), and then waited one hour before screaming "HELP ME" adding nothing to the question, and describing nothing new. You are being quite rude and those of us who put in our own spare time to have discussions and to answer questions don't feel compelled to help those who ask questions the way you have. That being said I've never used that DLL, and never used the Mandarin language, and assume it is a problem with Unicode support in LabVIEW. In the future if you want questions to be answered, ask it in a better way.

What do you actually want? What have you actually tried? Writing a string to a file shouldn't be difficult, and should be something covered in the first hour of a LabVIEW basics example.

In the development environment? You can't. The only hooks NI gives us to augmenting the IDE is through the menu bar (which is limited by typically are for entries in the Tools Menu), QuickDrop plugins (which get invoked by performing CTRL+Space, then CTRL+{Key} that you define), and starting in 2016 a right click frame work which works on objects that are right clicked. So you can define a menu to show up if a string control is right clicked, or a numeric constant, etc.

Glad you think so but there are plenty of things this project does in a less than ideal way when it comes to OOP. Certainly more dynamic dispatch would make adding new types easier but I never got around to improving it. I always thought a hardware abstraction layer like some posted on NI's site were good ways to get your toes wet in OO. http://www.ni.com/webcast/3431/en/ https://forums.ni.com/t5/Past-NIWeek-Sessions/Hardware-Abstraction-Layers-Using-LabVIEW-Object-Oriented/ta-p/3508682 http://www.ni.com/white-paper/53226/en/

Okay after testing out a few things and being confused on why the last upload didn't, work I think I know your problem. So the demo is primarily setup to work on localhost. If you wan it to work on a remote system you need to tell the web publisher what your local IP address is. I left a comment on the block diagram next to the Publish function stating: "Here we can use the external IP address, in case computers on the network are trying to access this page. Unwired is localhost and will only work from browsers on this computer." So what you need to do is wire from the IP to String, to the Host Connection terminal on the Publish function. In my setup I also use port 80 not 8080, but I tested using XAMPP on IE, Firefox and Chrome on another computer. The reason I left this unwired is you may have multiple NICs and I didn't want to assume the IP address you want to use, is the one returned by the IP to String function and wanted you to be able to specify it. Maybe in another update I could have the configure dialog ask for these settings listing the IPs found by performing IPConfig

For small development stuff in obscure versions Microsoft has VMs available for free download with a multi month time limit that can be extended, and snapshots that can be taken to extend this for quite some time. And many large companies have site licenses for Microsoft products where they aren't paying for each install with a full install price but sometimes just a key to use on that site as much as they want. But yeah if you don't fit into one of those two categories VMs are a bit harder to do large scale. Something as old as 8.5 should probably be in a VM just due to the legacy OS that it officially supports. Still I get the frustration.

Crosspost with more discussion.

Difficulties with scaling? Non scale-able? Less efficient development? More work in maintaining? More Error Prone? I get the issue of the language, but when you mentioned 'unmaintainable' I knew what you were saying so maybe my opinion isn't as important as someone who didn't immediately understand what you were talking about.

Sorry I couldn't hear you over the sound of my ZOOOOOOM! Okay maybe zoom wasn't my number 1 request, but it likely was the number one request by over all. Maybe XNodes would be my most requested features. VIMs gets 80% there.

I did this time round...I mean VIMs am I right?...still I'm lucky enough that my project development time was a year, full well knowing SP1 will be out before the deliverable is required, but that still is a decent amount of risk running a new version with so few miles on the tires.

Wish I would have known that earlier, could have filed a couple hundred CARs by now. When LabVIEW is stable I'd say it crashes a couple times a week, but it isn't a big concern because the fix is generally to start it up again. I also think variant to data could help invoke crashes too by converting things to things it shouldn't and then acting on those things. I just tried a few things I know used to crash LabVIEW when messing with registering for events but couldn't get it to occur so maybe that one was fixed. It's not a bug its a feature. One I'll admit I wouldn't use, but still.

So I have some VIs, and they call some subVIs. The dependencies have been replaced with a different but similar API. Instead of keeping both APIs I'm ripping the bandaid and getting rid of the old API moving forward. The old API has been used in several places and so now opening VIs that called them brings up a dialog of searching for the missing dependency. I can manually go in and do quickdrop replacements, but there called quite a few places and I'd rather do it with scripting. So what I'd like to do is open all VI references in a folder. Find all subVIs in that VI. Look at the path, or name or some identifying mark of the missing subVI. If it matches the old API, do a scripting replace on the new one with maybe some small adjustments like creating constants where before there wasn't an option. I'm running into an issue pretty early. I can open the VIs reference, and then get all references to subVIs. But since they are missing, the VI path and VI name for this reference is blank. So how can I know some identifying piece of information from the subVI that isn't loaded? One option is I see when you have context help open is you can see the expected VI path. But I couldn't find this property. Any suggestions? Thanks. EDIT: I see Missing VI Path, Missing Paths, and Dependencies >> Missing Dependency Paths, properties on the SubVI but these are always blank for some reason. Double Edit: I'm an idiot, the property node generated errors early on in my testing, and wasn't working right. Please disregard.

View File Hooovahh Array VIMs Here is the Hooovahh Array VIMs. This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques. In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette. Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels. And a few functions have added performance based on other inputs. For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted. The Filter 1D array can also be more efficient if the input is known to not contain any duplicates. Because these packages contain VIMs, they require LabVIEW 2017 or newer. Having these functions be VIMs mean all functions work with various array data types. Included functions are: Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  

Same as crossrulz. But the one brought to my attention recently scares me, and that is not being able to build an executable in some situations, when using VIMs. Since I'm in the middle of a major overhaul of VIMs in our reuse library any given application will likely use 10s of VIMs, in 100s of instances. And debugging when one VIM prevents a build from happening would be a major pain.

Oh that's a good one and one I have used in the past. I had found that in some versions of LabVIEW, some methods of doing functions were more efficient than others. And so I would have the VI on start read what version of LabVIEW it was running in, and then do things differently based on if it was in 2015 versus 2016. Of course there are other issues in that this needs to be saved in the oldest version supported, and that would generally mean not using some new features that might be more efficient. But my point is I would have found LabVIEW version useful in the past.

I was stating how I would do it now. You speak as if there is an alternative, of which I'm not aware of one. Also I'd prefer a first call state, rather than a thread swap to the UI every time I call the subVI. But I do have something that I might use this for. Is VI top level? My actors can run independently of any central messenger structure, so that each can be unit tested and debuged on their own. During the initialization state of the state machine within each actor I will detect if the VI is the top level, and if so it will behave slightly differently. This information is kept in the private data of the actor in the forum of a cluster in a shift register. They detect this by looking at the call chain, not a property as you mentioned but even this I heard can take enough systems resources that calling it over and over is less ideal than just calling it once on starting that actor. Other things I check I can see changing at run time like if the actor is in a subpanel I may behave differently, or if the VI has its window showing.

Thanks for making this clear. I know you mentioned conditional disable in the title but for some reason I didn't see it like that (us LabVIEW people are quite visual). I think I could see code like this. It could make things more reusable, but honestly I would just read this as a property node on first call into the VI the keep it in a shift feedback node all other times the VI is called. It isn't like reentrancy can change on a VI after entering run mode anyway, which is sorta the purpose of the conditional structure, things that can't change. Would you see implementing all properties of a VI in this conditional structure?

I really am editing the VI. It is fixing whatever bug or issue I found with the reentrant VI, that couldn't easily be troubleshot with debugging turned off (or no probing ability like on reentrant RT VIs).

I would definitely use this on reentrancy. Yes I designed a set of code to function as reentrant (and some times inlined) and it works and is tested and is great. Then comes a time when it behaves oddly on RT. Since RT can't debug reentrant VIs in the typical way with probes and break points, I will then change all the VIs I feel I need to debug to non reentrant. Make a set of test code that only uses one instance of that code, debug it, find the issue and fix it, then turn reentrancy back on. Maybe another one might be something like turning on wires retain values on a VI, or multiple VIs. Asbo had an idea on the Idea Exchange for improving this too. But overall I don't feel strongly one way or another

I was asking for an explanation, full well knowing it might lead to me asking for other things. But I do agree that the result of an XNode stating "I'm inline safe" and then not being, might lead to a crash or other unexpected behavior. Still I sorta feel like that is the result of a poorly made XNode, and while NI could protect for it, there are plenty of places I can force LabVIEW to crash doing something stupid and NI can just respond with "Don't do that." because I'm at fault for not abiding by the documentation.

You must know the second half of that expression...NOW WHERE'S MY MILK? (sorry for shouting but it felt appropriate). I'd love for a way for the XNode itself to state that it will or won't contain code that allows inlining since auto detection is mostly impossible. But it sounds like that will likely never happen. Thanks for the the help.

This really does seem like a feature of an XNode. Somehow telling the IDE that it can or can't be placed into a VI that is inlined. Looking at the XNode in a text editor doesn't seem to help, nothing jumps out at me as a value stating it can or can't be inlined. And the output of the generated code doesn't seem to indicate anything either. The only hint we might get is from someone at NI...that might be reading this and wondering if they should give the mouse a cookie...the mouse says "yes".

This isn't true for all XNodes so you are right there must be something else going on. If you drop the Error Ring XNode (made by NI) it appears to work as expected, working on inlined VIs.

Okay I think I figured it out. An XNode gets inlined into your VI automatically. But there are some functions that aren't allowed to be in an inlined VI, like New Data Value Reference, and property nodes. So if your XNode contains something that normally can't be inlined, then the XNode is fine, but it can't be in a VI that is inlined. Make sense? This is also why VIMs in 2017 can't contain property nodes since they aren't allowed to be inlined.