Its just like garbage collection!
-
Sorry but I just need to rant.
A fellow coworker was having some issues with a com object. We have several executables (a slightly different wtf) and a couple of dlls in the project. He looked around and noticed that all of the executables and all but one of the dlls have CoInitialize and CoUnitialize in them.
Of course the one dll he is having a problem with is the one that doesn't have CoInit/CoUninit in them. He puts 2 and 2 together and decides that must be the problem. He sends mail to the dev team asking why this particular dll doesn't have CoInit in it.
This particular dll happens to be a com object itself and doesn't need Com to be intialized. See the dll won't be called unless the caller initializes com first I explained.
His response was something along the lines of he was going to add CoInit and CoUninit so we know when we do not reference com directly.
I told him that his problem was not with CoInit, as calling it a second time wouldn't do anything. And despite the fact that there is no real harm in calling CoInit I am pretty sure he would write the code improperly, so I really didn't want him to add the calls.
He said he was going to add CoInit in the constructor and CoUninit wherever it is need! Do think its ok?
I told him, no its not ok, please don't add it.
A little bit later he tells me he has checked the code in, and I can review it if I wanted to, as apparently it solved his problems.
He added about 4 lines of code. In the ComObject Activate method he added:
HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
if( hr != S_OK && hr != S_FALSE ){
CoUninitialize();
hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
}In the DestroyWindow of the window we create he the CoUninit call.
Immediately I told him the code was broken in at least two ways, so please remove the calls. Since I was making changes in the file I removed the code, and checked in.
The next day we had a two hour "conversation." It basically involved me telling him what CoInit does (in this case not much) and him telling me what he THINKS it does. "It is like C# and garbage collection" And we have to make sure that Com is initialized because other calls might silently fail. And we have to make sure it is the concurrency we want it to be.
I finally gave up, he thought he knew what it did, and I wasn't able to convince him otherwise. I go back to my office and debug the code. The reason he wanted to call CoUninit was because a com object we were using wasn't being unloaded (until you reboot the machine he exclaimed) Turns out his code in one case didn't bother to release a pointer to the object, and in another case called DestroyWindow on the parent window. The parent window belonged to the code that instatiated us. Apparently destroying their window prevented them from unitializing com. Once I fixed these two bugs, everything was working hunky dory. Or so I thought.
I explained the bug to my esteemed colleague, and he said "well I guess I didn't know what coinit was doing!" The next day I am skimming through the bugs and I noticed he added some comments to a bug. The comment was "this looks to be caused by the removal of CoInit and CoUninit from the code!" Never mind the fact that his CoInit/CoUninit never actually made it into a build. He believes he is unable to talk to this other com object. When he is talking to it just fine, the other com object is returning an error. Turns out the REAL that he has been trying solve this, is actually a bug in this other com object. And apparently he believes the only fix is for us to call CoUninit.
-
yawn
-
Well, I hope that feels better off your chest.
Sometimes people can't be told. Nothing new, but I feel your frustration.
I once had a mid-level programmer, after I gave him the spec, keep asking me if it woudn't be better (simpler) to do it {x} way. I explained no, there were detailed (documented) reasons why that wouldn't work, and how it had to be done {y} otherwise it would fail with {z} errors. 1 Week later, same conversation. Immediately after the check in (i.e. before I could possibly have reviewed it), {z} starts happening. Of course, he had written {x}, as he felt it would be simpler. Never mind that it doesn't meet the spec, and causes an issue that we had predicted and deliberately designed around! Sometimes it is easier to code it all yourself...
He left shortly after, but not by my doing.
-
Unskilled and Unaware
[quote user="chrismcb"]
I finally gave up, he thought he knew what it did, and I wasn't able to convince him otherwise.
[/quote]
And the problem is...he is Unskilled and Unaware of it. All too common of a problem, and may or may not be their own doing. Perhaps he always wanted to be a programmer and didn't know he was a dolt, or maybe he got moved up the food chain and ended up a programmer. Who knows. All you can say is that he's an idiot and doesn't realize it. Arguably one of the most frustrating situations in the world; I feel your pain.
As part of my web development, I work with managers in several different departments, all of whom have their own little corner of our site. One in particular is the first to admit that she knows nothing about "the web" (living an environmentalists lifestyle helps, I'm sure). Yet, she repeatedly implies that she knows what the website should look/work like and what is capable of being done, usually implying that it can't be done because I don't know how. If I had a dollar for every person who didn't believe that I had a clue...I wouldn't have to deal with them anymore. Go figure, she also suffers from a similar problem: she believes her work has more impact than others' and should be given greater importance; enough so that she repeatedly goes above the entire division to get what she wants.
You should leave a sign on the side of his cubicle: <font class="sqq">“Meddle not in the affairs of the dragon; for you are crunchy and taste good with ketchup.”</font>
-
For a second I thought it said he was having problems with a corn object. And I really didn't want to know anything further thank you...
:-D
