Fix NOTIFICATION_POSTINITIALIZE sent twice to native parent classes#1447
Conversation
030f3e6 to
06373ce
Compare
|
We should be able to test for this with a flag and a notification check, just to validate it |
There are already automated tests for ensuring that I don't think there's a way for us to test that the bug this PR is fixing is fixed, though, since that all happens on the Godot side. So, I don't think this PR needs to add any more tests. |
|
Meant like adding something in the existing check so: if (p_what == NOTIFICATION_POSTINITIALIZE) {
if (post_initialized) {
// Some error.
}
post_initialized = true;
}Since the issue was sending it twice yes? Unless it's only sent to the parent twice |
It's only sent to the native parent class twice. On the godot-cpp side, we only see it once. |
|
Nice catch @dsnopek ! |
vnen
left a comment
There was a problem hiding this comment.
Approved in the GDExtension meeting.
|
Cherry-picked for 4.2 in PR #1465 |
|
Cherry-picked for 4.1 in PR #1466 |
As brought up on PR godotengine/godot#91018, we're currently sending
NOTIFICATION_POSTINITIALIZEto the native parent class twice.This issue was introduced by PR #1269, which was attempting to get the
NOTIFICATION_POSTINITIALIZEto arrive to the extension class by sending it inWrapped::_postinitialize(), but the way it's doing it will send the notification through the native parent class again.This PR makes it so that
Wrapped::_postinitialize()will only sendNOTIFICATION_POSTINITIALIZEthrough the class hierarchy that exists purely on the GDExtension side. BecauseNOTIFICATION_POSTINITIALIZEis run on the parent class first, this effectively just picks up where the previous notification that went through the native parent class heirarchy stopped.PR godotengine/godot#91018 and godotengine/godot#91019 attempt to more comprehensively fix
NOTIFICATION_POSTINITIALIZE, but those require changing the GDExtension interface (which is Godot 4.4 material at this point), and we need a fix to this issue that can be used with Godot 4.1, 4.2 and 4.3.