Supressing a MessageBox
-
I am using a 3rd party component in my code and every time there's a particular error occurs in the execution of the component, instead of passing the error to the code that is running it (the component) the developers decided to just make a Message box show up!! It totally is inconsistent with my program and since my program runs in a loop, if the particular error occurs, the user gets an endless loop of messageboxes that are really hard to kill. You wind up having to go the task manager to stop my program, because you message boxes from the 3rd party component are "dialog" (or whatever it's called) so you have to click the button and don't have access to my program's window. Very bad programming ethics on their part. So, I was wondering if there is a way to suppress the messagebox from the 3rd party component? I don't have access to the components source either. /\ |_ E X E GG
-
I am using a 3rd party component in my code and every time there's a particular error occurs in the execution of the component, instead of passing the error to the code that is running it (the component) the developers decided to just make a Message box show up!! It totally is inconsistent with my program and since my program runs in a loop, if the particular error occurs, the user gets an endless loop of messageboxes that are really hard to kill. You wind up having to go the task manager to stop my program, because you message boxes from the 3rd party component are "dialog" (or whatever it's called) so you have to click the button and don't have access to my program's window. Very bad programming ethics on their part. So, I was wondering if there is a way to suppress the messagebox from the 3rd party component? I don't have access to the components source either. /\ |_ E X E GG
eggie5 wrote:
I was wondering if there is a way to suppress the messagebox from the 3rd party component?
I know this isn't the answer you're looking for, but I would seriously consider dumping the component. However, before I do that, I'd check the documentation for error suppression flags and confirm the message boxes aren't being shown because the component is running in unlicensed (demo) mode. /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
eggie5 wrote:
I was wondering if there is a way to suppress the messagebox from the 3rd party component?
I know this isn't the answer you're looking for, but I would seriously consider dumping the component. However, before I do that, I'd check the documentation for error suppression flags and confirm the message boxes aren't being shown because the component is running in unlicensed (demo) mode. /ravi My new year's resolution: 2048 x 1536 Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
I am using a 3rd party component in my code and every time there's a particular error occurs in the execution of the component, instead of passing the error to the code that is running it (the component) the developers decided to just make a Message box show up!! It totally is inconsistent with my program and since my program runs in a loop, if the particular error occurs, the user gets an endless loop of messageboxes that are really hard to kill. You wind up having to go the task manager to stop my program, because you message boxes from the 3rd party component are "dialog" (or whatever it's called) so you have to click the button and don't have access to my program's window. Very bad programming ethics on their part. So, I was wondering if there is a way to suppress the messagebox from the 3rd party component? I don't have access to the components source either. /\ |_ E X E GG
As Ravi suggested, I'd throw the component away and find another one (or develop it myself.) If you manage to kill this message box, you don't know if there are more hidden just waiting to pop up with your best customer. As to how you could kill it, a
WH_CBTWindows hook probably would do it.eggie5 wrote:
are "dialog" (or whatever it's called)
It's modal (disables parent window) and modeless (doesn´t disable parent window) :)
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
As Ravi suggested, I'd throw the component away and find another one (or develop it myself.) If you manage to kill this message box, you don't know if there are more hidden just waiting to pop up with your best customer. As to how you could kill it, a
WH_CBTWindows hook probably would do it.eggie5 wrote:
are "dialog" (or whatever it's called)
It's modal (disables parent window) and modeless (doesn´t disable parent window) :)
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Asking them devs to fix it would be best but Luis hooking will work or you can remove the message box dialogs completly by debugging the control and noping the calls to the dialog.
In any case (hooking or patching), there will be problems when a new version is released (most likely with patching.) Making the developers fix that probably would be hard, altough he can try. If a component-developing company allows that code to be released, I would expect great customer support. Altough I might be wrong.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Asking them devs to fix it would be best but Luis hooking will work or you can remove the message box dialogs completly by debugging the control and noping the calls to the dialog.
-
In any case (hooking or patching), there will be problems when a new version is released (most likely with patching.) Making the developers fix that probably would be hard, altough he can try. If a component-developing company allows that code to be released, I would expect great customer support. Altough I might be wrong.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Can you explain this "hooking or patching" process to me? I"m not quite sure what you mean... Also, this component will never be updated again. /\ |_ E X E GG
Patching is actually changing the code in the DLL. In you case, suppose you have somthing like this in machine-type pseudocode:
call DoSomething if error code != 0 go to error call DoSomethingBecauseNoError return error: call MessageBox("error!!") returnSuppose you find that code in the DLL and actually modify the file so that the insctruction
go to erroris changed to aNOP(which is an Intel x86 assembly language instruction that actually does nothing). The next time the DLL is loaded and executed, theDoSomethingBecauseNoErrorcall will always be executed, even if there was a previous error. That's patching: modifying some already-compiled code. I can also be useful in cracking programs. Suppose you have an app that calls a funcion to check whether it's registered or not. If you patch the beginning of that function (by changing the first instruction for areturn true) it will always seem as registered (that's what some cracks actually do.) Hooks are something totally different. A hook is a way to register your code so it's called before or after some other code, and it can optionally alter the normal behavior. In this case the original code is not modified, but the operating system or the code-to-be-called must provide a way to be hooked. Windows provides several types of hooks. One of them, theWH_CBThook, lets your hook procedure be called everytime the system is about to create a window, and you can prevent it from doing so. This way, you could see every window created, and if it's the specific message box, just prevent it. You can find more information in MSDN: About Hooks[^] CBTProc[^] Your hook procedure must reside in a DLL that will be loaded -
Patching is actually changing the code in the DLL. In you case, suppose you have somthing like this in machine-type pseudocode:
call DoSomething if error code != 0 go to error call DoSomethingBecauseNoError return error: call MessageBox("error!!") returnSuppose you find that code in the DLL and actually modify the file so that the insctruction
go to erroris changed to aNOP(which is an Intel x86 assembly language instruction that actually does nothing). The next time the DLL is loaded and executed, theDoSomethingBecauseNoErrorcall will always be executed, even if there was a previous error. That's patching: modifying some already-compiled code. I can also be useful in cracking programs. Suppose you have an app that calls a funcion to check whether it's registered or not. If you patch the beginning of that function (by changing the first instruction for areturn true) it will always seem as registered (that's what some cracks actually do.) Hooks are something totally different. A hook is a way to register your code so it's called before or after some other code, and it can optionally alter the normal behavior. In this case the original code is not modified, but the operating system or the code-to-be-called must provide a way to be hooked. Windows provides several types of hooks. One of them, theWH_CBThook, lets your hook procedure be called everytime the system is about to create a window, and you can prevent it from doing so. This way, you could see every window created, and if it's the specific message box, just prevent it. You can find more information in MSDN: About Hooks[^] CBTProc[^] Your hook procedure must reside in a DLL that will be loaded -
I don't have any of the source code, all I have is the DLL. Can I still do the patch/hack? /\ |_ E X E GG
Yes, that's the idea, without the source code. But it's not easy. You need to disassemble it, find the call to message box, find where you could put a NOP (not all assembly instructions are the same length), get the hexadecimal value of the NOP (it's called the opcode)... it's really not that easy. I would definitely try to find another component, and if not, I would probably use the hook technique. Patching is the last resort.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Yes, that's the idea, without the source code. But it's not easy. You need to disassemble it, find the call to message box, find where you could put a NOP (not all assembly instructions are the same length), get the hexadecimal value of the NOP (it's called the opcode)... it's really not that easy. I would definitely try to find another component, and if not, I would probably use the hook technique. Patching is the last resort.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Can you recommend a disassembler to use? I would like to mess around with this. /\ |_ E X E GG
You'll have to search for one in google. I've not used one in years. I remember using one called WDASM32, but I don't know if it still exists. On a side note, I always wanted to write one myself (interesting project) but never did it. Now that I work for a living, I just don't have time.
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
can you explain more to me what you mean by
cnich23 wrote:
debugging the control and noping the calls to the dialog.
??? Can I do this if I don't have access to the source? /\ |_ E X E GG
There is no real easy way to explain this. Either you need to know your machine ASM or if the control is .NET you need to know IL. There are several .NET Dissasmblers some even let you edit the IL code directly. Which in your case you can search for MessageBox and remove them. But there is no easyway to explain this, and most likely it will involve a lot mroe research then waht your trying to accomplish. Best bet is to have the dev's fix it or learn .NET reversing.