LPCTSTR error when using ofxOsc with ofxDSHapVideoPlayer

I’ve never had this problem using ofxOsc with other projects. And ofxDSHapVideoPlayer hasn’t thrown this error until now. But something about having them both in the same project throws this error:

Severity Code Description Project File Line Suppression State
Error C2664 ‘CVideoTransformFilter::CVideoTransformFilter(LPCTSTR,LPUNKNOWN,const IID &)’: cannot convert argument 1 from ‘const wchar_t [28]’ to ‘LPCTSTR’ example C:\Users\selli\openFrameworks\addons\ofxDSHapVideoPlayer\src\DSUncompressedSampleGrabber.cpp 20

which is weird, because it looks like the argument being given there is indeed in the LPCTSTR format (prefixed with an L). I’m able to replicate this error easily by just adding ofxOsc to ofxDSHapVideoPlayer’s example project in the Project Generator. I’m on Windows 10 using Visual Studio 2019. Any ideas, @mantissa ?

I’d just given up on doing audio in oF since I have a performance tomorrow and was going to use OSC+PD, but now this…

I am not very familiar with windows.
but might be that a typedef or #define is being redifined and breaking it?
I guess that each addon works when used separated form the other but fails when you use both on the same project?
It might be important the order in which you include each addon. try swaping it.

This error still happens even if I don’t #include either- just adding both addons in the ProjectGenerator and updating it leads to this issue. @mantissa please help!

OK, fixed this by changing

CVideoTransformFilter(FILTERNAME, (IUnknown*)pOuter, CLSID_SampleGrabber)

to

CVideoTransformFilter((LPCTSTR)FILTERNAME, (IUnknown*)pOuter, CLSID_SampleGrabber)

Not sure why having osxOsc in the project causes this, but happy to find a fix.

Issues like this usually occur when the compiler gets stricter. It used to be that you could pass in whatever type as a pointer and it would just “pass through” but stricter warnings which turn to errors now try to check for explicit type make make sure what the function it’s getting matches what it expects. When the addon was written, it’s likely the compiler was more permissive with this but now it looks like VS is less permissive… which is helpful in finding areas for possible bugs.