Prototype replacement for error.llb -- Second Attempt

[Aristos Queue]

So, after trying to post these VIs a few weeks ago, getting (rightfully) turned down by LAVA gurus for submitting prototype code to the finished code repository, and then accidentally mass compiling my VIs in a non-shipping build of LV (you can read the whole debacle here), I'm ready to try this again...

I have ready a replacement for error.llb. This replacement uses LabVIEW classes to (in theory) massively extend the power of the General Error Handler.vi without adding to the in memory footprint of that VI hierarchy and simplifying the existing code. Great theory, huh?

If you use LV8.2, you can download it from here:

http://forums.lavag.org/index.php?act=attach&type=post&id=5290

INSTALLATION INSTRUCTIONS

While NOT running LabVIEW, delete your existing LabVIEW 8.2\vi.lib\Utility\error.llb and unzip the attachment in its place. You probably don't want to actually delete error.llb -- just hide it somewhere that LV can't find it (don't just change the file extension). To uninstall, delete the unziped files and put the original error.llb back.

Note: this replacement works fine for MS Windows. It frequently crashes the Macs with Intel chips. I do not know about Mac PowerPC or Linux -- I strongly suspect (based on MacTel crash logs) that they work fine and the crash is just on the MacTels, which are not officially supported by LV8.2. This entire project a prototype, not a finished product, so do not use this in any product you intend to ship.

This is released for your use under the same license that NI uses for anything in vi.lib -- you can modify, copy, distribute, etc, to the same degree that you could with any VI that is in vi.lib. Any rights that NI reserves vis-a-vis vi.lib apply to this download.

WHAT DOES THIS REPLACEMENT DO?

The error code cluster is LV's tool for passing error information through a diagram. Eventually, these clusters are displayed by the General Error Handler.vi (aka the GEH) in nice human readable form. Some years ago, the DAQmx team asked about the possibility of displaying charts/graphs in the GEH for certain types of errors. This was shot down because the already-complex GEH would be bloated trying to have custom displays for various errors, and the maintenance of tracking which dialog went with which error code would be a headache at least.

In LV8.2, LV introduced classes. Classes allow the data on the wire to define the behavior of nodes, so that a given subVI call will actually invoke different subVIs based on the data on the wire. This seems like a great solution for DAQmx's request for the GEH, except for the overhead of replacing all the error code clusters in LV with a LV class. Ug.

This replacement for error.llb allows us to hide a flattened LV class in the Source string of the error code cluster. This string, which already carries formatting and encoding data, can be unflattened in the GEH and then acted upon. The advantage is that different types of errors can then be made that have their own error displays WITHOUT adding any code to the GEH itself. In fact, the existing GEH code can be simplified rather significantly. A user would only pay the price of having another handler in memory if his/her code actually generated an error of that type. That's important if the capacities of the GEH are to be significantly expanded.

HOW TO MAKE YOUR OWN ERROR TYPE

An example of a new error class -- one capable of displaying pictures in the GEH -- is attached here:

http://forums.lavag.org/index.php?act=attach&type=post&id=5291

The project file included with the .zip file shows User-Defined Error.lvclass. You should generally make any new classes inherit from that one. A LV class cannot be inherited from when it is running, and you'll find that the base class "Source Error.lvclass" is frequently locked because it is used by various parts of LV internally (we do write a lot of LV using LV). The User-Defined Error.lvclass should (*ahem*) never be used as part of LV's internals and thus is unlocked and available for inheriting.

Picture Error.lvclass inherits from User-Defined Error.lvclass. You can follow the basic idea of Picture Error.lvclass to create your own error class.

1. Create a new class. Make it inherit from User-Defined Error.lvclass. Edit the class' icon to suit your taste. Consider following the new iconography guidelines.
   
2. Add any fields you need to your class' private data cluster.
   
3. Create a VI in your class that is the subpanel that will be displayed in the GEH. The subpanel must match the conpane of Picture Error.lvclass:Details Display Dialog Picture Subpanel.vi. (This is a prototype -- I've used the 5x5 conpane here because I've added and removed various terminals so many times and I occassionally overflowed 4x4...) The "Error.lvclass" input can be safely downcast (use the To More Specific node) to your specific class type... the code guarantees that this downcast will always work, so don't worry about the error out (there are tricky aspects to handling errors that occur in the error handler itself...).
   
4. Use New>>Override VI to override Get Subpanel.vi. Edit your new VI to return the subpanel that you created in the previous step.
   
5. Now go use your new error where you will.
   

If you look in LabVIEW 8.2\vi.lib\Utility\error.llb\ you'll find a .lvproj file that was used for defining the new class structure for errors. In that project, you can see the functions that are currently available in the palette, plus 4 more that would likely be added to the palettes if this project becomes more than a prototype. You'll also see two other classes of errors that are already used in the GEH to handle existing special cases.

FEEDBACK WELCOME

I welcome your feedback on this prototype. The code works in LV8.2 (on Windows at least). I do not have any inkling of when, if ever, this would replace the error.llb that ships with LV, but it is something that I'm investigating.

Specific areas of interest:

1. I'd really like for the subpanels to be live and running so that complex error information could be displayed with animation or interact with the user. I've written the Details Display Dialog.vi to make two calls to the subpanel VI -- one to size the subpanel, the second to run the subpanel. But I keep getting error that the VI is not in a runable state when I call it the second time. Someone with more knowledge of subpanels might make this work.
   
2. Improvements to the API. I don't particularly like the conpane for the subpanel, but I've tried to make it as extensible as possible, so that as much code can be reused by people who add new overrides as possible. But as you can see, a lot of code was duplicated in the Picture Error.lvclass subpanel from the default subpanel VI.
   
3. Feedback on how much memory this actually takes up normally vis-a-vis the existing GEH when handling run of the mill error clusters.
   

Thanks.

[Tomi Maila]

Hi Aristos,

As you already know, I support the idea of refactoring the error management system to use classes. So great work! You wanted feedback so here is my initial feedback.

- As a general remark I had difficulty following some of the code as it doesn't fit to my 1680x1050 screen and it wasn't very much commented

- All connector pane terminals were not clear to me as they didn't include a description

- The requirements for the subpanels of each user defined error class are much too heavy currently. New error classes should be very simple by default. Try to simplify the structures of subpanel construction. Perhaps the default functionality of most subpanels can be encapuslated to some error dialog helper classes.

- I think by default a new error class shouldn't need to define new subpanel. I don't know if this is the case. I didn't check it.

- I think normally each error class should include a single method that can be used to create an error of that class

- There wasn't yet any means of catching errors. I think catching errors is even more important that displaying error information. I guess you are going to work on this side as well.

- This is just a wild idea. Perhaps you could allow subpanels that are interactive i.e. that stay running during the display. This would allow interactive trouble shooting dialogs.

I try to study the example in more detail later on.

Tomi

[Aristos Queue]

QUOTE(Tomi Maila @ Mar 27 2007, 12:32 PM)

- This is just a wild idea. Perhaps you could allow subpanels that are interactive i.e. that stay running during the display. This would allow interactive trouble shooting dialogs.

I'll look into the rest of your suggestions, but on this one --- I do want the subpanels to be running. There's a bug in Details Display Dialog.vi that I've been unable to overcome. I make two calls to the subpanel VI. The first call the subpanel resizes and lays itself out and returns to the caller what size the caller should be -- the caller is in charge of displaying the Continue or Stop or whatever buttons. The second call would be to run the VI while it is in the subpanel. But when I try to run the VI in the subpanel, I keep getting an error about the VI not being in a state compatible with the Run method. No idea how to fix this. If you know how to debug it, I'd love to see it.

[Tomi Maila]

QUOTE(Aristos Queue @ Mar 27 2007, 11:06 PM)

I'll look into the rest of your suggestions, but on this one --- I do want the subpanels to be running. There's a bug in Details Display Dialog.vi that I've been unable to overcome. I make two calls to the subpanel VI. The first call the subpanel resizes and lays itself out and returns to the caller what size the caller should be -- the caller is in charge of displaying the Continue or Stop or whatever buttons. The second call would be to run the VI while it is in the subpanel. But when I try to run the VI in the subpanel, I keep getting an error about the VI not being in a state compatible with the Run method. No idea how to fix this. If you know how to debug it, I'd love to see it.

Hi,

I think this two-time call is overkill from the error class developers point of view. I propose the following. Use the front panel size of the subpanel VI to size the subpanel and the subpanel containing VI. Use multiple transparent panes to divide the error dialog into multiple parts top: header, middle: subpanel and bottom: buttons. Lock the bottom pane to bottom and top pane to top. Make the subpanel on the dialog frontpanel to resize with the window. This way your subpanel always fills the whole middle pane as you resize the dialog window. The buttons also stay at their correct locations.

So when opeing the dialog window, resize the window to its correct size. Do not ask the subpanel for a size but use subpanel VI front panel size to determine the size of the actual dialog window. When you resize the dialog window, the subpanel automatically also resizes accordingly. This way the only task left for the subpanel is the actual error displaying and nothing else.

[Tomi Maila]

QUOTE(Tomi Maila @ Mar 29 2007, 12:43 PM)

So when opeing the dialog window, resize the window to its correct size. Do not ask the subpanel for a size but use subpanel VI front panel size to determine the size of the actual dialog window. When you resize the dialog window, the subpanel automatically also resizes accordingly. This way the only task left for the subpanel is the actual error displaying and nothing else.

Hi AQ. Here is my proposal how to remove functionality from the subpanel and place intelligence to the dialog window hosting the subpanel. It's not working perfectly but it's a proof of concept. The dialog window resizes to fit to subpanel and the subpanel is executing until the user presses ok or cancel. Real system would need much more intelligence in the dialog side but I think you can figure it out.

Tomi

[Aristos Queue]

QUOTE(Tomi Maila @ Mar 29 2007, 04:43 AM)

So when opeing the dialog window, resize the window to its correct size. Do not ask the subpanel for a size but use subpanel VI front panel size to determine the size of the actual dialog window. When you resize the dialog window, the subpanel automatically also resizes accordingly. This way the only task left for the subpanel is the actual error displaying and nothing else.

Except we want the subpanel size to drive the dialog window size, not the other way around. Even if the window were made resizeable and this were passed through to the subpanel -- adding a *lot* of work for the subpanel developer -- we'd still want the subpanel to define the minimum bounds. The window resize commands don't seem to work once the VI is hosted in the subpanel (I assume that's because there isn't actually a window to resize).

[Tomi Maila]

QUOTE(Aristos Queue @ Mar 30 2007, 02:50 AM)

Except we want the subpanel size to drive the dialog window size, not the other way around. Even if the window were made resizeable and this were passed through to the subpanel -- adding a *lot* of work for the subpanel developer -- we'd still want the subpanel to define the minimum bounds. The window resize commands don't seem to work once the VI is hosted in the subpanel (I assume that's because there isn't actually a window to resize).

Perhaps if you did take a look at the example code I provided you would notice that this is the way the example indeed works.

Tomi

[Q^Q]

cool