LabVIEW
Re-Use of NI_Report lvclass
As we all know, you shouldn't alter VIs and files inside vi.lib; it isn't very portable, changes will be replaced if you reinstall LabVIEW, and it's generally bad practice.
That said, we cannot access a class' private data without a public accessor/mutator or adding a new method to the class. Catch-22.
I can think of a few ways to solve your problem:
- Create a new method for what you want to do in the class in vi.lib (bad practice, but quick)
- Create an accessor for the HTML report reference in its private data
- Clone the NI_HTML class, put it in the project directory and call it 'My_HTML_Report.lvclass' and add our own methods to our heart's content.
I'm not sure why LabVIEW would beep at you, but you may have been having issues with dynamic VIs not being called properly. Creating or altering a copy can be done and is the quickest way of solving your problem:
- Find NI_HTML.lvclass in the dependancies your project explorer
- Right click and add a static class
- Name it 'Edit Title Text.vi"
- Copy the functional global VI from one of the HTML member VIs
- Write a control to the FGV
- Save it
When you want to call it, you need to cast down to the HTML class:
The 'best' way I can think of so far is creating our own HTML class, or inheriting a child class from the NI_HTML class, and casting to it when we need to use non-dynamic VIs. This would also be a lot neater if we want to make more of our own methods. I'll rustle up a little tutorial and post back maybe tomorrow with some screenshots.
Been testing, and cloning the class is probably the best and most portable option.
- Find the NI_HTML class in the dependancies
- Right click > Save > Save as
- Save a copy, called My_HTML.lvclass to your project directory
We cannot use the Report Generation palette's Create Report VI without altering some VIs and enums in vi.lib, so we need to drop an instance of My_HTML and wire it into the new report subVI. The output is dynamic, and by copying the class in the first place, it retain its inheritance from NI_Report. Thus we can use the Report Generation palette to perform familiar methods.
In addition we can add our own static class methods and not need to worry about casting down to our class
It isn't a flaw, and it generally wouldn't be a problem - But it does look undesirable. In order to add new functionality we need to be able to access the private data of the class. (In this case the HTML report reference) Normally in our own class, we would just add the extra functionality as a static or dynamic method. Private methods and data are exactly what they sound like; only accessible within the class**.
When you inherit a child from a parent class, a layer of encapsulation is created. Such that the object heirarchy is maintained, and the whole lot can be passed around as a single object, but any class method will only look at the encapsulated bit that interests them; i.e. its own type. We don't want parents or children to be altering data in an object, but it is often necessary, so we can create accessors and mutators which are defined methods for reading and writing data to the object's private data. Inheriting NI_HTML >> My_HTML Would be of little use, because we can't inherently access the parent's data.
In short, we would normally just add functions to a class we have made and think nothing more of it. However the report functions are inside vi.lib and we don't want to add new things or change things. The only real option left is to override the whole class with our own.
**You can add 'friend' classes in all OOP languages that I know of; where another class can access private methods and data of another class, But I don't like using them. It breaks the concept of encapsulation. Also adding our own class as a friend would involve editing the class in vi.lib which we want to avoid.
I have tried to be concise, but do ask if you still don't get it!
I've just re-read the thread to remind myself of the issue. I assume that you want to add some extra functionality to the HTML Report Generation?
The issue still stands. Adding new methods to the HTML report require access to the "HTML refnum" private data of the NI_HTML class. The direct way to do this is to add a new method to the NI_HTML in vi.lib. A child inheriting from NI_HTML will not be able to access the refnum, so making our own clone of the class is still the best course of action in my opinion.
This should still work, what problems are you experiencing, and what steps have you tried?
