hooovahh

Personally I didn't think Generics was the right approach. XNodes already do what Generics don't, or sorta did in some use cases, some of the time. My point is Generics had a subset of features that XNodes did. Edit time polymorphics exist with XNodes, along with a whole slew of other cool features. Why create another way to solve the same problem? Focus on XNodes and on making that interface robust, stable, documented, etc. Then using scripting you can write a utility that makes a "Generic" which is just an XNode. That is a challenge that we can accomplish today. Given a VI as a template, create an XNode that accepts various things as the input, and then automatically change the output. Whos up for the challenge?

That's what I thought too, but I do have those special keys and I don't have OpenBinaryLibrary. So not only did something go wrong, but it went so wrong that some features even more secret than the super secret ones have been partially exposed. It sounds like your code is royally hosed somehow. Probably some kind of error where the timeout case is no longer valid, and the events are then shifted by one, which caused your value changes to turn into something else they probably shouldn't be. Hope you have source code control. I'd also bet that a repair install of LabVIEW will fix any new VIs made, but doubt it will fix any VIs saved that were in this broken state. You're probably going to need to contact NI for any real support. But thanks for sharing.

Very neat. Yeah I'd suggest making wrappers for each of the basic button examples you showed. The goal in my mind is to have as few inputs as possible, and exclude using clusters if possible, as well as using enums when possible. But I think some controls in your case will need to be rings, where maybe it has defined values, or a custom output. And I'd suggest making default values for inputs valid, so that fewer required inputs are needed. In my experience following these rules help make interfaces that other developers can use easily. Cluttering up the interface with tons of options gets confusing to new developers, and giving them fewer options, with working default options helps them adopt it easier. I don't have much time to work on these but here is an attempt at cleaning up some of the code. Functionally it should be the same. I moved some functions into the private code and exposed only important things as public, updated the example to use the event structure, and wrapped the first three functions into subVIs with icons, VI descriptions, and in the minimalist process I described earlier. I don't have 2012 installed so I had to back save from 2013, I hope things didn't break in the process. TaskDialogIndirect Source Hooovahh Edit.zip

Yeah we'll see, my initial thought is these couple of VIs aren't going to have much of an impact. If I am able to make tools that make XNodes, then likely others are able to make XNodes already. This might make, making XNodes easier, but it doesn't make understanding them easier. For me that's done by looking at what other XNodes have been made, and there are a couple good ones in the Code Repository. I am interested too in the progress of XNode development from NI's side. They not only add new abilities but update older ones. Like the GetTerms for instance added new data to their terminals to handle "English Name". So they are making an effort to continue updating this technology, for their internal uses anyway.

If you need a real time system, then you need a real-time system. Windows is not an appropriate system to be able to perform actions on a microsecond timing. Heck I wouldn't rely on a Windows application to respond in 10ms consistently. Ever been using Windows and have the keyboard and mouse go unresponsive for a few seconds? What do you think your application is doing during that time? That doesn't mean there isn't other possible Windows solutions. With IMAQ you can configure the acquire to return all frames, which can be kept in an onboard buffer. So you don't need to get a new frame every couple of microseconds. Instead you can wait 10ms and have it return all the frames that it acquired since the last read then process those one at a time. Still I think you'll have a problem processing them faster then they come in. So you'll still probably have a run away condition, and so when you last read is done there will still be time when the previous frames still need to be processed. This type of system is only really safe if the capturing of frames is a relatively short time frame. Another option is just to log all the frames as they come in, then post-process. This won't have the run away issue but your test will take longer of course.

You know I kinda thought it did. Do you have a pre-made VI that calls that with the right inputs that you could share? Oh but that only works on a VI path right? I can load the Block Data from a stream of bytes, not that it wouldn't be hard to save to a temp file.

UPDATE: These first few revisions are more or less broken. The first fully working version can be found here. 8 Years ago the first version of the XNode Manager was posted to the code repository, and it hasn't seen an update since 2009. Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality. I didn't spend too much time on it, and I don't think it replicates all the XNode Manager functionality, but it does have some major improvements. The XNode Manager had a blank XNode, and blank Abilities that it just made copies of. This is fine but then the abilities and XNode are quite old. There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager. My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create. Then VI server is used to create the XNode, State control, and Abilities. This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it. Be aware this uses several private functions, and several undocumented features that could be potentially bad. I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable. But at the end of the day if it blows up and crashes, don't be surprised, you've been warned. Saved in 2013, but could probably back save earlier if requested. If I get more time I'll add some features, and add it to the Code Repository. XNode Editor.zip

Okay so I did get a solution for my use case. One of my new favorite private functions is the Save VI as Buffer. It performs the same save operation that a VI normally does, but returns the stream of bytes that the file would be, had it been written to disk. Luckily there is also a Save Library as Buffer. So using these functions I was able to get the VI and project buffers, then save them to disk using the write binary file. The only modification I needed was to edit the library buffer stream, modifying the XML to include the relative path to the member. Since the member hadn't been saved yet the path wasn't stored in the project buffer. After that I needed to close some references, and it seems to work.

Oh it's not hard, it's you just need to use unconventional tools. A while ago I posted a bunch of VIs that open up the VI file structure. Normally you provide a VI as a path, then it reads it, analyzes it and tells you what blocks are in the VI and at what offsets. This can then do things like read the VI description, VI icon, and a bunch of other things without opening a reference to the file. This same code could be used to analyze VI files without LabVIEW too. Anyway so I made a couple VIs one with a block diagram one without, and looked at what blocked were missing then found a couple that start with BD and assume that has to do with the block diagram. So attached is some code. Open Perform Test which will have two static VI references in it. One to a VI with a block diagram one without. It will then perform a save VI as a buffer, then using that buffer will find the blocks, and look for the BD ones. I also built and EXE and it also worked from there too. One downside is the VI without a block diagram was saved in 2013, so this exact test only runs in 2013, but if you provide your own VI without a BD in whatever version you have it should work. Couple of undocumented features being used here by the way. Block Diagram Test.zip

Yeah it can be a bit of a hike. You can look into sharing a cab? Or those Pedi-cabs might be out by then, better tip them well cause it is up hill.

Wow keep up the good work. Yeah I'd say the majority of LabVIEW developers still use 32 bit LabVIEW regardless of the bitness of the OS, but still the majority of the features are working in 32 bit LabVIEW. I don't think this library is ready for a package yet, it is still very early. When the time comes we can try to wrap these functions into simple to use functions, give it some pretty icons, and then package it up. I'm loving the progress, keep it up.

I realize this is 5 years old, but that method won't work for me. Imagine if you create a new XControl. When that XControl is made it creates 4 things to go with that library. There is the Data, Facade, Init, and State. Through scripting if I make an XControl it will make these 4 items and put them in memory. I can't perform a save on a member of the library, or the library because of the issue you described. But I also can't remove these items from the library. I tried through scripting and I got crashy-crash. Might have been my fault but after I disconnected the VI from the library then attempted the save of the library it all went bad. So I have private methods on, and I still don't know a way to save a library with unsaved members, that cannot be removed or disconnected from the library. Any thoughts?

Topic moved and renamed. In the future do this by using the Report to Moderator button, I just happened to be following this topic, not all moderators follow all topics believe it or not.

I guess I just got super excited when I saw a demo and didn't read the rest of the posts enough.

Sorry I thought that meant 32-bit Windows support later.

Well thank you for your code...but your demo didn't really work for me. In the Example the only button that did anything was the surprises. I ran the Sample 1 Popup.vi and no error was returned but first call to TaskDialogIndirect returned a return type of -2147024809. This was on a Windows 7 x64 machine, with LabVIEW 2013 SP1 32-bit. Is this intended for 64 bit LabVIEW?

Oh wow that is cool. Please do post here when you get something working. In the past I had a similar need. Where I wanted a dialog box which looked similar to the system ones, but I could provide an image to be displayed below the text, above the buttons. I had tons of code handling the window resize, resizing the image, and the text, and had code trying to increase the font size, and splitter positions. It was a pain and wasn't very modular. It also was system looking, it looked like my current system. Having more low level control of system dialogs like that could be very useful.

Have you tried using this code on Linux? I didn't try it because I don't have access at the moment, but I see no reason why this wouldn't work on Linux it is just using the UDP primitive calls.

You reminded me of an interesting post where Altenbach noticed according to NI legal you can't use the word LabVIEW in a sentence, among other strange legal-eze. http://forums.ni.com/t5/BreakPoint/proficiency/m-p/3124823#M26799 I'm unsure if it is NI legal that is crazy or the whole system. In either case I'm always glad to hear changes in legal that simplifies things, or allows more control as a user of their tools.

I don't know what the TaskDialogIndirect looks like or what functionality it has. But for system Windows like dialog boxes, with options for 1, 2, or 3 buttons, and various warning/information glyphs I've been using this Windows DLL call. https://decibel.ni.com/content/docs/DOC-35643

Right but, if I asked you to round 3517564740 (what I think is June 19 at 13:19 for you) to the nearest 86400 (24 hours) you would say the value is 3517603200, which ends up being the next day. But I could see how this could cause confusion.

What about it? You state the day is wrong, which is true but rounding up to the nearest second could mean the second is wrong, it doesn't invalidate the fact that you only rounded up a fraction of a second. Yes time is absolute and relative I guess. So if we think of it as seconds passed from some date GMT, rounding up a fraction of a second doesn't mean anything more than just rounding up that fraction of decimal. Also your date example of rounding to another day doesn't matter to the other 23 time zones that would still be in the same day. None of this explains why NI chose to do what they did, but in opinion this isn't much of a reason to treat timestamps different.

Rounding time up? Like traveling into the future? That's just crazy! Rounding down is fine, it's like going into the past, you know the past exists you already were there. But how can you round up, the world might end in those milliseconds you rounded up to, now won't you have egg on your face when you look at your data after the world has ended, and your timestamp shows data was taken after the world ended. But seriously though, other than philosophical reasons, I don't know why we couldn't round up when appropriate.

I don't have IMAQ installed but I think those settings are exposed using various property nodes. I also remember those settings in MAX and saving them in MAX retained the values. So in the past I've just set it up in MAX and saved it, and never needed to change it for the application.

Launch the example finder by going to Help >> Find Examples and search for Simple Serial. There are also several examples on the NI forums and even here. https://lavag.org/files/file/172-hyper-terminal/