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.
Neither in parallel and nor in a predictable succession.
Quote from: Marsu42 on July 11, 2013, 05:31:17 PM
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).
Quote from: coutts on July 15, 2013, 10:54:15 PM
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.