hooovahh

I've used icacls before for setting permission as well (before I knew about the unlock feature). What I did then was install like normal, and then I needed to remember to run the batch file to change INI permissions after the install. Unlock removes this extra step but again will simply overwrite the INI during the install (which is where this topic came from in the first place)

Awesome idea. Yeah I was thinking about how all of this would work when switching users as well. I have not run into this myself but apparently there is a bug with 2012 with the unlock that doesn't work properly. Sounds like it is planned to be fixed in the next release

This code is still locked. Your code was removed here previously because of this. Either unlock the code or stop trying to submit it to the Code Repository.

What I'm doing right now can be considered non-standard. The INI and EXE go into the Program Files folder, and the INI has been "unlocked" by the NI installer. This makes it so anyone on the system has permission to write to it (but no other files). I've known for a while that files under Program Files should not be changed after the installer because of user permissions issues and that the ProgramData is the correct place for this information. To be more standard moving forward I think it would be a good idea to try what bmoyer suggested. I can have the installer install into Program Files the EXE and INI and keep them locked to read-only. Then settings are read from the ProgramData first. If the file doesn't exist (or there is an error in reading the Section/Key) use the INI file in the Program Files. Then when making changes save to ProgramData. An added benefit I didn't think about with this approach is I can have a "Reset to Default" button that will simply delete the ProgramData INI file, causing the software to use the Program Files INI for settings.

Hello all. I have an application. This application has an installer. During the install the EXE and the INI file are installed and the EXE uses the INI and can then write to the INI any settings changed in the application. If I have a new version of the application I make a new version of the installer. The problem (if it is one) is that during the install the new INI will replace the old one and all of the old settings will be lost. On the one side this is a good thing. This means that when version 2.0 is installed it comes with an INI file that is compatible with the 2.0 of the EXE and will have known good settings. On the other side this means that if there were any custom settings they will be lost. It is possible to run a EXE after an install, so I was thinking one possible solution could be to backup the old INI (sometime before deleting it) then after the install compare the two and any keys and sections that exist in the old and new INI, to be copied so the new INI has the same settings as the old. Any thoughts on this? Is this a non-issue and installing a new EXE with the new INI is the way to go, with the understanding that old INI settings will be lost? Thanks.

No worries. There are days where I come on here and probably say things out of emotion and say things I don't mean to try to get a point across. Password protection, IP protection, and low level LabVIEW secrets on this forum have been a hot topic, and people are very opinionated, which makes for some topics which seem to add nothing to the greater knowledge that this forum is intended for. I understand your position and feelings about IP and DRM. I also understand what flarn wants to do, and to an extent what drives him in his pursuit of all that is LabVIEW secrets. I too would like to know the dark secrets of LabVIEWs inner workings. I'm always interested in what there is to learn when it comes to LabVIEW, but at some point you cross the line and for everyone that line is different. Laws are intended to make that line the same but in many cases is still a grey area. In my opinion stating that "we need a new password cracker" goes too far, but at the same time I did not know that in 2012 the password scheme was changed to counteract previous flaws. And had it not been for this post I may have never known. Man I'm all over the place with this post. I congratulate anyone who understood the message I was trying to say.

This is just silly. Of course theres a difference. If there was no difference we would use the same word to describe both types of property. In the dictionary if you look up Intellectual Property it will not say "See Physical Property". I also don't condone releasing anything to break NI's password protection scheme, but I also think it isn't in your place to say that he "WILL get into trouble" if anything is released. What happened to the last guy that released a password cracker that works on all VIs between 7.x and 2011? Well I don't know for sure but his website is still up with the source code, and will even remove the password by uploading a VI.

It was kinda funny because I could see new posts, and my RSS showed new topics, but you couldn't go to the thread.

Sorry you made a duplicate topic here and I replied in any case here is what I posted: I've attached my go at it. This uses two OpenG VIs Remove Duplicates and Search Array. Install the OpenG Array package to get these VIs. Average Rows Same First Column Hooovahh.vi 9.06K 29 Number of downloads

It doesn't look like your attached any code. Yesterday there was some LAVA issues so this maybe this is to blame. In either case I've attached my go at it. This uses two OpenG VIs Remove Duplicates and Search Array. Install the OpenG Array package to get these VIs. Average Rows Same First Column Hooovahh.vi

Not the answer I was hoping for, but I'm not surprised. As tempting as it may be I will try to stay away from XNodes, and stick with 100 polymorphic instances, and OpenG code that can't adapt to every thing I need.

This won't work if the SubVI isn't being called in the code yet and is just in memory. I believe this is the situation Minh was describing. I've used several AbortVI functions in the past to be able to abort any VI running (not a close at the moment).

That does sound messy. The other solution I was tossing around in my head, was that each picture could be a separate running VI. Then you can register for a mouse enter/leave for interaction, and mouse down to know which was clicked. I did a quick test here which displays images, and each image is a VI. It's far from perfect, and it actually does resizing (which you wouldn't want to do) but it may give you a new approach.

This is not a feature request by any means, but if you are thinking about making the tool look more native I would suggest having vertical separators and a function that allows for resizing the window, which would collapse buttons into a single button when they all can't fit in the display. See the image of Foxit Reader which collapses the buttons to a >> button which don't fit. Just a thought.

Okay so I've never really dipped my feet in when it comes to XNodes. At the moment I'm not looking to make XNodes just understand using them, and really just get others to tell me it's safe. The ones for discussion are the Array XNodes, and the OpenG Array XNode. I see the functions this code has and I love the idea of using it. But I know that there is no support from NI for using XNodes, and I've heard NI say that using them can be quite dangerous (without specifically saying what it could do or how to avoid it). So I want to pose this question. Is the Array XNodes in the Code Repository as safe to use as the normal OpenG array functions? Is there a compelling reason I should not be using XNodes of any kind in an application? I assume Lava would not certify code that was unstable, and I also see that people are using these functions (over 3000 downloads combined). So is there nothing to worry about here? And if these are so great and stable, should I exclusively use these instead of the real OpenG ones?

Amazing, the community again thanks you for your contribution. The case as you put it is quite undocumented, and needs work, but the concept is there and it works just well. Also it should be noted to get this to work you need to install the Array XNode library, which also requires the lava_lib_labview_api_scripting_tools package as well. ...However I feel the need to post a topic using XNodes, simply because all I've heard about it is how unsupported it is which makes me nervous. That being said NI said the same thing about Scripting before it was released and I was using it then too. EDIT: I made a post expressing my concerns with XNode usage.

So I had a thought. There are primitives in LabVIEW that aren't exposed, just like there are VIs in the vi.lib that aren't on the palette. But the thing about vi.lib VIs is I can navigate the the directory and find the VIs on disk. My question is how does one find primitives not exposed? I've seen a few instances where someone will post a VI with a primitive I've never seen before and I wonder how people find these, other then finding them on the block diagram of another VI. A few examples I can think of are the Text to UTF-8/UTF-8 to Text, and Coerce to Type. Again I understand the reason why these may not be exposed, and I understand the reason why someone would not want to use them. But I can't help but wonder, where are primitives on disk? Where is their information stored (VI description and help path for example). And how can someone find primitives not on the palette?

Sorry I wasn't more clear. What I meant I put labels on the side of controls (right or left). An easy way to see what I mean is to activate quick drop (CTRL + Space) and then use Move Terminal Labels (press CTRL + T) when on the block diagram.

The solution is to architect the VI to only use one event structure. There is no need to poll in the timeout case of the first event structure, just handle all events the user can perform (like Panel Close ) in the one event structure and enqueue any states needed to handle the event. Another side effect of your code is I can't press new game, if a game is still going on. Again having one event structure handle everything the user can do is the way to go. Not sure how many pointers you are looking for but here are a few: The User Logon screen doesn't need the FP.Open or FP.Close (and then won't need the sequence structure) because the VI is configured to open when called, and close when done. If you want the logon screen to be seen first, why is this not the top level VI and then have it call the UI that the user plays with? The Logon screen doesn't allow the user to close, and I couldn't find a way to stop it other then the abort button. The Main screen doesn't allow the user to close. There is a button but using the normal close is more standard for users unfamiliar with your program. Get rid of the toolbar for the logon screen. There are tons of items in there that are just LabVIEW specific. Only show the toolbar if you have a custom toolbar with items for your program. Use more states in your QMH. You have alot of code in the Idle case (with the event structure). It helps to more easily follow the code if there are multiple states to call so they can be reused. You could have a state called "Draw UI" which can be called on startup, and every time the user or AI moves. Your sub VI's have error terminals in locations not seen often. This isn't bad exactly but error wires are usually on the bottom right and bottom left terminals. This borders on the line of style guide or preference not sure which. Control labels being on the right is a preference thing but I think looks nicer. You have some wires on top of other wires and going in the same direction. This makes it very difficult to know exactly where a wire is connected without have to triple click it. I saw some silver controls. As I've mentioned before I don't have them but it should be consistent. The ones I saw were the error wires by the way. I also saw some classic error controls. You are using the Value Signal property node but I don't see where the event is handling the value change. If you just want to change the value use a local variable. Or at least use the Value property. Value Signal indicates you are firing an event for a reason. Unneeded coercion dots. A coercion dot isn't necessarily a bad thing, but they can be so avoid them by giving the correct data type or perform an explicit conversion to the right type, knowing the possible consequences. That being said, you have nice labels, code description, and I like the tab solution for the UI. You are doing well for someone with a month of LabVIEW experience.

I understand why they are private, I was just wondering if in a specific use case if there was any danger in using it. Say if I'm in a 32-bit Windows environment would there ever be a case where using "OS Window" would cause bad things to happen? I have very similar questions for a few other private methods too, and was hoping for some unofficial documentation is all.

I may not have used the right words but what I meant is "NativeWindow" does not work with an application instance that was opened explicitly. It is just like the "All VIs in Memory" property. It will work if you don't wire anything to the reference in terminal. But if you open a new application instance the "NativeWindow" will not work but "OS Window" will. This may be better answered in a different thread, but is there a list of private methods/properties that are more stable than others? What I'm trying to ask is if I use either of these two methods what risk is there? Knowing these are unsupported functions. I found the wiki here, but was quite disappointed to find it so empty. I planned on using a few others like "All Context", and "Is Context Private?" (to get a list of non-private Contexts), and was wondering the risk of these as well.

I know of no XControl that does this. Why is making it yourself "not the solution"? And neither is making an XControl?

So one thing that is worth mentioning that I noticed about these undocumented functions is that the "NativeWindow" method does not work for remote application instances, but the deprecated method "OS Window" does.

Sorry to waste anyone's time. After I posted this I continued my search and I found this private property that works. http://lavag.org/topic/13803-getting-the-window-handle-for-a-fp-with-no-title-bar/

I'm looking for a way to get the HWND (handler window) of a front panel. The trick to this is I want to get this handle on a window without the VI running. The reason for this is I want to bring the VI to open the front panel and bring it to the front of all applications. The only way I know to do this is using a windows call using the HWND of the window to bring to the front. In the past I would get the VI's Front Panel Title (using the VI ref and property node) then get the HWND using this title. Problem is that is the title of the window when it is running. A possible solution is to attempt to figure out what the title of the window will be in the IDE then get the HWND of that. So is there any suggestions on how to bring a VI to the front of all windows, without running that VI? Attached is a test that shows the code working if the VI is running, and doesn't work if it isn't because the title is different. Bring to Front Test.zip