IRC Log Viewer » #firebreath » 2012-01-30

IRC Nick Time (GMT-7) Message
kun 00:01 someone available?^^
dougma 00:01 .ask
FireBreathBot 00:01 If you need help, just ask your question and wait for people to come back.
dougma 00:01 oh maybe you did earlier and i missed it.
what's your question?
kun 00:01 I want to create an object of my class AccountAPI
dougma 00:01 that could be done.
kun 00:01 and when I do boost::make_shared<AccountAPI>(m_host) I got an error
dougma 00:01 what error?
kun 00:01 undefined reference to `AccountAPI::AccountAPI(boost::shared_ptr<FB::BrowserHost> const&)
dougma 01:01 did you define the AccountAPI class?
kun 01:01 yes. I included the class
dougma 01:01 well... looks like you didn't define it correctly then.
kun 01:01 and did FB_FORWARD_PTR(AccountAPI);
dougma 01:01 FB_FORWARD_PTR is used instead of #include... but anyway.
so you should be able to omit that if you've the #include line
kun 01:01 yeah...
Don't recognize the fault...
dougma 01:01 the compiler is saying you don't have the method AccountAPI(boost::shared_ptr<FB::BrowserHost> const&)
method = constructor
kun 01:01 yes...It seems that the compiler doesn't find the constructor
dougma 01:01 doesn't find it.
oh well.
you could pastebin your AccountAPI.h
kun 01:01 class AccountAPI : public FB::JSAPIAuto { public: AccountAPI(const FB::BrowserHostPtr& host); virtual ~AccountAPI(); int getUid(); void setUid(int uid); private: FB::BrowserHostPtr m_host; int mUid; };
dougma 01:01 looks fine.
kun 01:01 yes it seems so^^
and the cpp implements the constructor of course too
dougma 01:01 and the .cpp where you do the boost::make_shared call is including AccountAPI.h ?
kun 01:01 jap
dougma 01:01 well... i can't do more from here. :)
kun 01:01 k thanks^^ do you know why i can't login the forum?
error: 'ascii' codec can't encode character u'\xdf' in position 3: ordinal not in range(128)
dougma 01:01 no idea... i never look at the forums. try the google group?
kun 01:01 ok
kun 01:01 when I want to add a new class to the project...do I have to add the .cpp in a makefile or somewhere else?
Now I simpy add it to the project directory
simply
ch 02:01 kun: if you put it with the other .cpp files, just rerun the prep script and it will pick it up
kun 02:01 allright thanks
and if I create a new JSAPI object with: boost::make_shared<AccountAPI>(m_host);
Is it possible to call the methods of the class AccountAPI ?
dtecta 07:01 I have a problem with loading DLLs from a plugin under Firefox and Safari. IExplorer and Chrome are fine. I use SetCurrentDirectory to set the current directory to the install path of the DLLs and then use LoadLibrary to load the DLLs. Under firefox the DLLs cannot be found. I checked with Procmon to see if indeed the DLLs in the install path are the issue and not some dependent DLL,
Does anyone here have an idea why Firefox and Safari behave differently from IExplorer and Chrome?
dtecta 07:01 Aww, I should have used SetDllDirectory. Sorry for the interuption...
taxilian 08:01 FireBreathBot: tell jshanab_wcw One of my goals for FireBreath 2.0 is to abstract JSAPI out into it's own project so that it could easily be integrated in with other frameworks; for example, I'd like to make an adapter for node.js
FireBreathBot 08:01 taxilian: I'll pass that on when jshanab_wcw is around.
taxilian 08:01 FireBreathBot: tell dtecta never call SetCurrentDirectory from within a plugin; you don't control the process, you don't own it, you shouldn't be messing with the cwd (and you certainly can't expect that if you do it'll always work correctly). use SetDllDirectory instead
FireBreathBot 08:01 taxilian: I'll pass that on when dtecta is around.
taxilian 08:01 FireBreathBot: oh, you found that; nevermind :-P
hara 08:01 hi,I have a problem invoking the JS method createElement in IE
this is what i do:
FB::DOM::DocumentPtr doc = m_host->getDOMDocument();
FB::JSObjectPtr new_element = doc->callMethod<FB::JSObjectPtr>("createElement", FB::variant_list_of("script"));
new_element is always null
in IE
while in FF the same code works
following the methods called, seems that the problem is in IDispatchAPI.cpp (line 475)
hr = dispatchEx->InvokeEx(dispId, LOCALE_USER_DEFAULT,DISPATCH_METHOD, &params, &result, &exceptionInfo, NULL);
result is a null variant
what i'm doing wrong?
what am i doing wrong?
taxilian 08:01 hara: calling DOM js methods like that some things just won't work on IE
so there are a couple of options; you could figure out what the "correct" way to do it with COM/IE is and then add an abstraction to the DOM and AXDOM objects to make it work
or you could use evalutateJavascript to do what you need
hara 10:01 @taxilian: sorry..while i was trying evaluateJavaScript Win crashed :)
foi solved the problem using evaluateJavaScript
thanks a lot
taxilian 10:01 yw
dreid 12:01 It appears that on windows jsobjectptr->HasProperty("unknown_property") will always return true?
ch 12:01 IIRC taxilian said that HasProperty might always give true in IE/ActiveX context
dreid 12:01 Sad.
taxilian 12:01 dreid: yeah, IE doesn't handle HasProperty well
better to use GetProperty and check if it's undefined
dreid 12:01 taxilian: An example of what that looks like?
taxilian 12:01 if (someObject->GetProperty("something").empty()) { … }
might need to wrap it in a try .. catch to be certain
.empty() returns true if the variant is an undefined, .isNull returns true if it === null
dreid 13:01 Hrmmm… that's always false.
taxilian 13:01 well, what does it return, then?
dreid 13:01 It appears to be consistently returning FBNull when the property is undefined, so I guess is_null is the answer.
taxilian 13:01 hmm; weird. You could check for either
my guess is that NPAPI will return undefined
and IE is returning NULL
which may actually be a bug in FireBreath...
!findfile comutils
!findfile comvariantutils
huh… the bot is sleeping or something
set a breakpoint at https://github.com/firebreath/FireBreath/blob/master/src/ActiveXCore/ActiveXBrowserHost.cpp#L186 and see what type it comes in as from COM
but it looks like it's returning VT_NULL, which is really bad of them
but I don't know what to do about it
dreid 13:01 It appears that perhaps I actually need is_null || empty because it appears that one works on IE9 and one works on IE8.
taxilian 13:01 lol
probably
dreid 13:01 If that doesn't work I'm just going to have to deal with default values in JS I guess.
But now I'm annoyed so I'm determined to bend IE to my will.
taxilian 14:01 lol
shenberg 20:01 Hi,
I think I found a memory leak with FB::variant. It might be me using the class the wrong way, but it might be an actual issue:
I have an object which holds a variant and a wstring (both by value). Once per timer tick I change the contents of the wstring, and then assign the wstring to the variant
That leaks the previous wstring
I'm not explicitly allocating memory anywhere
If I do a reset() call on the variant before each assignment, I stop the leak
My assumption would have been that assignment guarantees not leaking the previous value...
the last commit on my version is 43e46bd31c4e0ea720be6bf58f9fe241b3cf525f
FireBreathBot 20:01 43e46bd by Christian Hofstaedtler: FIREBREATH-153 Make prepmac.sh honor CMAKE_OSX_ARCHITECTURES http://goo.gl/O8f8h
shenberg 20:01 Okay, stuff is behaving weirdly on my system. Please disregard my earlier complaint till I verify that what I thought is happening really is what's happening...
shenberg 20:01 Okay, it is indeed leaking...
I'm also getting a leak when doing MyPluginJSAPIPtr->register/setAttribute("myAttribute", obj.stored_variant, false);
shenberg 21:01 Okay, I'm at a point where MyPluginJSAPIPtr->SetProperty("aProp", std::string(100000, 'c')); leaks memory
The options are either that std::string causes a leak, or FB::variant. My guess is the second, but, I'm using MSVC 2010 SP1, so it might actually be a broken STL...
shenberg 21:01 (Also, note that the leak still happens even if I create one copy of the object, then repeatedly use the same object in SetProperty)
One last thing - if my call sequence is MyPluginJSAPIPtr->RemoveProperty("aProp"); MyPluginJSAPIPtr->SetProperty("aProp", string_variant); then I don't leak memory, while successive calls to SetProperty do. It looks to me like it's the same leak-on-variant-assignment issue... I really hope I'm massively misunderstanding what's happening here and that I'm just an idiot not writing proper C++