|
First, thanks your comment.
I am not a specialist of BHO programming, and I have some questions to ask you.
Bill SerGio wrote:
1) You are NOT using Browser Helper Objects correctly. BHOs fail very often when their are more than one BHO listed in the registry and this varies as a function of the version of IE installed. The CORRECT way to use BHO is to create a list of existing BHOs and determine if your GUID will sort above them alphabetically---if not, you must create a new GUID for your BHO that starts with something like {0000001..... so it will appear at the TOP of the list of BHOs--BHO are loaded alphabetically in sequence. And the commercial applications I write remove all the other BHO until my DLL has load and THEN I restore the other GUIDs back to the registry--this is what professional application programmers do.
If all BHOs are writed like yours, how can you ensure your BHO is loaded before others?
In addition, I have never found my BHO fail.
Bill SerGio wrote:
2) NEVER use the BHO to do anything except to launch another program or toolbar and then exit IMMEDIATELY! The BHO itself should NEVER be used as part of the application because it creates a lot of coding problems and SLOWS the performance of any sink application!
You are right. But there is no such problem in my application.
Bill SerGio wrote:
Finally, while I do write a lot of ATL/WTL crap, I think MFC is VASTLY superior for creating SINK applications. For example, I can rewrite your entire application in 15 minutes using MFC and create an exe that is 1/3 the size with far better performance by NOT making the exe a COM object itself which just slows down the sink. I have also found it is far better to place all of the sink code in a .lib file for much better performance.
I am very interest in what you say.
How can you make a static linked MFC application smaller than using WTL?
What inter-process communication method you want to use if not making the exe a COM object? (I didn't find performace issue in COM invoking).
How to increase the performance by placing all of the sink code in a .lib file? How to place all of the sink code in a .lib file?
Hope you can understand my poor English.
|
|
|
|
|
Let me say again that I thought your code was excellent!
My comment refers only to the "design" of the program.
Look at the sample code I posted in my comment that launches a new instance of IE and place this code into your program. You will see that your program no longer works if you launch a new instance of IE from your exe file using the code I posted. It can be done but would require using some very bad coding fixes to get around this---this same situation can occur as a result of loading a web page with certain types of javascript coding.
Another solution, is to change the "design" of the application and place the SINK code in your BHO inside of your exe and to solve this problem and other problems inherent in this type of design.
As far as BHO goes, I learned from installing sink software on millions of computers that you can NOT go by how something works on your computer. Microsoft has commented in the MSDN on this problem with BHOs and it has NEVER been fixed. I create a GUID that starts with {00001 or as LOW a value as I can which means it will be executed first. In many of my programs I go one step further and also REMOVE all of the other BHOs listed in the registry---with the user's permission and make sure that ONLY my BHO is listed in the registry while my program is running.
I will probably post a sample of a SINK library in the next 2 weeks and i will email you to see how I do it using MFC.
Best regards,
Bill SerGio
|
|
|
|
|
I am waiting for you sample.
Thanks & regards
|
|
|
|
|
Hi,
Excelent code.
I tried emailing you but email bounced back so using this form.
Can i use your code to make my application.
Can u make index.dat cleaner or add it to this ?
Thanks and keep up the good work.
PS : i wonder what else u have done other than this.
Regards,
Ashish t
|
|
|
|
|
A Good explanation of what BHO are for, is avaliable at What is a Browser Helper Object. As far as the principle of merely using a BHO to launch an instance of your executable file, I see NO point to this once so ever. BHO are to allow your application to monitor and interact with Internet Explorer and Windows Explorer windows. If you attempt to use the BHO to launch another exe, and then use that exe to monitor events and interact with windows, then you are in fact doing the same exact task that a BHO does. The only difference is that instead of slowing the performance of Internet Explorer or Windows Explorer, you will slow the performance of the ENTIRE machine, by attempting to monitor all system messages for the desired information.
BHO are an easy way for you to monitor the messages of an existing Internet Explorer, or Windows Explorer window so that you may interact with them as needed, without trying to monitor the messages through the use of PeekMessage or some through some other means.
Bill SerGio wrote:
As far as BHO goes, I learned from installing sink software on millions of computers that you can NOT go by how something works on your computer.
True enough!!!
Bill SerGio wrote:
Microsoft has commented in the MSDN on this problem with BHOs and it has NEVER been fixed. I create a GUID that starts with {00001 or as LOW a value as I can which means it will be executed first. In many of my programs I go one step further and also REMOVE all of the other BHOs listed in the registry---with the user's permission and make sure that ONLY my BHO is listed in the registry while my program is running.
Actually what you are reffering to is a very specific case of BHO error regarding only Internet Explorer 5.00. Instances of Internet Explorer 4.* and IE5.01+,IE6.0+ etc, do not exhibit this problem. Your proposed solution however, is most unethical and disrespectful. Knowing that your BHO will only work on IE5 if it is the first one installed, you should NEVER disrespect another programmers work by making your GUID one number less!!! That is disrespectful and unethical! What you should do, is prompt the user to install a different version of Internet explorer that is capable of handling multiple BHO and let the user know that if they continue using IE5.00 then only one BHO will be installed and usable. Secondly, your proposed unethical solution, creates many potential problems when a user decides to remove your BHO from the registry manually. Using a GUID that varies, will create many potential problems when attempting to tell a user how to uninstall your software, hence a steady pre-known GUID should always be used. If the user decides not to upgrade their browser from IE5.01 (or to downgrade to IE4.x) then you prompt the user to uninstall all other BHO's and to not allow your BHO to be installed untill the user has either changed browsers or else uninstalled the remaining BHO on IE5.00 Ideally you should include a copy of IE5.01 or higher with your BHO making it easy for the user to use all installed BHO without having to play any unethical tricks, and without having to disrespect other programmers... Playing a "me first, no me first" kind of game with GUID's and BHO is what little children do in the lunch line at school. That is most UN-profressional behavior and should not be tolerated in any work environment. Your software should be programmed to be tolerant of other applications, otherwise you risk your software breaking when someone programs their object as you programmed yours, in addition you will find that consumers do not like being told what software will load on their computer and what will not. A profressional programmer would already know this... And I think there needs to be more respect paid to other programmers and their software instead of people playing a "me first" kindergarten style game with their "professional" software...
If you are not monitoring Internet Explorer or Windows explorer messages, then you are correct, you should launch your application perform the task and exit. However, you are monintoring the messages for example to detect DISPID_BEFORENAVIGATE2 so that before a user navigates to a page, you can check the url and stop them from veiwing the page, then making a seperate exe to do this, rather than the currently loaded BHO, is not going to make a difference because you will still have to monitor the messages rather it is from within IE\Windows Explorer or from wihout. The only real change is that instead of being mapped to IE memory space, you will be mapped to Windows memory space, and instead of being able to be notified, you will have monitor all messages from the application for the correct one.
Nothing is impossible, It's merely a matter of finding an answer to the question of HOW? ... And answering that question is usually the most difficult part of the job!!!
|
|
|
|
|
Hi Bill,
if you wrote LOTS of code like this, why didnt you post it to Codeproject and let us participate in your experience and knowledge? Apparently there are many programmers, how are interested in stuff like this. Take a look to the other postings...
Bye
Dirk
|
|
|
|
|
|
|
Hi Bill:
...I can rewrite your entire application in 15 minutes using MFC and create an exe that is 1/3 the size with far better performance by NOT making the exe a COM object itself which just slows down the sink...
If you are serious about your word, I'd like to see your 15 min. app posted here. I couldn't find anything from you at Code Project.
Are you just a big mouth?
|
|
|
|
|
This would be good if it came with some built in filters so one did not have to do them all himself. Do you have any of those laying around anywhere?
|
|
|
|
|
It's a good idea. But I have not built such filter for common use, sorry
|
|
|
|
|
What's this error all about?
error C2668: 'InlineIsEqualGUID' : ambiguous call to overloaded function
I'm sure I have the latest PSDK & WTL.
|
|
|
|
|
Darren Schroeder wrote:
error C2668: 'InlineIsEqualGUID' : ambiguous call to overloaded function
In the last several releases of PSDK, Microsoft has gone back and forth with some namespace issues regarding ATL. The upshot is that if your code uses the "using namespace ATL" statement, you end up with two versions of InlineIsEqualGUID: the one in the root namespace ::InlineIsEqualGUID and the one in the ATL namespace ATL::InlineIsEqualGUID. The compiler is complaining because it can't tell which context you are referring to (this is a problem with globally using a namespace). The solution is to explicitly tell the compiler which version you mean.
Replace InlineIsEqualGUID() with either ::InlineIsEqualGUID() or ATL::InlineIsEqualGUID() and you should be on your way. This is documented in a KB article, but that article is out of date and doesn't quite apply to all versions of PSDK.
Bomb our homes and threaten our children, and, as difficult as it is, we will still love you --- Martin Luther King, Jr.
|
|
|
|
|