IRC Log Viewer » #firebreath » 2013-08-16

IRC Nick Time (GMT-7) Message
Champika 00:08 Hi All
just wanted to ask for some guidance on firebreath
any info on this is greatly appreciated :)
dougma 01:08 NSWindow has a screen property
FB::PluginWindowMacCG has a getWindowRef method returns a void* but it is an NSWindow
Champika 01:08 will check on this. thanks a lot :)
taxilian 09:08 dougma: that was not correct; you cannot get a NSWindow in a NPAPI plugin
the PluginWindowMacCG type is a CGContextRef, but it's only available within the CoreGraphicsDraw event
Guest52177 16:08 Hi.I have an windows installer issue, I believe... I'm using external DLLs in my plugin. I added the DLLs to the Wix file as described in the WiX installer help wiki page. The files install. Dependencies load properly, but the plugin isnt loaded in the my browser's plugin list.
I ran firebreath with --debug-plugin-loading to get some info, the plugin doesnt appear to even try to load my plugin.
before adding the DLLs to the installer, my plugin was functioning and in production.
taxilian 17:08 Guest32177 look at the np<plugin name>.wxs file
most likely it's missing the needed registry entries
and most likely it's because the DLLs needed aren't in the output bin directory when heat tries to run as part of the build process
you'll likely need to use cmake to add a post-build command to copy the needed .dlls into the correct directory
Guest52177 17:08 the DLLs do make it to the final install location
I install system wide not per user if that changes any thing
taxilian 17:08 neither of those statements has any bearing on the problem
Guest52177 17:08 oh ok.
taxilian 17:08 the problem is that when the installer is *created*, not when it is run, the .dll files aren't in the same directory as the dll
because of that heat is unable to load the dll
and thus it fails
most likely, anyway
Guest52177 17:08 sounds promising
taxilian 17:08 could be something else, but that's by far the most common cause of an issue like yourse
Guest52177 17:08 i get a heat warning about DLL not being self regestering as well
taxilian 17:08 yep
that's the issue, then
and if you try to run regsvr32 on it it will fail
Guest52177 17:08 so, where should the DLLs be?
taxilian 17:08 get it so regsvr32 doesn't fail when run right after building and heat will work
in the same dir as the output DLL for the plugin
Guest52177 17:08 so /bin/<plugninname>debug
Ill try manually putting them there to test for now, before creating a cmake command... shoudl that work?
taxilian 17:08 might
probably will
Guest52177 17:08 ok, ill go down that path.
thanks a lot!
its Richard right?
taxilian 17:08 yes
akelani 17:08 taxilian: did some searching on google. This seems to be the same issue that I'm having:
taxilian 17:08 could be
I don't really know much about opengl per se
akelani 17:08 ah i see
Guest52177 17:08