mike5 Posted June 4, 2010 Report Share Posted June 4, 2010 (edited) I have created a new class (B) which in inherits from class A. "A" has one "dynamic dispatch" member requiring over-ride, which I have already overridden. But still, the library gives me errors: - Project Library Errors This class does not implement at least one dynamic dispatch VI.... The parent of this LabView class is private and is not accessible from this class. As far as I can determine, none of these statements are true. There are no VIs with * sign next to their name. Please help me fix my project. P.S. I have in the near past re-factored the library and removed some descendants of class A and the class name was different before. I suspect another case of internal inconsistency arising from left-over data. Is there a way to fix/clean-up my project? Mike Edited June 4, 2010 by mike5 Quote Link to comment
mike5 Posted June 4, 2010 Author Report Share Posted June 4, 2010 Yes, class "A" is somehow broken, but I cannot determine how. I'd really like some recipe for fixing these type of errors that isn't "create a new class and re-implement everything from the old class". If only there was a site where we could vent our frustration over the quality of this fine piece of software... Oh, wait! Quote Link to comment
Francois Normandin Posted June 4, 2010 Report Share Posted June 4, 2010 - Project Library Errors This class does not implement at least one dynamic dispatch VI.... The parent of this LabView class is private and is not accessible from this class. Hello Mike, A descendant class cannot call a private VI from its parent class. If you've overridden the private VI, I guess the error is that you can't call the Parent implementation with "Call Parent Method" primitive in the Child. If you have to call its parent implementation as part of the child's code, you should probably make both of them "Protected" instead of Private. Quote Link to comment
mike5 Posted June 4, 2010 Author Report Share Posted June 4, 2010 Hello Mike, A descendant class cannot call a private VI from its parent class. If you've overridden the private VI, I guess the error is that you can't call the Parent implementation with "Call Parent Method" primitive in the Child. If you have to call its parent implementation as part of the child's code, you should probably make both of them "Protected" instead of Private. Thanks, I know that and both methods were protected. I created a new class "A" and copied everything over hoping it will work out. It did (this time), and without LV crashing on me, too. Best regards, Mike Quote Link to comment
Francois Normandin Posted June 4, 2010 Report Share Posted June 4, 2010 Thanks, I know that and both methods were protected. I created a new class "A" and copied everything over hoping it will work out. It did (this time), and without LV crashing on me, too. Best regards, Mike I agree those error messages are far from optimal to say the least. I've stuck my head a few times too. Hopefully we'll see improvement in error documentation with LV2010... Quote Link to comment
mike5 Posted June 4, 2010 Author Report Share Posted June 4, 2010 I agree those error messages are far from optimal to say the least. I've stuck my head a few times too. Hopefully we'll see improvement in error documentation with LV2010... Thanks, you could also work on better class internal consistency control. I know I've had LV crash on me a couple of times simply as a result of renaming a member VI, removing a data from a control or VI from a class or renaming a VI or a class. And the crashes started occurring AFTER I fixed all the reported errors that were the result of my action... Br, Mike Quote Link to comment
Shaun Hayward Posted June 4, 2010 Report Share Posted June 4, 2010 I came across something once - basically, if you change a parent class's VI's terminals from dynamic dispatch to non-dynamic dispatch (I used the right-click-replace) then that VI will no longer be overridden-able... however, if you had previously marked that VI as "Must be overridden" then you will find out that the "must overide" flag does not get reset. The end result is a VI that simultaneously must be overridden and cannot be overridden = broken class. To fix it, replace the non dynamic dispatch with dynamic dispatch terminals, remove the "must overide" flag and start again. Quote Link to comment
mike5 Posted June 7, 2010 Author Report Share Posted June 7, 2010 Thanks for that explanation - it was not the case for me, but I'll watch out for it in the future... Br, Mike Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.