LogMAN

Are you working on a notebook by any chance? In my experience LV2016 and LV2017 (never tested SP1 though) get stupidly slow if the graphics card is not powerful enough to render the selection box. Notebooks in particular use CPU integrated graphics and only utilize the "real" GPU if a program requires more demanding 3D capabilities. LabVIEW doesn't fall under that category (yet). For the few test projects we do in LV2017 we use a sufficiently overpowered machine that can handle virtually anything you throw at it (designed to rendering 3D images from one of our cameras). It's ridiculous. Still not sure what to make of it...

Technically, no repository should ever grow to that size (as in "best practice"). Especially executables and installers will never change, so there is no reason to keep a history of it. I suggest putting them in a separate folder. For the same reason LV allows to separate compiled code in the first place. If you insist on keeping these files in the repository, consider making changes to the structure of your repository to keep it manageable. I've been in a similar situation in the past, where a repository exceeded a size of 10 GB. Very painful to pull and push, even on a local network. That repository contained installation scripts and of course the installation files that were bundled with it. Similar to your situation, these support files were the main reason for the size of the repository. The solution was simple: Split the repository into two repositories. One repository contains the installation scripts, another the support files. The repository with the support files was made a submodule in the main repository (using git submodules), essentially keeping the original structure in place. To reduce the size of the main repository, history was simply rewritten using git filter-branch. Don't do that! First create a copy of the repository and then make changes to the copy. That way the old repository can be archived for future reference (lessons learned 😅). Of course, the repository for the support files also grows over time. The solution is to create a new empty repository for every major revision (or whatever fits your needs) and re-link the main repository to it. It is still possible to checkout older revisions (the ones pointing to the "previous" repository) but it requires re-initializing submodules when doing so (because it points to a different repository). I had similar issues on Windows 7, where the build fails if the output folder is open in Windows Explorer. You should take a look at the application builder palette and automate the process by moving files after the build finished. We did so recently with great results. With a simple click of a button it builds all files, puts everything in a ZIP file (named according to naming standard) and moves it to a secure server location that is automatically shared to everyone who need to know about it. The only thing needed is to set the build version before pressing start and to commit (and tag) after it finished. Hope that is of some use.

Parameter bindings require you to follow specific syntax. It is explained here: https://www.sqlite.org/c3ref/bind_blob.html '?-x' gets interpreted as parameter, which doesn't work. Two solutions come to mind: 1) Use the concatenation function like you suggested. This makes sense if the suffix is static for all parameters. 2) Do the concatenation before binding the parameter (i.e. in LV). If your suffix can change, make it part of the parameter.

Indeed, the location is different => https://lavag.org/applications/core/interface/file/attachment.php?id=13529 If you go to your profile (icon in the top right) and select "My Attachements", the files listed there show a different file location than the ones in posts. Here is mine from above: My Attachments https://lavag.org/applications/core/interface/file/attachment.php?id=13701 This one probably works (not tested, just a guess) Edit: it doesn't. Post https://lavag.org/uploads/monthly_2019_01/591079262_AccessingElementsinaFor-Loop_vi.png.739aeb22d70a5a697b28a8358c333ffb.png

If you are set on doing multiple queries in the same loop, here is another example that might help understand how it should work. The VI is executable, using dummy data. I've also attached the VI for LV2014, so you can play around with it. Using Multiple Prepared Statements In One Loop.vi

You are right, my bad. Yes and no. The SQL Prepare function creates the SQL Statement. It allows you to run the same SQL query multiple times, but more efficient. I've attached an example in my last post, using your SQL query: SQL Prepare (second VI from left) receives an SQL Connection and the SQL query ("SELECT * FROM sueli WHERE d = ?"). Note, that it says "d = ?". The "?" will later be replaced in the loop by the actual value. In the for loop, the first node does exactly that. It replaces "?" by an element from the list. Note that you can have multiple values, using multiple "?" in your query. SQLite First Step (the next VI) executes the query once and you can read the results using the node that follows (Get Column String). Before running the same query again, you must reset the SQL Statement. Note, that everything takes place within the loop. When the loop ends, you need to finalize the SQL Statement or it stays in memory. You must finalize each SQL Statement separately. In your example, everything is inside the loop, so you gain nothing by using prepared statements. SQLite Prepare and SQLite Finalize must be placed outside the loop. I suggest you split those SQL Statements into separate VIs or it will be very confusing. Yes, they all share the same connection. Actually, the snippet was attached, but Lava removes the source code of snippets right now (download the image and drag it into LabVIEW). Can you copy the code into a new VI and post it here?

Unfortunately it isn't. Can you check again? Here is one of my posts for reference with multiple code snippets (also some of the previous posts as well): The first image has an original size of 26,392 bytes but the file in the post is only 12,304 bytes. That is the fully-zoomed image from here: https://lavag.org/uploads/monthly_2019_01/591079262_AccessingElementsinaFor-Loop_vi.png.739aeb22d70a5a697b28a8358c333ffb.png Let me know if I'm doing that wrong

My general advice for refactoring code is to do it step-by-step. Don't try to fix everything at once, as it will likely break your code (as it did in your case). Note: I wasn't able to load your VI snippet. I'm not sure why though (either I'm to stupid to do it or Lava sanitizes images) My suggestions below are based on your original VI Step 1 - Improve readability Arrays and for loops The outer for loop iterates over multiple arrays at the same time. This means that the loop will end after processing each element of the smallest array. I suggest you use one array for iteration and use the Array Index function to access elements from the other arrays. Here is an example: You should play around with it to see the different outcomes. Note that indexing an element from an array of smaller size returns a default value (i.e. zero for numbers, an empty string for Strings and false for Boolean). Shift registers The outer for loop uses a shift register for the SQLite instance as well as the error cluster. The inner for loop, however, doesn't. This can be problematic for two reasons: 1) The SQLite instance in the inner for loop gets reset after each iteration. 2) An error in the inner for loop is reset after each iteration and only the last error is returned. The solution depends on what you want to do. If you want to abort as soon as possible on any error, I suggest not using a shift register but making the for loop conditional instead (exit on error). Otherwise use shift registers on both loops. Step 2 - Optimize your code Use transaction outside of for loops Transactions are very useful for improving performance if used correctly. In your second example, you already added the BEGIN and COMMIT Transaction using "MySavepoint". This is generally a good idea. Disable transactions on Execute SQL The Execute SQL function has an optional input on the top which you can set to false in order to disable transactions. This will already improve performance considerably. Answering questions SQL Prepare and SQL Finalize should be placed outside the for loop and you need to inject values for your parameters at some point (unless your SQL Statement is static, which it isn't according to your info above). The "INSERT many rows Template code.vi" provided by the library (see Code Templates palette) visualizes that very well: I highly suggest not using "SELECT *" but explicitly selecting particular columns instead. That way your SQL Statement becomes predictable. Here is an example that may or may not work (I can't test it for obvious reasons): I suggest making a VI for each statement (without transactions of course). That way you can test things in isolation and be certain that it works. I'm not sure what you mean by that. Can you explain what you mean in more detail?

You can use git-svn to make your dreams come true (and nobody will know) ? https://git-scm.com/docs/git-svn

I agree. It just needs to be more visible to users (i.e. by putting "Downloads" in the main navigation bar next to "Leaderbord") It also brings us back to this poll

I agree to what @ShaunR said, but let me add to it: The library is not dead, because it is still functional and very useful - especially for new developers as mentioned earlier. The project, however, is dead. As you correctly pointed out: Technically anyone could fork the project (on whatever platform - SourceForge / GitHub / BitBucket - you name it). Development could even continue under a new name (probably even the same?). Yet the number of licenses being used right now is impossible to maintain, even for experienced developers. OpenG is also tightly coupled with lots of services (i.e. NI and VIPM link to the official repository on SourceForge). To my understanding (although I don't have facts on this), the lack of response in the main repository is the reason to why libraries like MGI were found in the first place. Just look at the bug tracker https://sourceforge.net/p/opengtoolkit/bugs/ This is also not the first time we discussed the (possible) future of OpenG. Here is a thread from two years ago: The complexity of the main repository (i.e. the folder structure) also sets the bar very high for novice contributors: https://sourceforge.net/projects/opengtoolkit/files/ And let's not forget the difficulties in comparing VI revisions in general. All things considered, the project is not a simple task anyone could just pick up and get going. Lot's of things need to be considered, which requires lots of experience in LV. Of course, most experienced developers have no interest in contributing to the project if it involves lots of administrative tasks on top of their regular job. Maybe a shared library like OpenG is not the right solution for LV. A simple place to share VIs might be easier to manage and contribute to in the long run.

We used the OpenG library a long time ago, when LabVIEW was still new to us and we could leverage the power of OpenG to accelerate our development (between LV6.1 and LV2009). This is in my opinion still the strongest point of that library - it provides new developers (or teams) with lots of useful functions at the cost of dependencies. We have since walked away from it due to incomprehensible copyrights, lack of updates (although it is very stable) and generally because we used few functions to begin with (i.e. Fit FP to largest decoration, filter arrays and some string manipulation). At some point the dependencies mattered more than the benefits. What we needed was rebuild in our own library, removing all dependencies from OpenG. If the OpenG library were to be cleaned up, just removing functions is not a good solution because it breaks compatibility for anyone who depends on it. On the other hand, dependencies between the libraries can easily be removed. For example, there is no need for OpenG String to depend on OpenG Error anymore. Instead OpenG String could be updated to remove the dependency (using only native LV functions) and still keep OpenG Error in VIPM. OpenG Error on the other hand is technically unnecessary nowadays (as pointed out by @smithd above). This library can be archived (while keeping it in VIPM). Here is what we do with our libraries when they become obsolete: Remove obsolete VIs from the palette (but keep them in the vi.lib) Change icons and documentation to highlight obsolete VIs (similar to how NI does it, by adding red color to the icon - the more the better) Explain in the documentation why the VI is obsolete and how to replace it Add replacement code to the block diagram of the VI Remove password protection Enable inlining if possible That way, when you come across obsolete VIs, you can simply use the "Inline SubVI" command to replace it: https://forums.ni.com/t5/LabVIEW/Inline-subvi/m-p/1279086/highlight/true#M532443 Of course, sometimes changes may destroy the block diagram of the calling VI, which is why those VIs have password protection removed, allowing the developer to inline the VI manually.

Please share ? Amen. I was working on a nasty bug for the past few days as well. The source code looked fine, but the application didn't do what it was supposed to do (or so I thought). As it turns out the executable did exactly what it was supposed to do. And I was looking at the latest code, testing old software... Reminder: 1) Always include und update the version number in your executables (and configuration data if possible)! 2) Work with the source code you used to make the executable! 3) If you are experienced enough to skip points 1 and 2, see points 1 and 2!

Yes, at least since 7.1, maybe earlier.

Sorry, my bad. I didn't see the "Something went wrong" message, thought we were talking about the "Optional Profile Information".

This is awesome! Thanks Michael I see the same notification using regular login (email + pw). Caching doesn't seem to be the issue. There are likely some new parameters which weren't available in the previous version. Edit: Here is a capture of the requested settings (it says "optional" but if you click "Skip this step" it will continue requesting info): Update: Pressing "Dismiss" on the notification seems to work for me

Are you looking for something like this? https://docs.microsoft.com/en-us/windows/desktop/api/wincred/nf-wincred-creduipromptforwindowscredentialsa

Here is a KB from NI on this subject: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7qjSAC

Which font do you use? On Windows we have "Small Fonts" which is the only readable one. Something similar should exist on Linux.

If anyone is interested in finding incorrectly connected Constructors automatically, here is a VI that will do that for you: It's not very fast, but it does its job. The result is a list of VIs with the total number of Constructor Nodes found and the number of Constructor Nodes where the first terminal ("new reference") isn't connected. This is an indirect solution because the offending terminal officially doesn't exist (not accessible via scripting).

Thanks for reporting @_Mike_ Turns out the terminal adjusts to the object type (object or enum). In your case the Constructor is for an enum type, so it actually returns an enum instead of a reference. Here is another example: This is the corresponding definition according to Visual Studio: Very interesting behavior indeed.

@Darren Would you be interested in adding another detail to the CAR? Just for fun I went to see if I can break other nodes and actually got strange behavior from the Call Library Function Node in a very similar way (using LV2017). You can connect the "path" terminals, even if the option "Specify path on diagram" is not checked. I understand that this is probably a design choice to prevent wires from vanishing when unchecking this option and it doesn't do any harm, but the wire should break. Unfortunately, the output wire doesn't break initially: Notice: I just placed the node and connected the wires. The options dialog is open to show the checkbox is actually not checked. Here is what I get after pressing the "OK" button on the dialog (you don't have to change any settings for this to work). You can see the wire is now broken, as it should be: This is only a cosmetic problem because the function breaks as soon as you press the "OK" button. The behavior is strange nonetheless.

Thanks everyone! It's good to know I'm not (yet) going insane Sorry for not mentioning how reproduce the issue in the first place. I suppose one reason this never occurs to anyone is because we all start wiring from the Constructor Node for obvious reasons, except sometimes we don't. Awesome, thanks for sharing! I'll inform my team to keep this in mind.

Okay, I just finished testing on various machines (virtual an non-virtual) with various LV versions and all of them support this feature! It is very unlikely that we somehow broke all machines and versions in our department for the past 15 years exactly the same way (although there is always a chance ). Find attached more snippets for all versions I checked (for 7.1 and 8.6.1 I had to take screenshots). I've also attached the VI for LV2017. So, in total I've positively tested these versions: 7.1 8.6.1 2009 2011 2013 2015 2017 Unfortunately I currently don't have a 2018 Installation to check. It works just fine. We can load, edit, build and execute the project and all executables. Darren, which version of LV have you been using at that time? Could this possibly have been changed in LV2018? Constructor Terminals LV2017.vi

Thanks for looking into this Darren! On my machine these terminals are permanently available even after a reboot and with a new VI. I just removed all VIPM packages and cleared the compiled object cache, restarted LV and still can connect those terminals. Also tested this on a different machine and got the same terminals. This is a very bad sign indeed, I don't see any warning whatsoever. This means it's either a bug in this particular version of LV [15.0.1f10 (32-bit)] or my installation is majorly broken somehow. Not sure what could have caused it though. Unfortunately I can't do that. My application builds perfectly fine (no broken arrow, no exception, no error) while connected to the wrong output terminal. This could potentially be harmful if it somehow effects memory. I'll check if this is still an issue with the latest (f12) or one of the previous patches.