6 replies to this topic

[Jeffrey Habets]

Hi,

I'll illustrate my question with my use-case. While implementing a variant of the command pattern I want to have commands that are optionally undoable.
For this the command will have an Execute method that is a must-override and an Undo method that can optionally be overriden.



What I'm looking for is a way to check at runtime (from the parent) if the child on the wire has implemented the Undo method, without calling it ofcourse.
Just curious if this is possible.

I know my ways to work around this, e.g. have attribute Undoable in baseclass, or introduce a CommandUndoable class (which is a child of Command) to be inherited from by undoable commands.

[MikaelH]

Since you can find out the Child Class name in runtime and you know the VI it should override, you can always:
1) Try to open the VI Reference to the VI using a string: <ChildClass>.lvclass:Undo.vi, since it belongs to a class it will be in memory.
2) Open a reference to the class and get it's members and check if it's in the list.

...or am I missing something?
//Mikael

[Jeffrey Habets]

Seems the one who was missing something was me..

But no worries I've got a vacation coming up.. All should be well after that.

Thanks!

[MikaelH]

Have a nice holiday
I just got back from a long weekend of skiing.
It was awesome, and next week I'll go snokeling, that's life down under :-)

[Shaun Hayward]

Another option you could use (that doesnt need opening references etc) is to have the parent class VI return an error code (ie a "method not implemented" error) - that way, any override VIs will execute normally, but any classes that do not provide this functionality will error in a known way that you can catch and handle appropriately, etc.

[Jeffrey Habets]

Another option you could use (that doesnt need opening references etc) is to have the parent class VI return an error code (ie a "method not implemented" error) - that way, any override VIs will execute normally, but any classes that do not provide this functionality will error in a known way that you can catch and handle appropriately, etc.

That's more or less what I did to have an indication of forgotten-to-implement overrides before we had the must-override option for methods. But for the use-case I have here this is not an option, since I'd have to call the method. In my use-case I need to know if it exists without actually calling it.

The open/close ref does the trick here and for my use-case it's not to much overhead.

[MikaelH]

The open/close ref does the trick here and for my use-case it's not to much overhead.

Especially when you open a VI reference by name i.e. using the string instead of path