I haven't actually looked at your code to see if this was a problem in your case, but the general rule-of-thumb is that a .h file should never create any data or code, only DEFINE data or functions that are actually implemented in .c/.cpp/etc files.
OK I think you were misunderstanding the purpose of those .h files. Tha project is thousands of lines long (not including the libraries) and so to keep things sane I have broken it up into a dozen "modules" (the code from your example I believe is from my messages.h module) The purpose of those modules is to collect common functions together for separate viewing. So if I need to work on some aspect of how the transmitter is controlled, I don't have to sift through a hundred functions trying to find the ones responsible for the transmitter. I just switch to the transmitter.h file in the IDE.
I'm used to this form of development with other languages similar to visual basic. And in those cases, you do indeed collect related functions into modules. For them, if you want to work on the keydown transmitter function, it's MUCH easier to find it - you just open the Transmitter module, and find the Keydown function, from a list that's sorted for you, alphabetically. IMHO arduino's IDE makes juggling a larger project a lot more difficult than it should. Without my "module" design, I'd be forced to use search to find the function, and would have sever "tunnel vision" with respect to what other transmitter functions were available.
I was actually a bit surprised to see the IDE seems to understand what I'm trying to do, and when I open the cleverfox.ino, it automatically loads up all my other modules in separate tabs. It's really slick that way. There are too many of them to all fit across the menu bar, so it develops a dropdown menu on the right for easy selection.
Maybe .h isn't required. I really haven't spent much time with that, I just see what I'm doing is working, and I go with it. If you look at my .ino file, you'll notice that all that's in there are some comments, and about a dozen #include, for the modules. Maybe those would be better named .cpp? MORE than once I've made a backup copy of an .ino file in its folder and found that when I tried to compile it, the IDE vaccuumed it up into the sketch during compile and gave me dupicate definition errors, so I haven't been too game to see what other "helpful behaviors" it is ready to spring on me. So if I find something that works, I tend to stick with it unless required otherwise. Unfortunately, I'm sure this will lead to some non-standard practices.