hooovahh

Well what toolkits do you have installed? I've never heard of such a screen before, but I'd suggest finding that toolkit and re-installing it, either through VIPM or NI Uninstaller depending on where it came from. You might also get away with forcing a mass compile on the toolkit, again if you can figure out what one it is.

Crosspost

Well they aren't the same, or made by the same company. There are likely features available in one and not the other, and you likely paid for any support you needed. That being said I'm super impressed with the Exaprom one and wouldn't mind paying (a reasonable) fee if I needed it.

Be sure and share it with the community, others may have similar questions.

Michael worked his magic, that he does so well and things should work now. I tested it on a pretty large block diagram and my browser zoomed out, but the image itself wasn't scaled on the server side, so I could still drag the snippet away and then into my blank block diagram.

I think I reproduced the steps you took, but I came to a different result. I posted a reply using the More Reply Options which is also known as the full editor. From there I picked the file by clicking on Choose File. Then I clicked Attach This File. This step might not be needed depending on the version of the uploader that you are using. Then I clicked Add to Post to add it to my reply. I was then able to click the image and get the VI source by dragging the image to my desktop. I wonder if it has to do with the size of the PNG you uploaded. It obviously scaled it which makes me think there is a maximum resolution the uploader accepts. EDIT: Yup just tested it, too large of an image is scaled, I'll let Michael know about his and see if there is something that can be done.

It sounds like you are using the wrong kind of reentrant VI. The NI signal processing VIs uses the Preallocate method of reentrancy which is less efficient than shared clones because a new copy must be created for each copy, instead of reusing already made copies. The benefit is of course things like uninitialized shift registers work as expected because each copy is reserved for that call.

Recently the PDF creating toolkit using ItextSharp by Exaprom has been updated to version 2.0. https://decibel.ni.com/content/docs/DOC-10952 The toolkit is very well put together and I've used it on a couple projects. The example generates the manual for the toolkit, and it is pretty impressive to see all the features of the toolkit demonstrated, by generating the user manual.

So you have a 2D array of numbers, and you want to find the perimeter around an object outlined by values of 1? There are probably tons of ways to achieve this. Look on the array palette and see what you can come up with. I'd suggest reshaping the array into a 1D, and use the search 1D array looking for 1, then that used with the quotient and remainder can give you the upper left edge. Similar functions where reversing the 1D array could get the lower right edge. If you get stuck post what code you've come up with.

Hey that's pretty neat. It remind me of one of my favorite XControls the Variant Probe, where a variant can be displayed in a colored tree.

In many cases a private method was made public, so there is no reason to password protect a VI. But in some cases these methods have new inputs or outputs between versions, so back saving would break the code. You'll then need private methods enabled so you can pick the older version if this is the case. If we just made all private methods public it would take care of this problem...and create many more.

Then using a DAQ card is going to be a problem. If you install DAQmx you're going to be required to install MAX. Then you can import your MAX NCE and use the tasks and channels in MAX, or use DAQmx VIs to programatically make your tasks at run time. Oh or the third option I don't usually do is you can have the tasks be in the project which then get deployed to the EXE when it is built. If you are really insisting on using LabVIEW 7.1, which is something like 11 years old then I'm unsure how much of what I said is going to be true for you.

I understand where you are coming from, but even when I was in that type of industry, explaining that things get done faster, and cheaper when trusted toolkits are used instead of reinventing the wheel, usually persuades the customer. It sounds like you are in a culture that doesn't use OpenG and it would be difficult to bring that in. I'm in a culture where using OpenG is expected, so taking that away would be difficult. Our applications are dependent on it, and so we always trying to make using and installing it as easy as possible. Same with other trusted toolkits like JKI, WireFlow, MGI, and others from LAVA. Again IANAL but I don't know if attributing OpenG as a consortium meets the needs or not. For now I think that is what I will try doing, but in the back of my mind I'd like to scan installed packages, and generate a license text file.

I am not a lawyer (IANAL), but I was using the following definition for Credit Publicly acknowledge someone as a participant in the production of (something published or broadcast). If we are trying to disclaim liability, I'd suspect leaving someones name off of a list of developers who influence the creation of the product would be what is desired. If that is the purpose couldn't I just say any code developed by someone other than me, used in this product are not responsible. Same here actually for some of my Code Repository stuff on LAVA.

Probably this. You'll probably need to use some kind of system function to get the origin path of the junction point, and then get the free space on that path.

While I think this is the easiest solution, and probably something similar that I'll adopt, what if you only used on subVI made by one guy in your build? You are crediting a few dozen people when really it should be one guy. Could I take this to the extreme and credit every human on the planet, and then never need to worry about forgetting to credit someone?

Okay attached is a VI that can be used to parse the arguments into multiple arguments. By default the delimiter is && but another one can be provided. Saved in 2013. Parse Multiple Arguments.vi

Whatever I guess, I just assumed that you'd continue to use the JKI delimiter of >> Something like: Enable Control >> Save Button >> Exit Button Where this case "Enable Control" could enable a set of controls, but I suppose && could be used just as long as it is clear that is how this N arguments works.

Feedback on the JKI State Machine would probably be better heard on the JKI forum. As for your comments 1. I think the "Default" case could be made to exit. The only time you should see that error is during initial development, when you try to go to a case that you haven't written yet. In this case going to exit is not a bad thing because I'm going to want to stop my software anyway to fix the typo or write the case that I meant to have. 2. The JKI State Machine already has several sections, for Core, Data, Macro, UI, and even has a template category. I've seen some others add a "Decision" category and try to limit decision making to go in those types of cases. After re-reading your comment I see you are talking about cases in cases. I think this could get confusing. But honestly I have done it in the past for a group of cases that are similar like "Defer Panel" and "Undefer Panel" but really arguments could be used here.. 3. This is probably a good idea, but I'd argue that the majority of the time a case has no arguments, let alone N arguments. The extra overhead of using something like Spreadsheet String to Array on every call of Parse States seems unnecessary. I'd recommend making a subVI that just takes the scalar string of arguments, then uses Spreadsheet String to Array with the delimeter being ">>" then return the array with white space removed. Then you can call this VI in the cases where you know you entered more than one argument.

Oh good point. When I did this in the past I would actually send the error back with the reply. So if a request was made to an analog actor to read some data, it would attempt to read the data then send it back, along with the data it would send back the error generated from the attempt to read. Then the request gets the data and an error, and the error would then be handled where the request was made.

Okay so it is clear to be in accordance with the BSD license in a binary build, we need to attribute the author(s) somewhere. That can be in several forms, but the easiest to talk about is a About window. In your application you can have an about screen, and there can be a button to click or a link, which opens up and shows the detailed license information. For BSD this is required to be a copy of the BSD copyright notice, and the list of authors. This is how JKI does it with VIPM, clicking on About brings up a window where you can click Copyrights. The question that comes up is how do we easily generate a list of authors, for BSD code that is used? Certainly a pre-build on an application builder can be used to run a VI that generates this text file, which is included in the project. But with this is a few issues. First is potentially large number of files to scan. OpenG has many polymorphic types, and so using scripting to look on the front panel of every VI called looking for the copyright notice might take a decent amount of time. I think a better approach would be to include the authors associated with the package. So if you use the OpenG Tick Count (ms).vi instead of attributing just Jim Kring, and Jean-Pierre Drolet, you'd also attribute Jonathon Green, because he is associated with the package and not that particular file. In my opinion this is fine. We are attributing all authors of the module we are using which is the Time Library. If we go with this technique it would be much easier to attribute authors because you only need to scan the installed packages, and not every file called. Another potential problem is with non OpenG BSD licenses. OpenG has a standard front panel comment attributing authors but other libraries may not. But again if we decide that going with installed packages is sufficient, we can pull the author information from the spec file from each package installed. What about VIPCs, can they be used in making BSD license management easier? A VIPC is a collection of packages, that usually are associated with a specific project. VIPM pro has the feature to scan source code and create a VIPC which is the packages, and versions, that the source uses. This single VIPC file could be made for a project, and then scanned for licenses and authors, which could then create the BSD license file that needs to be included with the application. And lastly another concern is that you maybe using BSD code not installed as a package. Some LAVA Code Repository stuff is not in a package but licensed under BSD. What ever Pre-build functions that are made are going to need to support including BSD attributions that aren't just packages.

I feel like we are hijacking the thread a bit, but it is a curious topic. I've just always used OpenG, it's always been there with the huge benefit of not having to develop, test, and document functions. Of course it is possible I've been using it wrong all these years. As for attribution can't you just use the copyright notice on the whole package, and not the individual functions in them? I was thinking of writing a VI that just takes all the attributed individuals in the OpenG libraries, and making an OpenG BSD License.txt that can be included with the software documentation. But I do see the point others are making, that the effort in complying with a license, might be more work than the functions themselves. And if that is the case it is quite discouraging for the user of the library and the developers. I know OpenG has wanted to make things simpler with various license changes in the past, but what I feel would be really nice is a simple "This is what you need to do if you use OpenG in an application".

Is there a reason you don't use the Filter Error made by OpenG which accepts a scalar or array of errors to filter? This was made native in 2014, but only accepts a scalar for some reason.

Removing the block diagram is a much better solution, assuming you can live with the fact that the code will not be able to be recompiled for other versions of LabVIEW. You can edit the code linked by jcarmody to save without block diagram. Right now there is a constant for it.

Your upload is missing a file, luckily it was just a type def'd cluster and I could disconnect it to see how it worked. From your description I didn't think I'd like a design where a while loop is inside a case of an event structure, but having it be encapsulated in a reusable subVI makes me like it for some reason. I also don't like how this is polling in a while loop where an event structure could generate new events for a mouse move, but then again the refresh rate is configurable, and it is only for the time the mouse is down. A different design could be using the Limit Maximum instances of a mouse move event to 1. But then that's more work in the VI using this function, where your technique is pretty easy to incorporate into a new VI. It could be reduced even more simply by the init and close in the subVI, possibly keep the reference open with an uninitialized shift register. You can also read the calling VI reference. The result could be a single VI, that you put into a Mouse Down event, that takes care of a window move. Attached is some of these improvements. Thanks for sharing. Drag Drop Hooovahh Edit.zip