hooovahh

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/

It is a handy feature to have. Especially for UI's that you have lots of panes and scaling happening. There are times that going too small just breaks things, so you make it as small as you can, then set the size to that to make sure the user doesn't make the UI unusable. Like I said there is a property for each pane as well but this is harder to get at because you need to drop down property nodes to read, they aren't viewable in the VI Properties. And then weird things can happen if you try going smaller where a pane can't get small but the window can so I almost never use this feature.

That's an interesting approach, with several pros and cons over the typical poll the timeout case and check method. A few comments, you aren't closing lots of various references, and I figure you probably just threw this together. You have a VI reference, notifier, and user event for each trigger that aren't being closed, and you aren't unregistering for the user events. Some of these take care of themselves when the VI stops but I don't think they all do. Also I'm not sure you are aware of this or not, but you can create an array of user events, and register for all of them at once as long as the data type of the user events are the same. This might help make things scale easier because you could be making timing sources in a for loop, and to add another source you just need to run the for loop another iteration. Overall I like the concept. I keep going back and forth, but I do not think I have a need for adding things to the end, and front. If I go off and do some things, and I want to go to Idle periodically to see if there is new events to handle (like a trigger) my first thought is I would want to add Idle states to the front, then add the states added in the event structure at the end, unless it is a critical thing like shutdown. But this isn't true because when I add Idle cases is is probably going to be in a Macro all at once, so it doesn't matter if it is at the end or front. And as for going to Idle periodically, I wouldn't want to go there until I was done doing what I'm doing anyway, and then the event structure will act like a queue and my events will be waiting for me when I'm done doing what I'm doing. In the past I've seen where the states were always added to the end, except for an exit which was added to the front. But again with this design you're not usually going to go check to see if you should exit, until you're done going to your states, so it didn't really matter. Oh and I've used the DAQmx events. Just like all state machines where you have work, and UI stuff in one loop you need to be mindful that things should happen quickly, so the UI appears responsive, and you don't delay the work going on. Like you probably wouldn't want logging in that same loop because an event is generated for taking DAQ, then you take the DAQ log it, do limit check, database, or whatever, and this whole time your UI is unresponsive.

Certainly posting the VI might help. Short of that I've seen this issue when using this function a couple times, all of which were expected if I had stopped to think about it. The first is maybe your front panel has a minimum size set, and the decoration is less than that minimum. In this case you won't be allowed to make the window smaller, so it throws an error. I've also seen it do odd things when there are splitters and multiple panes on a UI, where it will try to scale the window to the largest decoration, but that decoration is only on one pane. I've also seen where there is a minimum pane size, and again the decoration is too small. I'm sure there are other reasons this VI can throw an error. Because of these types of issues I don't use this function too often any more. I also heard someone mention this function does nothing, and returns no error on the new cRIOs running embedded linux, with a monitor plugged in, but I didn't get a chance to debug it.

I'm interested less in making MDI applications, and more in knowing that NI has provided the tools, to make any application my imagination can come up with. Put another way, I'd like to have the ability to take any existing program, on any platform, and be able to recreate it's UX. I want users to use my program and not know it was written with LabVIEW. Exposing the HWND, or providing wrappers to similar cross functional APIs is one step towards that. And to be fair the window management properties in VI Server is a decent step in the right direction.

I don't completely agree with your Always statement. If JKI didn't want us to be able to enqueue at the end then they shouldn't have included that feature. They obviously saw a need, or their users saw the need for it. Oh and jcarmody said without launching an actor.

Oh that's a great idea, and a case I haven't really thought of because I generally have had another actor doing the actual work, and the state machine is just the UI, but there are plenty of times the quick and dirty is to have it be in one state machine.

For me I don't ever add an "Idle" to the Add States. It just goes there after it is done doing what I asked it to do. So you go to the Macro Initialization. It does the states you tell it to, and then when it's done it goes to Idle, where you may have a timeout. In the timeout it might go to another Macro to do stuff, and after all of the states I add are done it goes back to Idle. It does this because when there are no more states to pull out, it passes out an empty string, so you should go to the "" case. Drop down the JKI template and run it. If you press the OK button or close the window it should react to your request by going to the Macro Exit case. It does this because it was in the idle case polling the event structure. You could add you own "Idle" to the states but I have never had a need for that, it will just go there when I'm done. And going to the idle case doesn't need to wipe away your string queue. If you go to the "Idle" case then perform an event with a button press, you can still use the Add States to add more. But in my software, since I never add and "Idle" case, to the states to go to, I will only go to the Idle case if all state have been processed.

Interesting read, and LabVIEW definitely falls into this category, and not just with threads. Ever allocate memory for a variable in LabVIEW? Maybe you initialized an array and used replace instead of build, but this is not the same kind of memory allocation other languages think about. What about parallel tasks? Memory cleanup? Obviously being a higher level language many things are hidden away, and with a really advanced compiler even more things are hidden from the developer. I was talking to a friend yesterday and he made the statement about how easy software programming is, compared to previous decades. And while I agree I think the challenge has shifted. You no longer need to worry about the things that are abstracted away (until you do), but you do need to worry about much larger systems, with a much smaller team. We need to have more architect skills, and be thinking about how the pieces plumb together, and worry less about the low level, and assume they are water tight. When they aren't, we struggle.

Here's some information on the .net functions called. https://msdn.microsoft.com/en-us/library/bb299773(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext.principalcontext(v=vs.110).aspx https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext(v=vs.110).aspx

Unofficially they do, but yeah you may want to post over on the NI forums, for higher visibility.