Fix Script -> Script Class not in CreateDialog #23060
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Bump. As far as I'm aware, there shouldn't be any issues with this PR. It's all set for merge. |
|
Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #21461. (Previously would have completed it, had it not been changed)
(Edit: Looks like that PR deals specifically with a cyclic reference error showing up. My bad. This PR is about making sure that script classes which extend a non-class script still show up in the CreateDialog properly.)
This is more of a bandaid until #22181 can be merged for 3.2. The ClassType object is a lot better for this since it can carry the potential type name AND potential resource path within a single object that knows how to fetch the "base" typename regardless of what it's actually looking at.
The below implementation will allow script classes deriving a script to be interpreted as extensions of that script's engine type, but it WON'T support going from a script class to a script to another script class and allowing the 2nd script class to register that it is extending the first one. That sort of complexity is beyond the scope of this PR's solution.