The reason I recommend an error is because the code will error out later without the .tlh (where it is requested via attributes or absence of).  The errors later will be a direct result of the failure of #import to function properly.<br>
<br>If we try to auto-include, where would we look for the files?  Apparently it will be given the same timestamp as the type library itself, as one way to verify the files are correctly matched, but you'll have to replicate the type lib search pattern (which can be progid-based and other odd lookup systems that will hit the registry).  Could be ugly.<br>
<br>-<br>Jay Blanchard<br><br><div class="gmail_quote">On Thu, Mar 15, 2012 at 12:07 AM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Mar 14, 2012 at 10:52 PM, J B <<a href="mailto:jayblanchard.cpp@gmail.com">jayblanchard.cpp@gmail.com</a>> wrote:<br>
> MSVC typically throws the generated .tlh (type library header) and .tli<br>
> (wrapper implementation) into the solution's defined intermediate<br>
> directory.  They aren't part of the source tree unless someone explicitly<br>
> makes them part of the source tree.<br>
><br>
> It might make sense to error on #import with information to generate the<br>
> files with MSVC and make them permanent, and switch to #includes.<br>
><br>
> I believe the attributes can be ignored unless you're going to go forward<br>
> with this auto-determined include plan.  If you do that, you'll need to pay<br>
> attention to the attributes implementation_only and no_implementation, as<br>
> they control whether there is a .tlh or .tli<br>
<br>
</div>More and more I'm liking the original idea of warning the user that<br>
#import will not work for them and not including the binary file.<br>
However, I think I do still need to parse the attribute stuff (to<br>
ignore) for no other reason than so that the parser doesn't barf on<br>
the rest of the file.<br>
<br>
We can always revisit at a later date if we decide we want to try to<br>
be more constructive or creative.<br>
<br>
Any objections?<br>
<span class="HOEnZb"><font color="#888888"><br>
~Aaron<br>
</font></span></blockquote></div><br>