LabVIEW
Named Pipes in Labview
Search LabVIEW like a graph!
@Linze99 wrote:
Well...
Thanks now I found them. But why are they located under System.Core and not directly under System.IO.Pipes?
The assemblies group functionality as MS pleased.
The way .NET classes are organized in LabVIEW isn't how it was intended. In C#, you won't know and wouldn't care. The environment will organize the classes in the class hierarchy. But LabVIEW doesn't 😕.
LabVIEW Classic knows nothing about C# object hierarchy and probably shouldn't try to care. It retrieves the information about .Net assemblies and associated classes from the registry and presents them accordingly. Microsoft has changed a lot about how the object hierarchy in .Net is organized and that doesn't match the way it is registered in the registry anymore. For various reasons the registration can't be easily changed after the fact so we now have the situation that the hierarchy LabVIEW shows, does often not match the C# object hierarchy anymore.
All this information can be retrieved with .NET's reflection tools.
It would be a lot of work, especially to make it efficient.
It would make a nice right click plug in though...
I'm pretty sure if you would try to naively build the entire .Net object tree through full reflection, that the awfully slow LabVIEW object class browser would seem very speedy in comparison. Reflection is great if you need to inspect a known class or its dependency but it is very slow. It's similar to Java's reflection in most aspects (not surprisingly, since the entire .Net implementation is very much a reimplementation of Java concepts in conjunction with a new language, and even that language was in many ways very similar to Java before Microsoft started to add new features to it later).
Yes, the data would need to be cached to get to a reasonable level of performance.
I'm not sure how to decide what data can be cached, but hashing something or checking versioning would probably be the trick.
