Labview wants to save some changes in the Stop Core.vi, even though none was made

[Rafal_Kor]

This is definitely something i'm doing wrong as a complete novice at it, but every time i try to override the stop core.vi method in any of my nested actors, labview seems to think i've made some changes to the parent method in the actor framework. i obviously haven't, as i know better, but that's not what labview thinks. I have even gone to the lengths of setting a Read Only attribute on the entire Actor Framwork subfolder and its contents, just to make sure that nothing and nobody changes anything in the framework. what am i doing wrong?

[BillMe]

Are you using the run-time menu option to script a new "Stop Core.vi"? That is, right-clicking on your class and selecting "New VI for Override"? I've never had an issue using this method. And I can go into the block diagram and remove the call to the parent if needed without getting any "save" prompts.

[MKIT86]

Actually, the same happens for me. After overriding the stop core Labview asks me to save the changes "i have made" to the parent stop core vi.

Edit:

This is the description of the changes in Stop Core.vi: "Some attribute of the VI was changed, such as the breakpoint, data logging, or VI Properties options."

[Rafal_Kor]

I've been trying not to use any labview built-in aids for creating either actors or messages. I have on occasion used the "New VI for override" feature, but again seldom, and not in this case. Your reply however has brought up an interesting point, regarding the framework parent methods. You indicate that the call parent method in the child-override of Stop Core.iv is an elective, depending on what you want. I thought that in order for the framework to work correctly the call to parent always had to occur in any child override, both for root actor(s) and nested actor(s). Again i'm somewhat new to the framework, and I have a feeling this might be a topic for a new thread.

[BillMe]

The framework "built-in" aids are a tremendous time saver. I would highly recommend using them.

As far as overriding a method: There are times when you want to call the parent method from your override, e.g., Actor Core.vi but depending on what you're trying to accomplish it's not mandatory. For example, I override Stop Core.vi so I can shutdown hardware, then call the parent method so it can send Stop messages to any nested actors (needed functionality I don't want to recreate). However, for my override of Handle Error.vi I do not call the parent method because there is no functionality in the parent method I need.

[lt_kurki]

Does your project happen to have more than one execution systems where AF is used? For example, Windows (PC) and an RT target.

I've had no end of trouble during the past couple of days with Actor methods just "spontaneously" breaking - with the error message that they're no more included in the class, although the class browser shows otherwise. This happens when I handle overridden VIs (Actor Core etc.) both on the PC side and the RT side. Occasionally LabVIEW wants to save the base class methods in this case, although I never change them myself.

For some time I thought that my particular project must be corrupted somehow. But then I created a fresh project from the AF template, added a CompactRIO target, added an Actor there, overrode some methods and opened and closed (and saved) the same methods on different Actors on both PC and RT sides. Pretty soon the base class methods were broken.

The only robust way to fix the broken methods (that I've found so far at least) is to just overwrite the whole vi.lib/Actor Framework with a fresh copy.

Perhaps this is a well-known thing already, and I simply should keep the PC and RT parts of my AF based software in different projects altogether.

[I'm using LV 15.0.1f1, SP1, 32bit]

[Rafal_Kor]

No, there is only one execution system.

It's amazing however how we both have come up with a way to fix the problem. I basically do same you do. I always have a spare, fresh and untouched copy of vi.lib\Actor Framework somewhere on some memory stick, and I copy it in case the framework base methods become broken.

one other observation i'd like to share and that is that since I set the read only attribute on the entire Actor framework (folder and files) in vi.lib, I've not had any issues with unsaved changes in framework base methods. It's a bit of a brute-force method, but as they say .... "if a hammer is the only tool you have to solve your problems, then every problem looks like a nail..."

[lt_kurki]

I just noticed this other thread:

https://decibel.ni.com/content/thread/26650?tstart=0

From reading that and from my own experiences I'd say that if you only use a single target, saving the Actor.Stop Core.vi won't actually break anything. But if you do, it potentially will, and you need to use one of the workarounds until the deeper issue is fixed in a future version of LV.