Changing a Property from Protected to Private in C++ does not lead to compile errors in Blueprints

I am using UE 4.5.0 and had Property exposed to Blueprints by making it “protected” and “BlueprintReadWrite” in C++. That Property was then used in a Blueprint. I changed the Property to “private” and removed “BlueprintReadWrite”. However the Blueprint using the Property would not throw an error message when compiled again, although it should not be allowed to use that Property anymore.

As far as i know the private and protected don’t affect variables that are exposed in the editor, you affect them by using the Visible(DefaultsOnly/Anywhere) or Edit(DefaultsOnly/Anywhere) macros along with the Blueprint(ReadWrite / ReadOnly) on the UPROPERTY macro.

No, the Unreal Header Tool will fail if it encounters a UPROPERTY that is exposed to Blueprints but put into the private section in C++.

That is why I changed it from “protected: UPROPERTY( BlueprintReadWrite )” to “private: UPROPERTY()”.

Try removing the UPROPERTY altogether if you don’t want to use that variable in the editor. If that’s not what you want, try making a new blueprint from the C++ class where the property is private and it should not appear.

:slight_smile: Maybe I did not make this completely clear but the problem is that the property was already used in the Blueprint and the Editor / Blueprint Compiler did not throw an error although after changing the access specifier it is not allowed to use the property within a Blueprint anymore. So I should not be able to start the game anymore and instead get an error message telling me to fix the problem.

What works fine is that the Editor does not allow me to place new nodes using that property, just a I would expect.

However the above mentioned behavior is an Editor / Blueprint Compiler bug which I was reporting so it can be fixed.

P.S. I cannot remove the UPROPERTY since the data is being serialized and therefore the metadata needs to be known to UE.

If it’s a bug put [BUG] or something like that on the title so Epic can look at it and we don’t think it’s a question :stuck_out_tongue:

:slight_smile: I put it in the category “Bug Reports” and tagged it as “bug report”.

But starting the title with [BUG] may be another way to mark it - next time…

Sorry didn’t noticed that :slight_smile:

Hi ,

Sorry for the delay in getting back to you on this issue. I did some testing and saw the behavior that you described. This does not seem like it is intended. I have submitted a report about this issue (UE-4922) for further investigation.


PS. If you see something in the Engine that does not seem right, posting in the Bug Reports section is generally enough to bring it to our attention. Using a “bug report” tag as well doesn’t hurt, but it isn’t necessary to use any additional notation in the title of the post, such as “[bug]”.