Здравствуйте Gelfer, вы писали:

G>Пытаюсь получить текст иконок с рабочего стола.

G>------------------------------------------------------------
G>CWnd *ww=GetDesktopWindow()->FindWindow("ProgMan",NULL);
G> if (ww!=NULL)
G> {
G> ww=ww->GetWindow(GW_CHILD);
G> if (ww!=NULL)
G> {
G> ww=ww->GetWindow(GW_CHILD);
G> }
G> }
G> if (ww!=NULL)
G> {
G> int z=((CListCtrl*)ww)->GetItemCount();
G> char *tbf=new char[MAX_PATH];
G> LVITEM lv;
G> lv.iSubItem=0;
G> lv.pszText=tbf;
G> lv.cchTextMax=MAX_PATH;
G> for (int i=0;i<z;i++)
G> {
G> ww->SendMessage(LVM_GETITEMTEXT,i,(long)&lv);
G> //((CListCtrl*)ww)->GetItemText(i,0,tbf,MAX_PATH);
G>-------------------------------------------------
G>В случае выполнения SendMessage или GetItemText выдает ошибку в файле Comctrl32. Имя класса ww — SysListView32 (вроде правильно).
((CListCtrl*)ww)->>GetItemCount() возвращает правильное количество иконок на рабочем столе — 14.
G>Что я делаю неправильно ???
G>Зы: версия Windows — Windows Me (это имеет значение ???)

я думаю дело в различных адресных пространсвах десктопа и вашего приложения. WM_GETTEXT будет работать, ибо винды его отдельно обрабатывают, а LVM_GETITEMTEXT- нет, ибо в win16 его не было, а значит проблем с совместимостью тодже нет, и его специально не обрабатывают.

Так как эта тема тут поднималась не раз, вот цитата из Рихтера:

//Start of Quote


In this section, we'll examine how the system transfers data between processes using window messages. Some window messages specify the address of a block of memory in their lParam parameter. For example, the WM_SETTEXT message uses the lParam parameter as a pointer to a zero-terminated string that identifies the new text for the window. Consider the following call:

SendMessage(FindWindow(NULL, "Calculator"), WM_SETTEXT,
0, (LPARAM) "A Test Caption");




This call seems harmless enough—it determines the window handle of the Calculator application's window and attempts to change its caption to A Test Caption. But let's take a closer look at what happens here.

The string of the new title is contained in your process's address space. So the address of this string in your process space will be passed as the lParam parameter. When the window procedure for Calculator's window receives this message, it looks at the lParam parameter and attempts to manipulate what it thinks is a zero-terminated string in order to make it the new title.

But the address in lParam points to a string in your process's address space—not in Calculator's address space. This is a big problem because a memory access violation is sure to occur. But if you execute the line above, you'll see that it works successfully. How can this be?

The answer is that the system looks specifically for the WM_SETTEXT message and handles it differently from the way it handles most other messages. When you call SendMessage, the code in the function checks whether you are trying to send a WM_SETTEXT message. If you are, it packs the zero-terminated string from your address space into a memory-mapped file that it is going to share with the other process. Then it sends the message to the thread in the other process. When the receiving thread is ready to process the WM_SETTEXT message, it determines the location, in its own address space, of the shared memory-mapped file that contains a copy of the new window text. The lParam parameter is initialized to point to this address, and the WM_SETTEXT message is dispatched to the appropriate window procedure. After the message is processed, the memory-mapped file is destroyed. Boy, doesn't this seem like a lot of work?

Fortunately, most messages don't require this type of processing—it takes place only when an application sends interprocess messages. Special processing such as this has to be performed for any message whose wParam or lParam parameters represent a pointer to a data structure.

Let's look at another case that requires special handling by the system—the WM_GETTEXT message. Suppose your application contains the following code:

char szBuf[200];
SendMessage(FindWindow(NULL, "Calculator"), WM_GETTEXT,
sizeof(szBuf), (LPARAM) szBuf);


The WM_GETTEXT message requests that Calculator's window procedure fill the buffer pointed to by szBuf with the title of its window. When you send this message to a window in another process, the system must actually send two messages. First the system sends a WM_GETTEXTLENGTH message to the window. The window procedure responds by returning the number of characters required to hold the window's title. The system can use this count to create a memory-mapped file that will end up being shared between the two processes.

Once the memory-mapped file has been created, the system can send the WM_GETTEXT message to fill it. Then the system switches back to the process that called SendMessage in the first place, copies the data from the shared memory-mapped file into the buffer pointed to by szBuf, and returns from the call to SendMessage.

// End of quote



В общем, как мне кажется дело именно в этом....

Как обойти — см в Рихтере, там даже пример есть — придется внедрять длл и общаться с ней.


Саша.