Querying information from an Explorer window

re: Querying information from an Explorer window

Dr. Jekyll — Tue, 20 Jul 2004 14:28:00 GMT

If everything is so nicely scoped, why not use CComPtr<>s / CComQIPtr<>s ? This very same code would be so much more readable (no ugly QueryInterfaces, Releases, uninitialized variables)...

Guess it's a habit thing.

re: Querying information from an Explorer window

Raymond Chen — Tue, 20 Jul 2004 14:35:00 GMT

I try to avoid using any extra libraries in these articles. If you like those libraries, you can translate raw C++ into your library; but it's harder for others to translate a library into raw C++. (For example, I could've used a library to auto-free the pidlFolder, but that would have confused anybody who wasn't familiar with that library.)

re: Querying information from an Explorer window

A. Reader — Tue, 20 Jul 2004 14:37:00 GMT

Hideous. That screams "potential memory leaks!"

re: Querying information from an Explorer window

Ben Cooke — Tue, 20 Jul 2004 15:17:00 GMT

That code is hilarious. It's stuff like that which really puts me off learning about COM. Fortunately, I've managed to basically ignore COM so far, and if all this .NET stuff becomes popular maybe I can just pretend it never happened. :)

Pleaaase release me, let me gooooooo......

re: Querying information from an Explorer window

Jack Mathews — Tue, 20 Jul 2004 15:30:00 GMT

Well, you could easily flatten out that code with a CComPtr class, a CComMemoryHandle class, and a function called GuaranteeSuccess that throws an exception on a bad HRESULT and catch that in the function.

re: Querying information from an Explorer window

Raymond Chen — Tue, 20 Jul 2004 15:44:00 GMT

Any reader who wants to make an ATL version of this function is free to do so. It would probably be a lot prettier. But I write in pure C++ in order to avoid arguing over which template library is best.

re: Querying information from an Explorer window

dude — Tue, 20 Jul 2004 15:51:00 GMT

cant compile : error C2065: 'StrRetToBuf' : undeclared identifier

re: Querying information from an Explorer window

Ben Hutchings — Tue, 20 Jul 2004 16:39:00 GMT

Does Explorer lock windows that external clients are looking at (or indeed <em>all</em> of them while the windows are being enumerated) or is this code vulnerable to race conditions?

re: Querying information from an Explorer window

Michael — Tue, 20 Jul 2004 16:54:00 GMT

>I try to avoid using any extra libraries in these articles. <

I for one am glad you approach your problems this way. It shows me what is "really going on". Keep up the good work!!

re: Querying information from an Explorer window

Cedric Beust — Tue, 20 Jul 2004 17:27:00 GMT

I believe the only point you've made is that only VB or C# should ever be used to access COM :-)

--
Cedric

re: Querying information from an Explorer window

drebin — Tue, 20 Jul 2004 17:47:00 GMT

I have a burning sensation in my eyes, is that normal??

re: Querying information from an Explorer window

Zachary Turner — Tue, 20 Jul 2004 18:51:00 GMT

Even in pure C++, better to just stick a label at the bottom and have a goto statement if the COM call fails, rather than use deeper nesting if the call succeeds.

To the poster who said it's things like that make you not want to learn COM, it's very simple and easy to read as long as you provide an appropriate framework for making it easy to read. For example, consider the following two macros:

#define COM_CALL(pfn, lbl) \
if (FAILED(pfn)) goto lbl;

#define RELEASE(ptr) \
if (ptr) ptr->Release();

Now the RecalcText function is as follows:

void CALLBACK RecalcText(HWND hwnd, UINT, UINT_PTR, DWORD)
{
HWND hwndFind = GetForegroundWindow();
g_szPath[0] = TEXT('\0');
g_szItem[0] = TEXT('\0');

IShellWindows *psw;
COM_CALL(CoCreateInstance(CLSID_ShellWindows, NULL, CLSCTX_ALL, IID_IShellWindows, (void**)&psw), finish);

VARIANT v;
V_VT(&v) = VT_I4;
IDispatch *pdisp;
BOOL fFound = FALSE;
for (V_I4(&v) = 0; !fFound && psw->Item(v, &pdisp) == S_OK; V_I4(&v)++)
{

}

IWebBrowserApp *pwba = NULL;
IServiceProvider *psp = NULL;
IShellBrowser *psb = NULL;
IShellView *psv = NULL;
IFolderView *pfv = NULL;
IPersistFolder2 *ppf2 = NULL;
LPITEMIDLIST pidlFolder = NULL;
LPITEMIDLIST pidlItem = NULL;
IShellFolder *psf = NULL;
STRRET str;
COM_CALL(pdisp->QueryInterface(IID_IWebBrowserApp, (void**)&pwba), finish);
if (hwndWBA != hwndFind)
goto finish;
COM_CALL(pwba->QueryInterface(IID_IServiceProvider, (void**)&psp), finish);
COM_CALL(psp->QueryService(SID_STopLevelBrowser, IID_IShellBrowser, (void**)&psb), finish);
COM_CALL(psb->QueryActiveShellView(&psv), finish);
COM_CALL(psv->QueryInterface(IID_IFolderView, (void**)&pfv), finish);
COM_CALL(pfv->GetFolder(IID_IPersistFolder2, (void**)&ppf2), finish);
COM_CALL(ppf2->GetCurFolder(&pidlFolder), finish);

if (!SHGetPathFromIDList(pidlFolder, g_szPath))
lstrcpyn(g_szPath, TEXT("<not a directory>"), MAX_PATH);

int iFocus;
COM_CALL(pfv->GetFocusedItem(&iFocus), finish);
COM_CALL(pfv->Item(iFocus, &pidlItem), finish);
COM_CALL(ppf2->QueryInterface(IID_IShellFolder, (void**)&psf), finish);
COM_CALL(psf->GetDisplayNameOf(pidlItem, SHGDN_INFOLDER, &str), finish);
StrRetToBuf(&str, pidlItem, g_szItem, MAX_PATH);

finish:
RELEASE(psf);
TASK_FREE(pidlItem);
TASK_FREE(pidlFolder);
RELEASE(ppf2);
RELEASE(pfv);
RELEASE(psv);
RELEASE(psb);
RELEASE(psp);
RELEASE(pwba);
RELEASE(pdisp);
RELEASE(psw);

InvalidateRect(hwnd, NULL, TRUE);
}

I probably introduced a few bugs here, but I just typed this in notepad and didn't bother compiling. The point is obvious, just change the logic flow and COM is much easier to follow. Don't listen to what they say, that you should "never" use goto statements.

re: Querying information from an Explorer window

Larry Osterman — Tue, 20 Jul 2004 19:55:00 GMT

Never use goto statements? I LOVE goto statements :)

re: Querying information from an Explorer window

Jack Mathews — Tue, 20 Jul 2004 20:05:00 GMT

Zach: Ummm, except now you can't use C++ construction/destruction semantics with yoru code...

re: Querying information from an Explorer window

Nicole DesRosiers — Tue, 20 Jul 2004 20:14:00 GMT

Having had to actually code up a program using a raw dispatch interface in C++, I really appreciate that you wrote this example without libraries. When I was trying to design my program I nearly tore my hair out trying to translate the things written on MSDN with the wrapper code into raw function calls that were actually useful to me.

re: Querying information from an Explorer window

MadHungarian :) — Tue, 20 Jul 2004 21:23:00 GMT

The thing that bugs me is the use of Hungarian notation. 'psf' doesn't say much, 'shellFolder' does.

re: Querying information from an Explorer window

Raymond Chen — Tue, 20 Jul 2004 21:39:00 GMT

Zachary: Note however that some of your code goto's over variable initialization - for example if the initial CoCreateInstance fails. This results in the RELEASE trying to use an uninitialized variable.

re: Querying information from an Explorer window

Joe — Tue, 20 Jul 2004 22:49:00 GMT

Zachary, you have to make sure that when you make macros you take care to write them correctly. For instance, this hypothetical code is wrong:
if(--i == 0) // we have no more use for the object
RELEASE(pObj);
else
COM_CALL(pObj->foo(), finish);

First, because the RELEASE() macro has a semi-colon, you end up with two semi-colons and that'll terminate the if statement before the else. If you remove the extra semi-colon, then the else clause gets attached to the if statement in the macro, and not the if(--i == 0).

I think the usual way of handling this is to use:
#define RELEASE(ptr) \
if (ptr) ptr->Release(); else

So that the semi-colon at the end of RELEASE(foo); will close the else.

re: Querying information from an Explorer window

Jack Mathews — Tue, 20 Jul 2004 23:35:00 GMT

Or instead of a macro, you use something like a CComPtr, and to fix the nesting, you do like this:

enum EBadResult
{
kBadResult
};

void Succeed( HRESULT hr )
{
if ( !SUCCEEDED(hr) )
{
throw kBadResult;
}
}

... then in your code, you can simply do ...

try
{
Object obj;

Succeed( incoming->DoThis( obj.GetPtrPtr() ) );
Succeed( obj->DoThisNow() );
}
catch ( EBadResult )
{
// Do what you need to in order to fail
}

... and you will get automatic destruction of the intermediate objects that you didn't use. You write a small amount more code, you get similar ease of use as goto, and much MUCH more robust error handling in the language.

re: Querying information from an Explorer window

John Schroedl — Wed, 21 Jul 2004 01:25:00 GMT

Great post. Keep 'em coming with more good stuff for the shell!

re: Querying information from an Explorer window

Steven Engelhardt — Wed, 21 Jul 2004 03:25:00 GMT

For writing anything but the simplest macros, I typically recommend enclosing in a do { ... } while(0) block as follows:

#define DoStuff() \
do { \
// statement 1; \
// statement 2; \
// ...; \
} while (0)

The if (...) else trick should work as well.

I also explained my C/C++ error-handling style which uses gotos, along with its limitations, in:

http://www.livejournal.com/users/sengelha/35640.html
http://www.livejournal.com/users/sengelha/37087.html
http://www.livejournal.com/users/sengelha/37182.html

re: Querying information from an Explorer window

Tim Robinson — Wed, 21 Jul 2004 09:30:00 GMT

> I try to avoid using any extra libraries in these articles.

Even the Microsoft C++ runtime library includes COM support classes. For most Windows developers, that's hardly an 'extra library'.

re: Querying information from an Explorer window

Stewart Tootill — Wed, 21 Jul 2004 13:05:00 GMT

I tend to use the exception concept and ATL com smart pointers. I know the example wasn't written in ATL, but even if thats the only ATL functionality you use its worth it in my opinion.

As for the macro, I typically use

inline HRESULT TestComCall( HRESULT hr ) throw (_com_error)
{
if ( FAILED( hr ) )
_com_issue_error( hr );
return hr;
}

it returns hr so you can use it with the Next method on IEnum interfaces. You can replace the _com_error with your favourite exception. Also its a shame, but the microsoft compiler whinges about the exception specification.

re: Querying information from an Explorer window

Tudor Tihan — Wed, 21 Jul 2004 14:31:00 GMT

Hy,

Is there any way to similarly get a handle of the text inputs in the Internet Explorer ?

If it could be a write-only way (for setting texts inside) that would be great, because it would mean that I could write a program to fill my credentials on my visited sites without sharing them with password manager and such.

So, is it possible?
Could you give me some guidelines, please, as I am new to advanced COM programming.

Thank you!

re: Querying information from an Explorer window

Raymond Chen — Wed, 21 Jul 2004 14:43:00 GMT

mshtml.h contains the interfaces you need. I leave filling in the details as an exercise. (Besides, this is an IE question and that's not my area.)

re: Querying information from an Explorer window

Michael Geary — Wed, 21 Jul 2004 16:48:00 GMT

Steve, I'm curious about the use of do...while(0) in your macro. I've written scads of multiline code macros, and all I ever do is enclose them in braces. So your example would be:

#define DoStuff() \
{ \
// statement 1; \
// statement 2; \
// ...; \
}

Is there a situation where that would fail and do...while(0) would fix it?

re: Querying information from an Explorer window

Steven Engelhardt — Wed, 21 Jul 2004 18:32:00 GMT

Michael Geary: The #define DoStuff() { ... } style works in most cases but not all. See http://www.livejournal.com/users/sengelha/38124.html for details.

re: Querying information from an Explorer window

Zachary Turner — Wed, 21 Jul 2004 18:36:00 GMT

Well as I said, I typed it in notepad and didn't compile anything ;-) The point was just to illustrate a general concept, which when applied would simplify readability. Thanks for pointing out the errors though. To respond to the individual comments (I'm sure everyone knows everything I'm about to say, but I might as well say it anyway for the sake of completeness):

Raymond: Skipping over variable initialization is easily handled by moving all declarations and setting them equal to 0. The release macro checks whether or not the value of the pointer is 0, and if it is it does nothing. So you never release garbage that way. Obviously you know that already, but like I said just pointing it out for completeness' sake.

Jack: Are you referring to construction/destruction semantics with regards to COM smart pointers auto add-refing and releasing? You can use whatever you want, this was just an attempt to simplify readability in a way that didn't use any smart pointer template library, which was Raymond's initial goal as well. Since some readers said "it sucks, you can't read it without smart pointers", I was just providing a way by which you could ;-)

Joe: Good point, thanks :)

Jack (2nd message): Raymond's original goal was specifically NOT to use any library such as that, so that people didn't have to argue over which template library was best.

Michael: Yes, the do while macro allows you to put a semicolon at the end Consider your macro to be called DOMICHAEL, and steve's to be called DOSTEVE. Now consider the following code:

if (1)
DOMIKE();
else
DOSTEVE();

if (1)
DOSTEVE();
else
DOMIKE();

The first if/else block generates a compiler error, because a ; after DOMIKE() terminates the if block, as Joe pointed out earlier. The second if block does NOT generate a compiler error, however, as you are required to put a ; to terminate the do while.

That's the only difference that I see. This only applies for single line if blocks as well, if you already had enclosing braces for the if block there would be no difference.

The old goto problem

Otaku, Cedric's weblog — Wed, 21 Jul 2004 21:46:00 GMT

I was once reminded of the constant controversy that surrounds the use of goto by the two following posts: Raymond Chen's article on a COM trick to track the Explorer...

re: Querying information from an Explorer window

Michael Moore — Wed, 21 Jul 2004 20:12:00 GMT

Seems to me you might as well stick with the simple braces method since a do { ... } while (0) approach also results in a syntax error if you leave off the semicolon.

i.e. this won't compile either:

if ( expression )
do { a(); b(); } while (0)
else
c();

so its really just a question of whether you think semicolon's should be used to terminate macro usage.

I'll grant you the lack of a semicolon is a bit more obvious a syntax error for the macro than a mismatched else.

-Michael

re: Querying information from an Explorer window

Michael Geary — Thu, 22 Jul 2004 00:22:00 GMT

Stephen and Zachary, many thanks for the explanation on the do...while(0) bit. All makes sense now, and I'll start doing my own macros that way.

Michael M., when I write a code macro like this, I like to do it in such a way that I can use the semicolon when I use the macro. The idea is that the code that calls the macro should look the same whether it's a macro or a function.

Taking a simpler example, I would write a macro like this:

#define DoStuff() CallSomething()

and not like this:

#define DoStuff() CallSomething();

because when I call DoStuff, I want to call it like this:

DoStuff();

and not like this:

DoStuff()

The latter style means that the caller has to know it's a macro, which I wouldn't want.

re: Querying information from an Explorer window

Raymond Chen — Thu, 22 Jul 2004 00:57:00 GMT

The semicolon-less style also messes up most code auto-formatters / syntax colorers.

re: Querying information from an Explorer window

sir — Thu, 22 Jul 2004 05:52:00 GMT

buncha jealous heytah's ;-)

re: Querying information from an Explorer window

Kyle Lahnakoski — Thu, 22 Jul 2004 16:07:00 GMT

Looks like this turned into a discussion about code readability and the use of gotos.

Gotos are not good, but suggest the need for better error handling than the inadequate try-catch semantics. I suggest Structured Cascaded Exception Handling solves this problem and should be adopted in the next generation of languages.

re: Querying information from an Explorer window

Steve Donie — Fri, 23 Jul 2004 04:52:00 GMT

You forgot to mention the Accessibilty Interfaces! Go straight to the focused item, get notified when it changes rather than polling...

Run the magnifier (Start->Programs->Accessories->Accessibility->Magnifier) or Narrator (same place) to see what those can do. Then see http://microsoft.com/enable/ for a ling to the developer docs.

Kind of cool

crashBlog — Sun, 09 Jan 2005 22:40:00 GMT

Using script to query information from Internet Explorer windows

The Old New Thing — Tue, 05 Jul 2005 17:00:09 GMT

The ShellWindows object was designed for scripting.