IRC Log Viewer » #firebreath » 2011-05-06

IRC Nick Time (GMT-7) Message
jks 01:05 hi guys... can anyone suggest some hints on how to use a MFC DLL from a Firebreath plugin?
jks 07:05 what is the easiest way to include an existing MFC application in a Firebreath plugin?
FireBreathBot 07:05 JIRA issue issue created by catchfbinfo
chrdorn_zurich 08:05 anyone there :) ?
neilg_ 09:05 Morning all!
jks: What are you planning on doing with your MFC application/plugin?
You'll want to add the MFC runtimes to your plugin installer for a start (unless you can statically link against MFC?)
jks 09:05 neilg_, right now I'm just testing, so I already have the MFC runtimes installed on the system, etc.
neilg_, basically I have an existing MFC app that I would like to run as a plugin also
neilg_, I was thinking of something like compiling the MFC program into a DLL
neilg_, and then I figure I need to pass the HWnd to the DLL and use that to initialize the primary window with
neilg_, however it seems "something more" needs to be done in order for MFC to function... not quite sure if it is CWinApp or similar that needs to be initialized
FireBreathBot 10:05 JIRA issue issue resolved by richard "This issue is already fixed; please update to the latest version of FireBreath (or at least to 1...."
taxilian 10:05 jks: I have seen others try to make MFC and FireBreath play nice together and I'm not sure anyone has succeeded; I don't know if it is possible or not. FireBreath uses ATL; as long as you can make it work with ATL you should be okay
jks 10:05 taxilian, hmm, okay... could possible be quite complicated then (?)
taxilian 10:05 it might be; then again, the people I've seen try before didn't really understand anything about how MFC or ATL work, so it might not be bad if you know what you're doing
however, I've never really liked MFC and so haven't even tried using it =]
jks 10:05 well, I'm no fan of MFC either... but rewriting a program several years in development isn't really to my liking either ;-)
taxilian 10:05 keep in mind that many existing programs don't port well directly into a plugin
if they rely on cwd, global / static variables, singletons, etc you might have issues
but that doesn't mean it can't be done
FireBreathBot 10:05 JIRA issue issue closed by richard
jks 10:05 taxilian, yeah, but it's already written to be used as a plug-in... just not a browser plug-in
taxilian 10:05 ahh
well, I hope you figure it out; if you do, could you let me know what it took?
FireBreathBot 10:05 JIRA issue issue created by richard
Commit 4ae1a86 on firebreath-1.5 by doug mansell: "FIREBREATH-52: correct for when T is an unsigned 32-bit inte..."
Commit 4ae1a86 on master by doug mansell: "FIREBREATH-52: correct for when T is an unsigned 32-bit inte..."
JIRA issue issue resolved by richard "Imported into 1.5 branch and master (currently 1.6)"
JIRA issue issue closed by richard
neilg_ 10:05 jks: Now, I haven't tried this. But my suspicion is that the easiest way for you to do this would be to use FireBreath to launch your own MFC executable and pass the window handle. This would only work on Windows though.
Then you should be able to make MFC use your HWND
Of course the mere fact you're using MFC means you only want it working on Windows so...
But that's not the normal usage of FireBreath. But it does work...
jks 13:05 neilg_, ah, that's a good idea... the pointer HWND would be valid in the address space of another process?
I assume there's some kind of safety mechanism somewhere, but perhaps it doesn't apply to forked child processes or?
taxilian 13:05 that's not a bad idea
HWNDs are cross-process
however, you can't use the winproc for your HWND in the other process
but what you could do is create a new HWND in the child process and pass it back to the parent; you could then have a winproc for the child process in the child process and just PostMessage to pass all window messages from the parent window to the child window process
since you can PostMessage to any HWND you can reference
neilg_ 13:05 Actually, that would probably work even better given how MFC probably won't want to use an external HWND
Ugh. "work even better"? "be better" would... be better. lol
taxilian 13:05 let's just go with "that might even work"
given the subject matter
jshanab_wcw 16:05 I am getting as fed up with Visual Studio as I am with SVN. Wondering if There is a better way that would still work well with the prep scripts wehn in windows. (intelisesne useless, debugger stops working etc)
taxilian 16:05 jshanab_wcw: you could always use vi and build on the console :-P
what version of vs are you using?
jshanab_wcw 16:05 Not that I haven't done that but I do need debugging
taxilian 16:05 windbg?
jshanab_wcw 16:05 Visual studio 2010 premium. There are just so many things that are starting to tick me off, there just has to be something better.
taxilian 16:05 huh; I haven't had any real issues with 2010
jshanab_wcw 16:05 I could run kdevelop on windows, but i suppose that would use GCC?
taxilian 16:05 right
nothing else uses microsoft's compiler that I'm aware of
jshanab_wcw 16:05 Really? maybe something is wrong with my version. Intelisesne is so slow it is almost useless, it crashes 3 to 5 times a week and it gets confused and won't recognize the symbols and therefore silently won't stop on breakpoints.
taxilian 16:05 you can disable intellisense if it's causing that much trouble
and when it doesn't recognize symbols that usually means you aren't debugging with the version of the dll you think you are
jshanab_wcw 16:05 Well changing compilers would get rid of the pdb problem :-). Don't shoot me, but i do thing GCC is a better compiler
taxilian 16:05 or you changed a file and didn't compile it again
quite possibly… but you can't use it with ATL on windows =]
jshanab_wcw 16:05 right, so I shut down everything -re-prep, uninstall and rebuild and install the plugin fresh, Usually that works, but about once a week that is not enough and it take 4 hours of messing arround to get it to work. So random, hard to find.
taxilian 16:05 I have never had to do that much crap to make it work
generally I just thought it built and it didn't 'cause the dll was still in use
jshanab_wcw 16:05 Isn't the ATL, MS's implementation of the stl?
taxilian 16:05 no
atl is activex template library or some such
it's used for the activex stuff
could be rewritten to not require it… if you'd like to do so, please feel free ;-)
jshanab_wcw 16:05 Oh, and FB needs that for the ActiveX side
taxilian 16:05 or if you can find someone willing to pay me for it I'll do ti =]
jshanab_wcw 16:05 Did you notice that you cannot even reference the members of a class in a watch or printing brakpoint any more?
taxilian 16:05 sure you can
maybe your system is messed up
I do that all the time
jshanab_wcw 16:05 It says it is not allowed. What version do you have? Premium/professional/etc? Maybe I need to get a more professional distro (for lack of a better term)
taxilian 16:05 Premium, I believe
might be professional
don't actually know what the difference is
Premium ont he computer next to me right now
jshanab_wcw 16:05 I was thinking this is silly, no one would tolerate not letting you access a class. Maybe that is one of the differences!
taxilian 16:05 nah, that's what I'm using
works just fine for me
jshanab_wcw 16:05 you have to type {value} in your version, right? if i try {classptr->function()} it says not supported
taxilian 16:05 sorry, what? I have never used { } in watches...
-> sometimes doesn't work if it's something where -> is overloaded, but if you do just the class and then step down inside you can right click and do "add watch"
jshanab_wcw 16:05 Well I am pulling my hair out on this thing, won't even attach to my code. If I could debug i would check, the {} are on the break points I guess
taxilian 16:05 huh. I could try looking at it, if you have a way I could see what you're doing