ak_nz

To be honest, that statement in the LVOOP white paper is fairly controversial.

Your simplified process doesn't necessarily require by-reference behaviour, although it certainly makes it easier. If you want to pursue inheritance hierarchies using DVR's then I suggest looking at using GOOP / OpenGDS. It has a proven track record of sorting out the nitty-gritty and letting you focus on the more generic problems associated with reference-based designs.

D'oh! Thanks for pointing that out, ShaunR.

I'll have to keep a lookout for this in the future. Is there rationale that was given from NI for why this (or any other) property is not available?

My guess is it is to do with the scheduling infrastructure built into LabVIEW. VI Server Property nodes in other OSs force running in a specific UI thread, and some actually require full root loop access (root of the LabVIEW execution). To enable such support in a real-time system and provide guarantees on real-time performance was probably impractical. 

We have a lot of third-party IP in dlls here so the Execution System wrappers would help us out a lot (and avoid continuously customizing ini files to extend the number of threads per system). But agreed this wouldn't be beneficial to everyone.

Looks interesting; I have been working on something similar. I notice your naming follows the TPL convention in the 4.0+ .NET Framework, were you inspired by this strategy?

Avoid abusing inheritance hierarchies as much as you can - keep them clear and shallow. Sooner or later it bites you in the a$$.

Wow that was a difficult read...

To More Generic doesn't change the run-time class on the wire, simply provide some compiler guarantees that the class can then be viewed as the parent.

Without sitting down with a strong cup of coffee - your solution sounds like it might work but it also sounds awfully complicated for what is basically an LSP violation in the hierarchy.

I too use the build number for source control. When we don't use a build server directly we have a plugin (Tools menu) that reads in the project source SVN revision and allows the developer to build the appropriate build spec and then reverts the project file to prevent confusion. 

Do you see you logic error in the SubVI1 False case?

In order to create an HTTPWebRequest: there is a factory method in the base class WebRequest: https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest(v=vs.110).aspx. You could then call GetWebResponse to process a response object.

"The HttpWebRequest class provides support for the properties and methods defined in WebRequest and for additional properties and methods that enable the user to interact directly with servers using HTTP. 

Do not use the HttpWebRequest constructor. Use the WebRequest.Create method to initialize new HttpWebRequest objects. If the scheme for the Uniform Resource Identifier (URI) is http:// or https://, Create returns an HttpWebRequest object."

EDIT: Looks like you can only call GetWebResponse on derived classes as you specified. It looks like the WebClient class design exposes this as a virtual seam to override. LabVIEW can't create .NET classes, so in this case you could wrap it up in a basic assembly and use that from LabVIEW. Or use the LabVIEW native APIs to communicate to the web service.

Quick thought - you could probably down-cast the reference and then set the TimeOut and ReadWriteTimeOut properties on the HttpWebRequest reference.

You implied that your C# assembly contain a Form - so presumably you want to show this form from within LabVIEW. Once you have instantiated your form with a Constructor node you need to show the form with the Show() method via an Invoke node.

My understanding is that they both execute in the single UI thread and they have basically the same performance - although the performance similarity is unofficial from an NI support person.

 

Hi all.

 

I am trying to call a VB .NET application develloped in my company.

The Construtor node returns no errors.

However when I use the Invoke Node to call the Show() method, the following error appear: "DragDrop registration did not succeed"

 

DragDrop_error.png

 

The application I am trying to call uses drag and drop menus.

But, shouldn't LabVIEW be able to let those run?

Is there a work arround for this?

 

 

I am using LabVIEW 2014 32-bits and .NET framework 4.5.

 

Thanks in advance for all the help.

 

Regards,

Diogo Ribeiro

 

By application and your description I presume you mean instantiating an instance of the particular Form that you are showing?

Or are you calling the static Main method in the (commonly named) Program class in order to start-up the message pump in order to monitor WND messages?

Here's a simple example that replaces all property nodes that exist for a given control ref with a different type. In my case I have specified a Numeric type; feel free to change this to suit. Note that the VI with the property nodes must be in edit mode for this to work; as a result it might not suit your use case.

My mistake, I assumed you meant replacing the control applied to rather than the destination of the node. Are you sure that Property is the write type? I assumed this was for any Property Node call, rather than the specific PropertyItem GObject.

Yes, it is entirely possible if you have a reference to the object.

Make sure you have VI Scripting enabled in your LabVIEW options (under the VI Server section) in order to see more useful methods and properties of VI Server objects.

Hi gang,

I am in the process of re-structuring a large application to minimise dependencies. The approach taken is to break the application up into buildable components. One of the consequences of this is that many VIs, when moved to another component, are missing SubVIs, including some polymorphic instances. They need to be replaced with versions that are now located in these built components (lvlibps)

I have been able to fairly easily write a scripting tool to locate missing SubVIs and replace them from a search folder but have struggled with polymorphic instances. While I can replace the polymorphic VI itself easily (eg. "Poly Convert.vi") , it appears as if I cannot retrieve the "missing" instance that was used (eg. "To int32" is the missing selected instance); thus I am unable to correctly set the right instance after replacing the VI.

Any ideas? I have many hundreds of polymorphic instances to replace in this project and am not looking forward to the menial work otherwise...

EDIT: An example of what I am trying to replace attached

I like cell. Perhaps Slot?

We make extensive use of this feature - but unlike MarkCG our deployment scope is much more limited (Windows targets only). Besides deleting the cache when the occasional "odd" thing happens we very rarely ever get corrupted VIs now (unlike 2012 - looking at you buddy).

Thank you Jordan Kuehn. I have checked those links. I think there is no much information in first link and in second link is like direct option to printer.

The second link demonstrates an example of the Report Generation Toolkit. The example shows saving the report to an html file.

All it really is is a form of abstraction layer. My understanding in LabVIEW is all it is saying is your messaging API has a child class which implements the TCP, then as you are noting, don't put this in the same libraries as this 

 

Yes, for simple projects we would have a single "Common" library which would contain the abstractions needed by the other hierarchies. Only this Common library would be automatically loaded into memory by it's callers. We have found that sometimes 'stairway' requires a bit too much lvlib maintenance to be truly useful on all but the larger projects. I'm interested in your experiences and patterns for this.

I quite like smithd's rule of thumb, (wildly paraphrasing!) if you wouldn't give them all the same icon, I wouldn't put them in a library together.

This is probably my main take-away point as well 

I did.

 

(That is, after years and N00's hours investigating LVLIBs in the context of namespacing/distribution/building/linking/encapsulation/scoping/reuse/load time/dependency management and so forth. James, I am not surprised if you independently draw the same conclusion, and I'm interested to hear if you conclude otherwise.)

Do you favor LLBs as the alternative? I'd be interested in hearing more of how you manage the same use cases.

Fair example. I tend to end up making simple interface classes for this situation but I know they aren't for everyone. Ideally I would have 3 lvlibs. A would be the messaging component, B would be the tcp component, C would just contain the set of functions which tie them together. I'm doing something similar with a file loader right now. I want a generic hierarchy of essentially key value pairs so that the lowest level component can be used everywhere. In the actual application I'm trying to write I have a file loader which loads my particular hierarchy which includes a system configuration object that contains N process objects which contain M plugin objects. So now that I've gotten the two libraries where I wan them, I'm writing a 3rd library which converts between the very generic hierarchy and the specific hierarchy, as well as allowing for some useful manipulations of the data set (lets say I only want to load process #4 and its plugins, but not the rest of the system).

Edit: Its worth mentioning that while this is something I am definitely doing, I'd probably simplify it if I were writing from scratch -- I'm trying to refactor months of work so it can be used on a few different projects, which is why having these weird dependency links is currently desirable.

 

Downsides to this are that it can't always work (but usually works enough for me to not worry about using lvlibs) and it does lead to occasional instances of bloat and situations where I have to convert between the types used by the different libraries, but it seems to work well enough for my purposes.

A comment on smithd's description of "package management" with lvlibs - this type of management is common in our other Java and .NET applications for packaging dependencies. Discussions around how to manage packages in order to reduce dependencies / coupling between dependencies has been a common topic of discussion in the development world (outside of LabVIEW) for many years now. LabVIEW has it's own take on the same concepts. We typically try and use the "stairway" pattern for dealing with dependencies but that relies heavily on LabVIEW "interfaces/abstract" classes. It works most of the time; on occasion we have the same sort of bloat but that typically occurs when we have multiple copies of basically the same dependency loaded from different packages.

At work we favor packed project libraries for production deployment (VIPM packages for development deployment) so lvlibs are unavoidable for us.

But we do run into the "load the earth" scenario too. The best compromise we have found is to break down the component into smaller pieces.

As ak_nz and drjdpowell have both said, it is perfectly fine to implement concrete code in an abstract class. This lets you make full use of inheritance to keep your project tidy and organized.

 

 

 

"Rules" and "best practices" are established to guide you down a tried-and-true path, to maximize your chances of succeeding the first time you try. However, a set of rules will never cover all possibilities so simply following rules will not guarantee you success.

 

As the software designer/architect, it is your job to decide whether or not it makes sense to follow a rule in a particular part of your project. Referring to the two quotes above, I'd say: "It's ok to inhibit parent behaviour if 2 out of 20 children need to do it, but not if 18 out of 20 need to do it. If 10 out of 20 need to do it, well... make a judgement call."

Yes, this is an interesting design problem that inevitably ends with a different answer for each developer - what percentage deviation from LSP are you comfortable with? It is a slippery slope - so be careful. And document the limitations so that the next developer to follow you understands the trade-offs you made - they might follow your example in a way you didn't expect. As the quote goes:

 

tl;dr: throw errors in parent functions which shouldn't be called. Its a good idea.

I do this for hierarchies where a child class doesn't support a particular function - the default parent behavior is to generate an "Unsupported Operation" error. Still I personally only do this if I think the number of operations or number of classes in the hierarchy won't really increase (ie. percentage deviation from LSP is small). If I find that I have multiple levels of undo in multiple operations in a hierarchy I wonder how maintainable this codebase will be by the worst critic - another independent developer.