[ANSWERED] Are PROP_HANDLER execued in parallel or in a predictable succession?

[Marsu42]

Afaik it's advised to just add PROP_HANDLERS in modules when needed - but can I predict in which order they are executed, for example the core PROP_HANDLERS before the modules?

In my current case I'd like to add a PROP_HANDLER(PROP_ROLLING_PITCHING_LEVEL) to auto-switch the af points from portrait to landscape and vice versa by reading the "struct rolling_pitching level_data" that is initialized in the core PROP_HANDLER.

[a1ex]

Neither in parallel and nor in a predictable succession.

[coutts]

Afaik it's advised to just add PROP_HANDLERS in modules when needed - but can I predict in which order they are executed, for example the core PROP_HANDLERS before the modules?

In my current case I'd like to add a PROP_HANDLER(PROP_ROLLING_PITCHING_LEVEL) to auto-switch the af points from portrait to landscape and vice versa by reading the "struct rolling_pitching level_data" that is initialized in the core PROP_HANDLER.

Think of a prop handler as inert until its property changes, then it fires (runs).

Sounds like you just need a simple if statement in that prop handler, so when pitching level changes, check if it's over some threshold to detect moved to vertical/horizontal, and if it's over that threshold, call your function to switch AF points and update some status variable so you know the current state (vertical or horizontal).

This sounds like a feature already implemented by Canon in the 6D (and 5d3 probably too).

[Marsu42]

This sounds like a feature already implemented by Canon in the 6D (and 5d3 probably too).

Yes, exactly, I'd like to backport it to my 60d and the other camera bodies - with the tiny af spread of the 5d2/6d the functions is a bit of a joke, but with the larger 9/19pt af on the crop cameras auto-switching the af point should be quite useful.