Leaderboard

An unofficial response: avoid this primitive. It was requested by a group within NI and it turned out they didn't need it halfway through its development. In a lot of cases it can create a compile error. In some cases it will cause a crash on save. The author says that it was never thoroughly tested (so don't expect IEEE 754 conformance!) and that bug reports for it are rejected since it was never officially released (not even for internal use). This is a prime example of digging around in LabVIEW and finding fool's gold instead of actual gold.

Everybody knows the problem: We need custom VIs to compare floating point values using a tolerance. I just discovered something via scripting: The Floating Point Equal? primitive which does exactly that. Can anyone imagine why it is missing from the standard palette? It's in LV since version 8.0 ... FloatingPointEqual_LV80.vi

Yes. There's only reentrancy if you explicitly make your method VI reentrant. In many cases this might not be a problem, though. What are you trying to accomplish?

Yes that's correct a project is a manager of files while a library/class manages code Ton

Nothing elaborate really. For this specific problem you can flip things around to delegate ownership of any pages to implementing classes, and have the parent class define a method that returns any pages which get operated on. For example Dialog:GetConfigPages returns an array of pages which is called by any Dialog method that needs those pages. The Dialog implementation can return any pages which might always be there, or an empty array by default. Any implementing method appends it's own pages to those returned by its parent. However I don't think this suggestion is any more "correct" than your implementation-- I've certainly used both models.

In my opinion there's nothing inherently wrong about using the to more specific class primitive in this situation. There definitely other ways to tackle this but let's stick with your original implementation. Be aware that since the base class likely manages access to the Channel Config Dialog Pages at the Dialog Page level, you have to be careful about assuming you can say all the contained Dialog Pages are in fact Channel Config Dialog Pages. Even if the accessor is protected, you have to make sure that all access to the contained Dialog Pages is protected and that none of the public methods of the parent can set Dialog Pages. If this seems inherently fragile, it is, but it isn't necessarily wrong. Just be mindful of error handling. I'd also suggest ditching the property node in favor of an accessor which is more modeled after the polymorphic primitives that LabVIEW uses where they have a "type" input. This is a prime candidate for the preserve run-time class primitive: Why would I do this? It puts the type checking all in one place so you don't need to do it each time you want to access your pages. It also is very handy for coding because the wire type changes dynamically at edit time depending on what you wire to the type input: