Alrighty, here’s an excerpt from my Log
LogBlueprintUserMessages: F::The Found Key
LogTemp: ReMapKey, successful? ::R
LogBlueprintUserMessages: D::myKeyValue
Pretty much, the function(OnKeyDown) that prints the third log message is called before the functions that print logs messages 1 and 2.
So even though the functions that print the first two log messages are executed after the execution of OnKeyDown, they still print and resolve before the OnKeyDown which was called first. *Note, OnKeyDown is called in a different context outside of this widget blueprint, but it still affects the value of a variable that initiates the sequence that calls the other nodes. See picture.
Print String TheFoundKey is inbetween C++ functions FindKey, and ReMapKey.
the UE_LOG(…) that resolves to ReMapKey, successful? :: %S is inside the function ReMapKey.
OnKeyDown changes the value of a string variable in this blueprint widget, that allows the Branch at the very beginning of the script to execute the sequence that finds the previous binding, removes, then adds a new binding.
OnKeyDown is overridden to do two things. Set the value of a string, and set the value of an FKey variable.
Even though setting the value of the FKey variable happens before the setting of the String variable in the node sequence. In the context of my widget blueprint, the string variable’s value changes and tells the Branch to proceed to call the other nodes. !But the value of last_key_FKey is still set to the default and does not take the value that it was set to in the context of the OnKeyDown function. In Fact, it does not take on this value until after the nodes resolve in the widget BP.
So is this a bug or a feature?