While adding some code I noticed one thing that doesn't make wading through the code easier: the PROP_HANDLER statements are all over the place and just happen to be near the feature they were originally intended for, not matter what happened in the meantime.
I know refactoring/relocating shared code generally causes a lot of confusion and merging problems, but for my 2 cents if you do anything like that sooner or later, imho concentrating all PROP_HANDLERS in one location would be a good idea, even if there are less static and more extern vars. The features would then integrate their hooks into the handlers, and this would make merging easier afterwards.
One example I just stumbled across was the PROP_HANDLER for PROP_AF_MODE that was taken by some obscure 5d3 feature, with just one line of code - and I didn't even realize that the whole handler was in a #ifdef and why the handler didn't respond :-\
The prop handlers are just hooks, you can define them wherever you need them (they should be unique in a single source file though). Maybe the restriction of uniqueness can be removed?
Quote from: a1ex on April 09, 2013, 01:47:58 PM
The prop handlers are just hooks, you can define them wherever you need them (they should be unique in a single source file though). Maybe the restriction of uniqueness can be removed?
Doh, I didn't know that and thought I have to hook my code in the existing handler, wherever that may be. And yes, removing the uniqueness restriction if possible would be good because it would allow the code to be more independent and prevent conflicts when merging, there are bound to be multiple PROP_HANDLERs for af stuff and such say in shoot.c