GGShinobi wrote:.Notify
seems to have no effect if .DynamicNotify
is true. (I thought setting it to false would prevent the oxpcNotifyOnChange-function to get called on start, so that, for example, at first the string "1st key of key combo." is used. But instead, the string has already been substituted by the value from oxpcNotifyOnChange even the first time I enter OXPConfig.)
I'm not sure I understand (and sorry for the longer text).
Both flags are working independent and even if both flags are true
.oxpcNotifyOnChange
won't be called at all when
OXPConfig runs its own start routines as long as no settings were stored before.
OXPConfig also won't call it if you're just browsing through the settings. If settings were stored before we have a different situation and
OXPConfig will call it if the
.Notify
flag is true when it runs its own start routines. The passed argument will always be 7 (1-boolean + 2-short int + 4-24bit int) to indicate the full range for stored values.
After the startUp procedure:
The next situation is if a user enters the
OXPConfig screens and changes settings.
OXPConfig uses the
.DynamicNotify
flag and passes 1, 2 or 4 based on the type of the changed setting if the flag is true. And last but not least if the user has finished his changes and leaves the screens
OXPConfig uses the
.Notify
flag and passes the sum of changed settings, so it can be 1...7 if the flag is true.
And to complete it. If stored values are there
OXPConfig will apply the settings regardless of the
.Notify
flag.
What (probably) happens in your script is another thing. As you are calling
this.$setupKeyArrays()
in you scripts
.startUp
the loading order will become important. Specially for these cases
OXPConfig has the
.EarlyCall
,
.EarlySet
flags. But calling other OXPs
.startUp
from within
OXPConfig has a drawback - it raises the time the function runs and we may hit the timelimiter some day. A approach for your script could be to get rid of the duplicated
this.$setupKeyArrays
function and call the remaining
this.oxpcNotifyOnChange()
a bit later (e.g. via the
.missionScreenOpportunity
handler) or use a init property which gets checked on
guiScreenChanged
. This way you'd still get your configuration in all cases and don't have to worry about things like loading order or if the user has
OXPConfig installed or not.
Edit: Oh, and
.EarlySet
is probably not a bad idea too.
OXPConfig will apply stored settings in its first cycle then.
GGShinobi wrote:this.oxpcSettings.Info.InfoS
didn't use the fresh values from the variables. No matter how I changed key1-key4, the string shown is always the same (always: "CHANGED: ...")
Yep. InfoB, InfoS and InfoE are not part of the dynamic stuff as their meaning was always to describe the settings and not their values. Shouldn't be hard to change it to give OXPs some more room.