IRC Log Viewer » #firebreath » 2011-01-04

IRC Nick Time (GMT-7) Message
zmichl 02:01 Hello, I am getting this error when compiling on MacOS X 10.5. What could be wrong please?
The following build commands failed:
DSV_PluginAuto:
CompileC build/projects/DNSSECValidator/PluginAuto/FireBreath.build/Debug/DSV_PluginAuto.build/Objects-normal/i386/P
luginWindowMacCarbonCG.o /Users/zbynek/dnssec-plugin/plugin/FireBreath/src/PluginAuto/Mac/PluginWindowMacCarbonCG.cpp normal
i386 c++ com.apple.compilers.gcc.4_0
iaincollins 03:01 Happy New Year everyone
zmichl 05:01 iaincollins: hehe, finally sober after New Year's Eve? :)
iaincollins 05:01 Hehe, no just back at work alas
(which is, erm not to say am not sober (alas))
Was knocked out for over a week with N1H1, starting from Christmast Eve, still coughing now, bah!
neilg_ 07:01 Happy New Year everyone! Even though I was working yesterday... lol
nitrogenycs 09:01 Happy New Year :)
taxilian 09:01 zmichl: you still around?
zmichl 09:01 taxilian: yes, but I solved the error already ;)
taxilian 09:01 oh, good
just checking =]
it's good to see people in the channel again… it's been lonely over the holidays :-P
zmichl 09:01 I forgot to set FBMAC_USE_... macros to 0
taxilian 09:01 ahh
so neilg_, iaincollins: one of the big new features of 1.4 is that you can have optional arguments in a JSAPI method signature =]
neilg_ 09:01 That's pretty cool!
taxilian 09:01 the variant casts are also a lot more powerful, so you no longer need to worry about casting all JSAPI types to JSAPIPtr before returning them; you can just return FBTestPluginAPIPtr type, etc
iaincollins 09:01 ooooh nice
taxilian 09:01 also you can accept a JSAPI type and it will pull the JSAPI object out of the underlying browser object so that you can handle JSAPI objects returned to the browser and passed back in
zmichl 09:01 taxilian: I have remark to the prepmac.sh script. When I use it like "./prepmac.sh projects build", it ctreates the build tree in the current directory instead of inside the build dir
taxilian 09:01 zmichl: sometimes CMake gets confused on that; I haven't seen it in awhile, so I hoped we'd fixed it. If you can clean up all the cmake files in the tree the problem should go away
it's a pain, though
still haven't figured out what causes it to start
once it happens once it'll keep doing it until whatever file cmake is looking at gets deletedc
I highly recommend moving your projects dir out of the FB source dir anyway, though
iaincollins 09:01 oooh.. how well does the object handling work?
taxilian 09:01 iaincollins: for JSAPI objects passed in from the browser?
iaincollins 09:01 yeah
taxilian 09:01 perfectly, AFAIK
iaincollins 09:01 Cool! Can imagine that being tricky to impliment
taxilian 09:01 it'll throw an exception if you pass something in that doesn't match the type you specify, just like anything else
iaincollins 09:01 oh neat
taxilian 09:01 let's just say I've learned to do things with templates in the last week that threaten my sanity :-P
iaincollins 09:01 Templates threaten my sanity period :(
taxilian 09:01 also any type that FB "supports" you can also cast to a boost::optional and it becomes optiona
l
so if your parameter type is FBTestPluginAPIPtr, you can use instead a boost::optional<FBTestPluginAPIPtr> and you can pass in null and it'll work
actually, come to think of it I think with the fix I pushed last night you can always provide null for an object, so that should be checked for
but other types; int, bool, std::string
whatever is supported
iaincollins 09:01 that's very cool
taxilian 09:01 I'm working on support for boost::variant types so that you can use a boost::variant to say "this type can be a bool, int, or std::string"
iaincollins 09:01 any idea (e.g. from the surveys) if people are doing a lot of object or value passing in their plugins?
taxilian 09:01 it'll try the conversions in the order you specify and only fail if none of them succeed
iaincollins 09:01 (for me, very heavvily, but no idea what other people are doing)
taxilian 09:01 nobody has really specified anything like that; some people have been, but I don't know how many
jtojanen 09:01 I am doing a lot of conversion :)
taxilian 09:01 the project that has the most complex object model that I'm aware of is http://github.com/firebreath/indexeddb
zmichl 09:01 taxilian: yes, i have it outside, as described at http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/
iaincollins 09:01 being able to pass objects would reduce a lot of boiler plate for me
taxilian 09:01 zmichl: and it's building in the current dir? weird
zmichl: I'd recommend deleting all the build files in that dir and trying again; should fix the issue
iaincollins 09:01 I could do away with a lot of getters / setters
taxilian 09:01 iaincollins: it's in 1.4 alpha 2
incidently, another new features is "attributes"
you can registerAttribute("name", value, true) to set a readonly attribute (acts like a property, but set using registerAttribute
omit the last param to set a read/write attribute
iaincollins 09:01 I am mostly dealing with objects that are variation of a core set of types (e.g. network devices from specific vendors, and then variations from vendors on those devices)
taxilian 09:01 jtojanen: you were asking about support for boost::variant, right? I'm adding it now =]
jtojanen 09:01 Taxilian, could you change the behaviour in ActiveXBrowserHost::getVariant with VT_I8 and VT_UI8 to double instead of int?
boost:variant, thank you!
taxilian 09:01 if that's what it should be, yes
I've never seen those types passed
jtojanen 09:01 truncation after 2^53
:)
taxilian 09:01 would an int64_t be better?
iaincollins 09:01 oh how is an attribute different to a property?
jtojanen 09:01 JavaScript doesn't support that
taxilian 09:01 a property has a getter/setter, an attribute is stored in a map on your class and handled for you
iaincollins 09:01 oh! automagic
neato
taxilian 09:01 jtojanen: is double really the best solution, then? maybe a string would be better
jtojanen 09:01 doulbe
taxilian 09:01 iaincollins: also, implicit properties are enabled by default; so in JS if you set a random property name, it will get stored as an attribute
iaincollins 09:01 that *is* going to shrink my code size
taxilian 09:01 it's great for things like constants
iaincollins 09:01 o_0
taxilian 09:01 jtojanen: I'll take your word for it for now
=]
jtojanen 09:01 There will be no loss with numbers smaller with +/-2^53
taxilian 09:01 ok
jtojanen 09:01 And if someone has problem, then we could convert bigger numbers to string
taxilian 09:01 hmm. I actually had a problem with that at one point; I think I did end up converting bigger numbers to string for that reason. Let me look through and see what we have; trying to remember
let's see, are you referring to the type *from* VARIANT to FB::Variant?
jtojanen 09:01 yes
taxilian 09:01 ok; since javascript doesn't support that, it'll probably never come up anyway
but I'll change it
VT_UI8 is actually an int64, no?
jtojanen 09:01 thanks, and yes it is
no no
VT_UI8 is uint64
taxilian 09:01 yeah, that's what I meant
since it's incoming, I'll just store it as what it is in the FB::variant, since that supports it
we'll deal with outgoing when it becomes an issue, I guess
jtojanen 09:01 what will happen in conversion?
taxilian 09:01 boost::numeric_cast
jtojanen 09:01 that will work
zmichl 09:01 taxilian: huh, it's ok now :) but i am pretty sure that i had the same dir/file structure before :)
taxilian 09:01 zmichl: it could be. cmake is kinda odd sometimes
jtojanen 09:01 Taxilian, why do we have with plugin these generated "Win/dllmain.cpp" and "Win/np_winmain.cpp" files? Should these be in PluginAuto project under the Win folder?
taxilian 09:01 jtojanen: my goal has always been to allow as much customization as possible; those are the main entrypoints for FireBreath, so I opted to leave direct control of them to the user
jtojanen 09:01 In these files there is nothing plugin related
taxilian 09:01 I debate the wisdom of that sometimes, but I just figure that the user may want to have them
jtojanen 09:01 okey
taxilian 10:01 since there is nothing plugin related in them, that usually means that breaking changes don't affect them; unfortunately this time they did :-/
but at least you can just copy the template files
jtojanen 10:01 that is the reason why i'm asking
taxilian 10:01 yeah, I figured
at this point to remove them would be to remove a customization point that has always been there, and I try not to do that without a really really good reason because someone may be using it
zmichl 10:01 taxilian: I have one one more question. Is FB able to make IE plugin with extension (including graphics like icons, popup menus, ...)?
taxilian 10:01 no
I believe you need a BHO (Browser Helper Object) for that, and FireBreath does not make any attempt to be a BHO
zmichl 10:01 taxilian: ok, but is it possible to make two different dlls (plugin, extension) and call plugin functions from the extension?
taxilian 10:01 hypothetically, I would suppose so; however, I don't know what would be involved
if a BHO can inject HTML into a page (dunno) then you could do that and interact with it through a page
you could of course instantiate the activex control from inside the BHO, but then the activex control wouldn't have a link to the page
brb, I need breakfast
back
zmichl 10:01 taxilian: ok, thanks for explanation. Now I have a Firefox extension with FB plugin (plugin is inserted through <object> element, so I can call plugin's functions). And I need to port it to IE, so I'd like to choose the easiest way :)
taxilian 10:01 yeah, I really don't know :-( sorry
zmichl 10:01 taxilian: That's fine :)
jtojanen 10:01 Taxilian, what is the oldest Mac OS that is supported by FB?
taxilian 10:01 my understanding is that currently 10.5 is the oldest that it should compile on; someone got it working on 10.4 but we never got his changes merged in
partially because I don't even have a 10.5 box to test on
much less 10.4 =]
jtojanen 10:01 okey but 10.5 and 10.6 cover most
of user
taxilian 10:01 that's my thought as well
I have to rely on others to test on 10.5; it was working last I heard, so I assume it still works
jtojanen 10:01 I will let you know as soon as I get OS installed
taxilian 10:01 cool
I have automatic conversion from boost::variant types to FB::variant; now I'm just trying to figure out why my conversion back to boost::variant isn't working
gotta love metaprogramming...
zmichl 10:01 I have Mac 10.5 and FB compiles fine for me ;)
iaincollins 10:01 will have fun checking out 1.4.x this week ... take it easy all :-)
taxilian 12:01 boost::variant support seems to be working now
FB_GitHubBot 13:01 FireBreath: master Richard Bateman * 8d9971b (6 files in 3 dirs): Added experimental support for boost::variant conversion ...
FireBreath: master Richard Bateman * 5ee1d01 (2 files in 1 dirs): Fixed conversion from boost::variant to FB::variant on mac/linux
FireBreath: master Richard Bateman * 3bf6b20 (5 files in 3 dirs): Added support for converting from FB::variant to boost::variant
FireBreath: master Richard Bateman * e93aeae (1 files in 1 dirs): Fixed minor Mac issue w/ boost::variant
FireBreath: master commits 1a81021...e93aeae - http://bit.ly/ep8Xoz
taxilian 13:01 and boost::variant works
FB_GitHubBot 13:01 FireBreath: firebreath-1.4 Richard Bateman * 8d9971b (6 files in 3 dirs): Added experimental support for boost::variant conversion ...
FireBreath: firebreath-1.4 Richard Bateman * 5ee1d01 (2 files in 1 dirs): Fixed conversion from boost::variant to FB::variant on mac/linux
FireBreath: firebreath-1.4 Richard Bateman * 3bf6b20 (5 files in 3 dirs): Added support for converting from FB::variant to boost::variant
FireBreath: firebreath-1.4 Richard Bateman * e93aeae (1 files in 1 dirs): Fixed minor Mac issue w/ boost::variant
FireBreath: firebreath-1.4 commits 1a81021...e93aeae - http://bit.ly/ep8Xoz
taxilian 14:01 anyone here interested in testing some new awesome JSAPI features for me?
wolfmanfx 14:01 hi i run into an issue my app is plugin based but now it can not load this plugins because i do not know the path where dll's are. Is there any functionality/possibility to retrieve the path where the np plugin lives?
taxilian 14:01 well, yes, you can find out the path tot he plugin
but that only helps if you are dynamically loading the DLLs?
wolfmanfx 14:01 yep i am loading dynamic
taxilian 14:01 http://www.firebreath.org/display/documentation/Tips+and+Tricks#TipsandTricks-Gettingthepathandfilenameoftheplugin%28DLL%2C.so%2Cor.dylib%29
wolfmanfx 14:01 thx
taxilian 14:01 np
kylehuff 15:01 taxilian: what are you looking to get tested?
taxilian 15:01 I'd just like to see some people using the new features a bit; if not that, then some tests added to FBTestPlugin to show that they work and how they work
kylehuff 15:01 I could try, though the FBTestPlugin might be the way to go. do you have a list of the featuers?
taxilian 15:01 err, in my head =]
a better test / example of using optional arguments would be a good starting point
taxilian 15:01 the boost::variant support is the other thing that there are no tests for (except in the unit tests)
jtojanen 15:01 someone has been busy :)
taxilian 15:01 hehe. I'm on a 9 day streak for committing something to github every day, according to http://calendaraboutnothing.com/~taxilian
jtojanen: You interested in doing any testing on boost::variant support for me?
jtojanen 15:01 I will test how it works tomorrow, but looks good. Let's see if ISO image file size works without truncation
taxilian 15:01 internally everything still uses FB::variant, because boost::variant just doesn't do everything we need, but converting betweent he two should work well
cool
was that getting truncated?
jtojanen 15:01 yep, to 32-bits
guys were complaining
taxilian 15:01 huh. well, that should be fixed, I think
jtojanen 15:01 i bet it will
taxilian 15:01 also uint32 was being truncated to int32
that could have caused some issues as well
jtojanen 15:01 also simplifies my own code as i'm using boost::variant internally
taxilian 15:01 cool
something to know about how that works, btw
jtojanen 15:01 which part?
taxilian 15:01 whatever is stored in your boost::variant can be assigned directly to a FB::variant with no problems
but going back can sometimes be tricky
if one of the types supported by your boost::variant is an exact match to what is in the FB::variant, then it will use that one
otherwise it will use the first successful convert_cast
jtojanen 15:01 does it throw bad_cast?
taxilian 15:01 unfortunately, that means that if there is a float in the FB::variant and your boost::variant has int before double, then it will convert it to an int
if there are no valid casts
jtojanen 15:01 that is nasty
i have to check to order then
taxilian 15:01 yeah; trying to decide how to deal with that
the question is, if you tell it to convert_cast<int> and it's a floating point, should it ever succeed?
should it only succeed if it doesn't need to truncate?
boost::numeric_cast truncates by default
of course, one option is to just not use float; if everything is a double, or if you have both, then it's not an issue
jtojanen 15:01 but boost::variant knows the exact type
and yes, double is only used
taxilian 15:01 right; this is only an issue coming from FB::variant to boost::variant
jtojanen 15:01 As I said, JavaScript knows only double
taxilian 15:01 I could probably find a way to make FB::variant::cast work to a variant
right; so it's probalby not an issue
I'm just mentioning it as it's the only real issue I know so far =]
similarly, though, if you have a short and there are no shorts in your variant, it will convert it to the first valid type
if the list is <double, int, long> then the short will get converted to a double
jtojanen 15:01 smallest first
taxilian 15:01 right; so if you order it smallest first, it should be okay
anyway, the main place that will matter is if you use a boost::variant type as a parameter in your JSAPI method
jtojanen 15:01 that is the order right now
taxilian 15:01 good
jtojanen 15:01 previously it wasn
t possible
taxilian 15:01 yeah; it should be now. I haven't tested that, but it just uses FB::variant::convert_cast, and I have a unit test that tests that
the cool thing is that means you can use boost::variant to say "this parameter can be a std::string or a std::vector<std::string>"
and either will be accepted
jtojanen 15:01 COM application would love to have conversion to CComVariant..
taxilian 15:01 you can also use boost::optional<type>
should be doable; you can add types to support boost::variant casting to and from, you just have to have it all included in the right order
jtojanen 15:01 By the way, where do you have to define exactly the number of parameters to JavaScript function?
taxilian 15:01 yes and no
jtojanen 15:01 BSTR is the bastard
IDispatch want param in reverse order
it will ignore unnecessary
Saw your comment in code regarding named parameters in IDispatch Invoke
taxilian 15:01 ahh, for setting properties
yeah
that was a fun one to troubleshoot, let me tell ya
the PUTREF one was too
so number of parameters
as of 1.4 there are several ways to allow optional ones
previously, you had to use FB::CatchAll as a type, which basically holds a FB::VariantList wtih 0 or more parameters
that makes it variable length from then on
as of 1.4, however, a FB::variant type or a boost::optional type at the end is an optional parameter
and the behavior of optional parameters is still a little bit in flux as I try to figure out what the most intelligent behavior is
jtojanen 15:01 that is tricky
JSAPI_IDispatchEx line 365: // TODO: Figure out why default function calls have an extra argument;
taxilian 15:01 the sheer amount of compile-time meta-code involved in all of this gives me a headache =] for all of that, it's surprisingly concise
yeah; any ideas? =]
jtojanen 15:01 DISPID_THIS
With IDispatchEx id==0 can be used as constructor
taxilian 15:01 hmm. I think I remember reading about that a little; I've been meaning to add support for it
NPAPI has NPN_Construct
jtojanen 15:01 Constructor method need needs to know the scope
taxilian 15:01 makes sense
so it passes in the IDispatch* for the scope?
jtojanen 15:01 To be the scope of new object
taxilian 15:01 hmm… that would probably also be the use of the GetParentScope thing
interesting
jtojanen 15:01 No used to JScript engine
by I mean
taxilian 15:01 fair enough. So is there anything there that you think I should worry about? or just leave it as-is?
jtojanen 15:01 for now
taxilian 15:01 cool
jtojanen 15:01 In callbacks it makes sense to define it by yourself
taxilian 15:01 meaning functions we pass to javascript to be called?
jtojanen 15:01 if we are calling JavaScript function that has been assigned to us
taxilian 15:01 hmm. not sure I understand
jtojanen 15:01 function foo(){ this.bar = "some"}; var o = new Object(); o.func = foo; o.func();
this.bar to work
stupid example
taxilian 15:01 hmm. interesting
do you have any idea how we can get a reference to the DOM object that we're in? our Object tag?
oh, and do you have any idea what DISPID_SECURITYCTX is?
(sorry, all the questions I haven't found answers to in the last two years… :-P)
jtojanen 15:01 Second one I haven't seen but first one.. could you explain more what you mean?
Access to JScript engine on browser?
taxilian 15:01 on the page there is an object tag; that object tag has a mimetype or clsid that cause our plugin to instantiate
however, that object tag has attributes that aren't part of our IDispatch interface
such as id, width, height, position, etc
for that matter, it might be possible through the DOM to get a list of available PARAM tags instead of relying on knowing them ahead of time
on NPAPI, there is a call that says "give me my DOM element"
jtojanen 15:01 IPropertyBag during the initialization?
taxilian 15:01 "id" returns nothing
http://stackoverflow.com/questions/4103315/how-to-get-a-ihtmlelement-pointer-to-the-object-tag-hosting-an-activex-control
I ask that question on StackOverflow… nobody knows
so far my best thought has been to use GetElementsByTagName, iterate through all object tags, and make some sort of call to see if they are our plugin. (maybe have a unique instance ID somewhere or something)
jtojanen 15:01 I will have to check that tomorrow
taxilian 15:01 if you can find a way to do that on IE, it'd solve some long-standing problems / challenges =]
jtojanen 15:01 Happy to help (if I can)
taxilian 15:01 as for the DISPID_SECURITYCTX (-5511), we get it multiple times for every request made to our plugin
but I can't find any docs for it anywhere
it's something IE specific
that's all I know
jtojanen 16:01 It must be browser stuff as I haven't seen that with JScript engine alone
taxilian 16:01 defined in MsHtmdid.h
jtojanen 16:01 IE stuff
taxilian 16:01 just makes me wonder if there might be an advantage to implementing it, since it's being called so often
=]
jtojanen 16:01 UAC has been giving enough problems for today....
taxilian 16:01 hehe. gotta love UAC...
jtojanen 16:01 There is bug we have to fix but let's leave it for tomorrow. I will get some sleep now.
taxilian 16:01 aight; FYI, tomorrow I start school again, so I won't be available as much
should be on my morning, though
jtojanen 16:01 that good..
wolfmanfx 16:01 i relaized now that every project used Code Generation MutliThreadedDebug and my plugins using MultiThreadedDebugDll i changed now every project by hand is there a way to enforce it with cmake?
taxilian 16:01 change the plugin to use the Dll?
wolfmanfx 16:01 Loading DynLibs with different code generation was a good crash :)
taxilian 16:01 hmm. I'm not sure why it would matter as long as you aren't releasing anything that is allocated on the other side of the boundary (and vise versa), but yes, you can change FireBreath to use dynamic CRT
http://www.firebreath.org/display/documentation/Prep+Scripts
run the prep script with prep2010.cmd projdir builddir "-D WITH_DYNAMIC_MSVC_RUNTIME=1"
you might want to delete your build dir first; not sure if that one will need it or not
wolfmanfx 16:01 i see everything well thought here :)
taxilian 16:01 mostly you're just not the first one to have the problems =] but we try
one thing, though
if you're having a crash from that, you likely have a deeper problem with your memory management
wolfmanfx 16:01 memory management should be fine (mem tracker do not show any leaks) and i am aware that pass the owner ship of some factories to the main dll
thats why it crashes
taxilian 16:01 well, I guess it's up to you, but that's both bad practice and dangerous (For reasons you're seeing)
if you allocate something in one module, you should never free it in another
the way I normally solve that issue is to have some sort of deallocation function that you can call from the other module to free something
but yes, that will definitely cause a crash if you're doing that; if you're using the same version of the CRT, you might be okay, but it's a lot more fragile than I would want to have things
wolfmanfx 16:01 i think it comes down to the fact that i am the only guy who write and compile these plugins
and i can also build everything static
taxilian 16:01 well, it's your system; I'm just letting you know =]
wolfmanfx 16:01 so thats not a big issuse as long i know why it happens :)
taxilian 16:01 my personal preferance for plugins is to build everything static; you lose a lot of the benefit of dyanmic linking with that memory handling problem, because if you change the DLL and it's not exactly the same type of CRT dll it will all die
also, I've had a lot of weird issues with using dynamically linked stuff, though dynamic loading fixes most of those
anyway, it's no hair off my chin =]
wolfmanfx 16:01 :) i think in the end (when i release something) i will build one big dll which contains everything
taxilian 16:01 cool. what are you working on, btw? or did you already tell me? (sorry, I have a bad memory sometimes)
wolfmanfx 16:01 I am working on a small game its already working on pc/mac now i am trying to port it (at least i try) to firebreath
taxilian 16:01 ahh, right, you said you were doing 3d graphics
cool
wolfmanfx 16:01 it uses ogre for the rendering
taxilian 16:01 how is it coming so far?
wolfmanfx 16:01 i thought that i am seeing something now
but it crashes now here void CrossThreadCall::asyncCallbackFunctor(void *userData)
taxilian 16:01 what is the crash?
and what version of FireBreath?
wolfmanfx 16:01 dont know have to track down a little bit
taxilian 16:01 I mean what is the error
wolfmanfx 16:01 memory access fault :)
taxilian 16:01 hmm. you're using threading, I take it?
ooh… are you using HWND PostMessage signalling?
wolfmanfx 16:01 is that not working?
or just on the topHWND
taxilian 16:01 it's not that that doesn't work
it's that FireBreath also uses it
so if you use the same message ID...
wolfmanfx 16:01 uh that could be something deep in ogre
have to check it
taxilian 16:01 hmm. actually, the FireBreath code that uses it probably isn't needed anymore, if you're on the latest
FB_GitHubBot 16:01 FireBreath: master Richard Bateman * 0c90a69 (1 files in 1 dirs): Removed potentially problematic handling of custom HWND message that is no longer used - http://bit.ly/dI4GuG
taxilian 16:01 try pulling the latest firebreath from github; or just apply the patch I just pushed
wolfmanfx 16:01 ok i applied it manuelly
is the latest stuff on git stable?
taxilian 16:01 it's in alpha
wolfmanfx 16:01 k
taxilian 16:01 there may be some issues, but it should be pretty stable
if you find any issues, please let me know; I should be able to fix them w/in 24 hours
wolfmanfx 16:01 super
k this crash is gone but now i got another
assertMainThread();
bool NpapiBrowserHost::InvokeDefault(NPObject *npobj, const NPVariant *args,
http://nopaste.info/263123a58b.html
here is the stacktrace
taxilian 16:01 that's… weird.
that shouldn't be possible
can you look at the thread_id of the failed assertion and see if it actually is on the main thread or not?
wolfmanfx 16:01 yeah i am on it
k i got this crash because a plugin had a depency to openAL32.dll which is not in the system path for the moment i disabled this plugin and i got something on my screen :)
taxilian 16:01 huh
wolfmanfx 16:01 but the error msg is weired
taxilian 16:01 strange
wolfmanfx 16:01 hehe what i see is that firefox hates directx
but openGL renderer is fine
taxilian 16:01 what version of firefox?
FYI, I have used directx in firefox before
wolfmanfx 16:01 3.6.13
taxilian 16:01 hmm. I understand that 4 uses directx for some rendering
it may just be that you need to set your context up to match how firefox is using it
wolfmanfx 16:01 FF redners it but all menus and toolbars are gone
taxilian 16:01 ahh. yeah, that's fixable, but I don't know how exactly
things have to be configured correctly with your DX context
wolfmanfx 16:01 ah
what method do you use to render stuff i read that you suggest to use one render thread
atm i am using a time which suxs
*timer
taxilian 16:01 yeah, timers are sometimes tricky
it's also possible that your renderer running on the same thread as firefox may be hijacking the window messages somehow
wolfmanfx 16:01 ok now it renders in ff/chrome
but in ie i got a blank page
or do i have to restart the browser
ok i have restarted but no renderings her
is their an event in IE like WM_PAINT where i should draw?
now iam just drawing in the timer event
taxilian 16:01 you should draw in response to WM_PAINT as well, but the timer should get you started
FB_GitHubBot 21:01 FireBreath: firebreath-1.4 Richard Bateman * 0c90a69 (1 files in 1 dirs): Removed potentially problematic handling of custom HWND message that is no longer used - http://bit.ly/dI4GuG