IRC Log Viewer » #firebreath » 2015-10-19

IRC Nick Time (GMT-7) Message
Enkindler_ 08:10 I'm having an issue with the Messaging host now.... I made some modifications to the plugin to do some testing, and when I built the project again, reloading the page causes a FireWyrmNativeMessageHost.exe has stopped working error
I restored the changes and rebuild the project but it doesn't fix the issue at all..
I even ran the prepcmd again, just to see if a was missing something and re-registered the dll (after unregistering it) but the issue remains!... Any ideas?
taxilian 09:10 'morning
enkindler when is hte last time you pulled from FireBreath? there was a crash that sounds a lot like that one that was fixexc
fixed*
Enkindler 10:10 A while ago, when I started testing firebreath in the first place...
Should i update?
taxilian 10:10 yes
Enkindler 10:10 Alright then...
I managed to get it working using an exe that i built for another plugin... so maybe I unknowingly modified the source?... All I did as far as I'm concerned was uncomment the debug part...
Once updated, should I prep again or just build?
Once updated, should I prep again or just build?
taxilian 10:10 prepping never hurts, and build will rerun prep if it needs to
prepping never hurts, and build will rerun prep if it needs to
so either way, really =] depends on what has changed
so either way, really =] depends on what has changed
I don't think you'll need to prep, but I don't remember for sure
Enkindler 10:10 Alright... Yea I was wondering... when I modify sothe source code, I'm actually modify the source that the prep scripts... prep?
Alright... Yea I was wondering... when I modify sothe source code, I'm actually modify the source that the prep scripts... prep?
taxilian 10:10 all the prep script is is a shortcut for running cmake with the parameters you need
it looks at the CMakeLists.txt file and creates a project for it
it looks at the CMakeLists.txt file and creates a project for it
it also "configures" several files for you based on settings (mostly in PluginConfig.cmake)
it also "configures" several files for you based on settings (mostly in PluginConfig.cmake)
so the prep script is only needed if something about the project config changes -- files added or removed, settings changed, etc
anything you'd normally change in project or solution properties in VS will be done w/ Cmake instead
Enkindler 10:10 like adding new header files and sources yes?
taxilian 10:10 yes
Enkindler 10:10 alright.... Thanks...
Do you know a way to make IntelliSense... Work?..
Do you know a way to make IntelliSense... Work?..
because It always freezes on "Operation in Progress" and does nothing...
taxilian 10:10 it doesn't seem to like something about the way the project is build
unfortunately I haven't found a solution :-(
Enkindler 10:10 Oh... But it could be something of the project then?...
Enkindler 10:10 Thought it was intellisense that sucked
Is there a way to know if the plugin that's being loaded is the one I just built?
Is there a way to know if the plugin that's being loaded is the one I just built?
taxilian 10:10 well, it is intellisense that sucks
but I'm not sure if it sucks enough that any project which uses boost has this issue or if the way cmake builds the project may sidestep some optimization that they sometimes do to try to make it suck less
as to the last question... do you have more than one version of the plugin installed somewhere? there are probably some things you could do, though nothing super simple comes to mind
you could delete the new dll and see if it still thinks it loaded =]
Enkindler 13:10 That worked... But turns out i was kinda registering the wrong dll too.... My bad!...
taxilian 13:10 =]
Enkindler 14:10 Why does the callbackFn var has a "_fwcb_" prefix? at var callbackFn = "_fwcb_" + Math.floor(Math.random() * 100000000);
taxilian 14:10 FireWyrmCallback
that's in my code that I sent you?
it is just basic namespacing
doesn't mean anything important, but that's why I named it that
Enkindler 14:10 Alright... And the math stuff it's bassically so we use a random name yes?
taxilian 14:10 yes
so that multiple calls don't conflict
yes
Enkindler 14:10 Alright....
Alright....
What does the setHelper actually do? underneath I mean?
taxilian 14:10 just caches the object
just caches the object
the object can be used multiple times
the object can be used multiple times
Enkindler 14:10 the object is the extension then?
the object is the extension then?
taxilian 14:10 it's the object that the extension passed into the callback
it's the primary interface for the extension, yes
Enkindler 14:10 How does it know that what It should be looking for is that?... all I really see in the code is the var helper = inp.wyrmhole; part... And I dont really see where that inp is coming from....
taxilian 14:10 inp came from the callback
you postMessage to the extension to tell it you need the wyrmhole and it injects some code into the page, then passes a reference to the object into the callback
line 30 of that gist
line 30 of that gist
the contract is that when you postMessage it will call the specified callback with that object
Enkindler 14:10 I see... yes, I kinda missed the postMessage part...
taxilian 14:10 oh, heh
yeah, tha'ts the most important part there
that's how you get access to the extension
'twon't nothing work without that
everything else in this file centers around that
Enkindler 14:10 Yes yes.. I'm kinda trying to understan what everything does by itself so I can start to write something about the examples...
taxilian 14:10 90% of that file is just wrapper; the only steps that matter are:
1) window.postMessage({firebreath: CompanyName, callback: someFunction)
2) in the function referenced in (1) get the wyrmhole, then call create()
2) in the function referenced in (1) get the wyrmhole, then call create()
3) if you passed a mimetype in (2), instantiate FWJS with the wh; this can be used to instantiate the plguin
3) if you passed a mimetype in (2), instantiate FWJS with the wh; this can be used to instantiate the plguin
Enkindler 14:10 the create in (2) returns another wh?
taxilian 14:10 it returns an actual wh instance
it returns an actual wh instance
so I should have been more specific; 1) returns the wyrmhole factory
so I should have been more specific; 1) returns the wyrmhole factory
Enkindler 14:10 alright... and the create in 2, using a mimetype binds the mimetype to that wyrmhole?
taxilian 14:10 if you provide a mimetype it will load a plugin with that mimetype
and at that point the wyrmhole is bound to that plugin DLL
note that is a plugin, not a plugin instance
note that is a plugin, not a plugin instance
i.e. it's a plugin dll, not an instance of the plugin residing in the DLL
and technically that DLL could contain multiple plugins and you could instantiate any of them from the wyrmhole
Enkindler 14:10 which is the reason for a second pluginFactory.create yes?
bassicaly the FWJS object itself?
taxilian 14:10 yes
that's what instantiates the actual plugin instance
that's what instantiates the actual plugin instance
Enkindler 14:10 alright
Thanks...
I think i get it now... kinda
Another thing... is this the right way to list the installed plugins? http://pastebin.com/Eyw3cgcu
Another thing... is this the right way to list the installed plugins? http://pastebin.com/Eyw3cgcu
taxilian 14:10 is pluginFactory what is returned in the callback?
Enkindler 14:10 ?
which callback=
taxilian 14:10 let me rephrase: what is pluginFactory?
Enkindler 15:10 http://pastebin.com/ZDsvufMi
http://pastebin.com/ZDsvufMi
that should work better
that should work better
pluginFactory is where the FWJS gets instanciated...
pluginFactory is where the FWJS gets instanciated...
taxilian 15:10 you have to instantiate a wyrmhole to list plugins
wait...
wait...
I think most of this makes sense
but not listPlugins
listPlugins is not called on FWJS
it's called on a wyrmhole
it's called on a wyrmhole
generally if you're listing plugins you aren't sure which you're going to instantiate yet
so you'd do helper.create() to get an unattached wyrmhole
then call listPlugins on that wyrmhole
I think it's possible to load the plugin on an unattached wyrmhole as well, though I'm not doing it in my code
it's probably more efficient
Enkindler 15:10 shouldn't I already know which plugin I'm going to instantiate, and list it to make sure it is installed?, and then instatiate it or throw an error?
shouldn't I already know which plugin I'm going to instantiate, and list it to make sure it is installed?, and then instatiate it or throw an error?
and list the pllugins to make sure the one I want is installed*
taxilian 15:10 probably
so most of the time you don't really need listPlugins
but if you did, you wouldn't instantiate the plugin first =]
but if you did, you wouldn't instantiate the plugin first =]
Enkindler 15:10 true true... I did that as a test... I was actually asking because I saw it a bit different in your example...
taxilian 15:10 my example does the same thing; it calls wyrmhole.create().then(function(wh) { wh.listPlugins(); })
or similar