When would you use AllowPrivateAccess?

Development Programming & Scripting C++
,
1

Hi!

When would you use AllowPrivateAccess? Can you give me an example?

I know the theory about AllowPrivateAccess, but I can’t imagine a situation to use it.

Thanks!

2

the short answer is: AllowPrivateAccess should be used for any memeber that is marked as private:, but you still want to expose to the the editor for the blueprint or the outliner details window.
This includes if you only want UPROPERTY(VisibleAnywhere, BlueprintReadOnly) on a Private member you will still need AllowPrivateAccess.

  • for example if I need a pointer to an input action that has no applicable use except the controller class, or the character that is being possessed by that controller; then the pointer gets designated private, but because I must assign the pointer in the editor (to avoid hard path string references) I need to expose it, so the pointer is marked as AllowPrivateAccess
  • Another application for AllowPrivateAccess is if I have a purely internal state control variable that is only applicable to the object in question, but knowing that state would be important for troubleshooting/visualizing so I can mark the member UPROPERTY(VisibleAnywhere, BlueprintReadOnly, meta=(AllowPrivateAccess)) this way even a level designer can see that state member, and either use the information to figure out responsibility for the undesired program behavior (this application might be sidestepped by giving the object some kind of ReportToLog() that just dump state members, but these can be info spam for singular members)

The intent of AllowPrivateAccess according to the docs is it applies to things that will be Private based on currently protected, but this functionality was never fully implemented or is very shaky and leans to “for blueprints and outliner protected means public” there may be some confluence of inheritance/composition that will have “protected means that anything outside the inheritance chain treats the member as private” be meaningful to the editor

but you should also ask yourself “why you are marking this as private to begin with?” if you are doing so because you want to enforce a Setter that does nothing more then a raw assignment

private:
     int32 MySpecialValue;
public:
     void SetMySpecialValue( int32 inValue ) { MySpecialValue = inValue; }

this member should probably be marked public, and if you need to do follow up logic you can capture it in PostEditChangeProperties()

don’t hide you data too early, if it will only ever be set in the editor, and never touched again by any outside class then it should probably be private with EditDefaultsOnly and AllowPrivateAccess be careful with EditDefaultsOnly, and EditInstanceOnly as these can have other side effects.

2 Likes
3

E.g. when I use it: if you want your property to be private, but you still want the derived blueprint to be able to access it, you add use e.g.

UPROPERTY(BleuprintReadOnly, meta = (AllowPrivateAccess = "true"))

Without AllowPrivateAccess the compiler will throw an error saying something like “you can’t make a private property blueprint visible”. AllowPrivateAccess helps circumvent that.

IDK if it works for derived c++ classes though; never tried it.

1 Like