Ich möchte gerne u.a. die Icon-Positionen des Desktops auslesen können und
bin zur Ermittlung des Desktop-Handles auf die beiden folgenden
Code-Beispiele gestoßen:

hDesk = FindWindow("progman", vbNullString)
hDesk = FindWindowEx(hDesk, 0, "SHELLDLL_DefView", vbNullString)
hDesk = FindWindowEx(hDesk, 0, "SysListView32", "FolderView")

hDesk = FindWindow("progman", "Program Manager")
hDesk = GetWindow(hDesk, GW_CHILD)
hDesk = GetWindow(hDesk, GW_CHILD)

In beiden Beispielen geht der jeweils 2. Aufruf schief und liefert null
zurück.
Andere Aufrufe von FindWindow bzw. FindWindowEx in meinem Programm
funktionieren dagegegen.

Was kann da falsch sein?

Am 11.04.2024 um 19:03 schrieb Wendelin Uez:
> Ich möchte gerne u.a. die Icon-Positionen des Desktops auslesen können
> und bin zur Ermittlung des Desktop-Handles auf die beiden folgenden
> Code-Beispiele gestoßen:
>
>    hDesk = FindWindow("progman", vbNullString)
>    hDesk = FindWindowEx(hDesk, 0, "SHELLDLL_DefView", vbNullString)
>    hDesk = FindWindowEx(hDesk, 0, "SysListView32", "FolderView")
>
>
>    hDesk = FindWindow("progman", "Program Manager")
>    hDesk = GetWindow(hDesk, GW_CHILD)
>    hDesk = GetWindow(hDesk, GW_CHILD)
>
> In beiden Beispielen geht der jeweils 2. Aufruf schief und liefert null
> zurück.
> Andere Aufrufe von FindWindow bzw. FindWindowEx in meinem Programm
> funktionieren dagegegen.
>
> Was kann da falsch sein?

hProgman = FindWindow("Progman", "Program Manager")
hDesktop = GetWindow(GetWindow(hProgman, GW_CHILD), GW_CHILD)

"Klaus Ketelaer" <usenet@ketelaer.de> schrieb im Newsbeitrag
news:uv99e1$f2b3$1@solani.org...
> Am 11.04.2024 um 19:03 schrieb Wendelin Uez:
>> Ich möchte gerne u.a. die Icon-Positionen des Desktops auslesen können
>> und bin zur Ermittlung des Desktop-Handles auf die beiden folgenden
>> Code-Beispiele gestoßen:
>>
>> hDesk = FindWindow("progman", vbNullString)
>> hDesk = FindWindowEx(hDesk, 0, "SHELLDLL_DefView", vbNullString)
>> hDesk = FindWindowEx(hDesk, 0, "SysListView32", "FolderView")
>>
>>
>> hDesk = FindWindow("progman", "Program Manager")
>> hDesk = GetWindow(hDesk, GW_CHILD)
>> hDesk = GetWindow(hDesk, GW_CHILD)
>>
>> In beiden Beispielen geht der jeweils 2. Aufruf schief und liefert null
>> zurück.
>> Andere Aufrufe von FindWindow bzw. FindWindowEx in meinem Programm
>> funktionieren dagegegen.
>>
>> Was kann da falsch sein?
>
> hProgman = FindWindow("Progman", "Program Manager")
> hDesktop = GetWindow(GetWindow(hProgman, GW_CHILD), GW_CHILD)

Das ist praktisch identisch mit dem zweiten Codeblock, und deshalb kommt
bei mir ebenfalls hDesktop = 0 heraus.

Wenn's nicht an dem Code liegt, woran aber dann? Meine IDE läuft zwar unter
WIN8.1, aber das sollte doch hier keinen Unterschied machen?

Am 12.04.2024 um 11:54 schrieb Wendelin Uez:
>
> "Klaus Ketelaer" <usenet@ketelaer.de> schrieb im Newsbeitrag
[...]
>>> Was kann da falsch sein?
>>
>> hProgman = FindWindow("Progman", "Program Manager")
>> hDesktop = GetWindow(GetWindow(hProgman, GW_CHILD), GW_CHILD)
>
> Das ist praktisch identisch mit dem  zweiten Codeblock, und deshalb
> kommt bei mir ebenfalls hDesktop = 0 heraus.
>
> Wenn's nicht an dem Code liegt, woran aber dann? Meine IDE läuft zwar
> unter WIN8.1, aber das sollte doch hier keinen Unterschied machen?

Api-Funktionen werden von Windows ausgeführt und nicht von der IDE.

Mein Code liefert für alle Windows-Versionen von XP bis 10 das
korrekte Handle zurück. Also kann es bestenfalls noch an den
Api-Deklarationen liegen.

Private Declare Function FindWindow Lib "user32" Alias "FindWindowA"
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long
Private Declare Function GetWindow Lib "user32" (ByVal hwnd As Long,
ByVal wCmd As Long) As Long

Private Const GW_OWNER As Long = 4
Private Const GW_CHILD As Long = 5

>> Wenn's nicht an dem Code liegt, woran aber dann? Meine IDE läuft zwar
>> unter WIN8.1, aber das sollte doch hier keinen Unterschied machen?
>
> Api-Funktionen werden von Windows ausgeführt und nicht von der IDE.

Weshalb ich auf WIN8.1 hinwies - es könnte ja sein, daß sich da was geändert
hat.

> Mein Code liefert für alle Windows-Versionen von XP bis 10 das
> korrekte Handle zurück. Also kann es bestenfalls noch an den
> Api-Deklarationen liegen.

Das habe ich natürlich überprüft und sogar jetzt eine Kopie deiner
Deklaration per copy & paste tippfehlerfrei in meine Testroutine übernommen:

> Private Declare Function FindWindow Lib "user32" Alias "FindWindowA"
> (ByVal lpClassName As String, ByVal lpWindowName As String) As Long
> Private Declare Function GetWindow Lib "user32" (ByVal hwnd As Long, ByVal
> wCmd As Long) As Long
>
> Private Const GW_OWNER As Long = 4
> Private Const GW_CHILD As Long = 5

Leider mit exakt dem selben unerklärlichen Ergebnis.

Ich habe sogar ein neues Standard-Projekt ohne sonstigen Code angelegt, nur
mit diesen beiden Declares und der GW_CHILD-Konstante, sowie die beiden
Codezeilen
hProgman = ...
hDesk = ....
plus einer Zeile "MsgBox hDesk"

Ergebnis leider immer noch hDesk=0.

Ich habe dann ein Exe drau gemacht und auf einem anderen WIN8.1Rechner
laufen lassen. Ergebnis wieder null.

Dann das Exe auf einem WIN 10 Rechner. Ergebnis wunderbar wie gewünscht.

Also dürfte es doch etwas mit WIN8.1/WIN10 zu tun haben. Bloß was???

Am 12.04.2024 um 19:31 schrieb Wendelin Uez:

Was sagt den GetLastError?

Am 12.04.2024 um 20:42 schrieb Klaus Ketelaer:
> Am 12.04.2024 um 19:31 schrieb Wendelin Uez:
>
> Was sagt den GetLastError?

Normalerweise ist die Function in der User32.dll. Laut Doku
der Function gibt es da noch eine

ext-ms-win-ntuser-window-l1-1-0 (eingeführt in Windows 8)

Vielleicht hängt es damit zusammen... Einfach mal die
Doku lesen...

Hallo Wendelin,

Am 11.04.2024 um 19:03 schrieb Wendelin Uez:
> Ich möchte gerne u.a. die Icon-Positionen des Desktops auslesen

das müßte man auch relativ einfach per UIAutomation lösen können. Da
sparst du dir die Windows API Aufrufe und über die COM Schnittstelle
läßt sich das einfach in VBA einbinden.

Die Icons sind einfach die Childs von "Desktop"(SysListView32) unterhalb
von "Program Manager" (Program). Die ClassNames in Klammern.

Das läßt sich innerhalb der UIAutomation einfach adressieren und
durchlaufen.Schau mal hiernach einer Helper-Classe:
https://github.com/mhumpher/UIAutomation_VBA/blob/master/UIA_Wrapper.cls

und dann interessiert dich die Property "BoundingRectangle".

Ein wichtiges Tool ist Inspect.exe, womit du dir alle Daten anzeigen
lassen kannst.

Gruß Ulrich

Am 12.04.2024 um 21:53 schrieb Ulrich Möller:
> Hallo Wendelin,
Hallo Ulrich

> Am 11.04.2024 um 19:03 schrieb Wendelin Uez:
>> Ich möchte gerne u.a. die Icon-Positionen des Desktops auslesen
>
> das müßte man auch relativ einfach per UIAutomation lösen können. Da
> sparst du dir die Windows API Aufrufe und über die COM Schnittstelle
> läßt sich das einfach in VBA einbinden.
>
> Die Icons sind einfach die Childs von "Desktop"(SysListView32) unterhalb
> von "Program Manager" (Program). Die ClassNames in Klammern.
>
> Das läßt sich innerhalb der UIAutomation einfach adressieren und
> durchlaufen.Schau mal hiernach einer Helper-Classe:
> https://github.com/mhumpher/UIAutomation_VBA/blob/master/UIA_Wrapper.cls
>
> und dann interessiert dich die Property "BoundingRectangle".
>
> Ein wichtiges Tool ist Inspect.exe, womit du dir alle Daten anzeigen
> lassen kannst.

Wenn das System ein kaputtes Handle zurück liefert, dann muss
man sich darum kümmern, besonders wenn es sich um ein eminent
wichtiges Handle handelt.

Mal abgesehen davon, dass es viele (bessere) Möglichkeiten gibt,
die auf dem Desktop/Program abgelegten Icons zu ermitteln;

Wenn ich eine Fensterliste brauche, dann nutze ich ein paar
Zeilchen eigenen Code, wie z.B.

hWnd = GetWindow(GetDesktopWindow(), GW_HWNDFIRST)
Do
...
hWnd = GetWindow(hWnd, GW_HWNDNEXT)
Loop Until hWnd = 0

Das geht jedoch nur, wenn ich keine kaputten Handles vom System
zurück bekomme. Darum hat das Priorität.

Statt dessen etwas einzubinden, bei dem bereits die Requirements
bei mir eine Panikattacke auslösen halte ich für suboptimal.

' Requirements:
' UIAuotmationClient (UIAutomationCore.dll) (this is the core UI dll)
' Microsoft Scripting Runtime (scrrun.dll) (this is mainly for using
dictionaries)
' AutoItX3 1.0 Type Library (AutoItX3.dll) (additional automation
capabilities)
' Miscrosoft VBScript Regular Expression (vbscript.dll\3)

Zudem: VBA != VB...

Gruß Klaus

> Was sagt den GetLastError?

null

> Wenn ich eine Fensterliste brauche, dann nutze ich ein paar
> Zeilchen eigenen Code, wie z.B.
>
> hWnd = GetWindow(GetDesktopWindow(), GW_HWNDFIRST)
> Do
> ...
> hWnd = GetWindow(hWnd, GW_HWNDNEXT)
> Loop Until hWnd = 0
>
> Das geht jedoch nur, wenn ich keine kaputten Handles vom System
> zurück bekomme. Darum hat das Priorität.

Habe ich jetzt auch probiert und die Aufrufe entzerrt:
GetDesktopWindow() liefert noch ein Handle, aber GW_HWNDFIRST schon nicht
mehr und trotzdem mit GetLastError=0

Hallo Klaus,

Am 13.04.2024 um 10:30 schrieb Klaus Ketelaer:
> Statt dessen etwas einzubinden, bei dem bereits die Requirements
> bei mir eine Panikattacke auslösen halte ich für suboptimal.
>
> ' Requirements:
> ' UIAuotmationClient (UIAutomationCore.dll) (this is the core UI dll)

Es wird lediglich die UIAutomationCore.dll benötigt und hierbei ist es
egal, ob VBA oder VB. Ich habe das letztens in einer MS Access
verwendet. Es ist einfach zu handhaben und macht genau das, was es soll.

Da UIAutomation auch von den Tools für Barrierefreiheit verwendet wird,
sollte es auch stabil sein.

Am 13.04.2024 um 11:04 schrieb Wendelin Uez:
>
>> Wenn ich eine Fensterliste brauche, dann nutze ich ein paar
>> Zeilchen eigenen Code, wie z.B.
>>
>> hWnd = GetWindow(GetDesktopWindow(), GW_HWNDFIRST)
>> Do
>>   ...
>>   hWnd = GetWindow(hWnd, GW_HWNDNEXT)
>> Loop Until hWnd = 0
>>
>> Das geht jedoch nur, wenn ich keine kaputten Handles vom System
>> zurück bekomme. Darum hat das Priorität.
>
> Habe ich jetzt auch probiert und die Aufrufe entzerrt:
> GetDesktopWindow() liefert noch ein Handle, aber GW_HWNDFIRST schon
> nicht mehr und trotzdem  mit GetLastError=0
>

Wie das Leben so spielt. Manchmal findet man nichts, und
das ist dann auch kein Fehler.

Hier sollte man schon eher etwas finden, denn die Desktop-Icons
liegen auf dem Program...

Private Declare Function GetWindow Lib "user32" (ByVal hwnd As Long,
ByVal wCmd As Long) As Long
Private Declare Function FindWindow Lib "user32" Alias "FindWindowA"
(ByVal lpClassName As String, ByVal lpWindowName As String) As Long

Private Const GW_HWNDFIRST = 0
Private Const GW_HWNDNEXT = 2

Private hProgman As Long

Private Sub Form_Load()
Dim hwnd As Long

hProgman = FindWindow(vbNullString, "Program Manager")

hwnd = GetWindow(hProgman, GW_HWNDFIRST)
Do
Debug.Print hwnd
hwnd = GetWindow(hwnd, GW_HWNDNEXT)
Loop Until hwnd = 0

End Sub

Mal rein vorsorglich:

Die Daten zu einem Fenster ermittelt man so: :-) :-) :-)

Private Sub RegisterWindow(ByVal hWindow As Long)
Dim hParent As Long
Dim hTask As Long
Dim szTitle As String
Dim szClass As String
Dim lStyle As Long

Dim iLength As Integer
Dim lResult As Long

' Eltern-Fenster
hParent = GetParent(hWindow)

' Festerstil
lStyle = GetWindowLong(hWindow, GWL_STYLE)

'Titel des Fenster auslesen
szTitle = Space$(255)
iLength = GetWindowText(hWindow, szTitle, 255)
szTitle = Left$(szTitle, iLength)

szClass = Space$(255)
iLength = GetClassName(hWindow, szClass, Len(szClass))
szClass = Left$(szClass, iLength)

'Task-ID ermitteln
lResult = GetWindowThreadProcessId(hWindow, hTask)

m_Windows = m_Windows + 1
ReDim Preserve m_Window(m_Windows)

m_Window(m_Windows).hWnd = hWindow
m_Window(m_Windows).hParent = hParent
m_Window(m_Windows).Style = lStyle
m_Window(m_Windows).Title = szTitle
m_Window(m_Windows).Class = szClass
m_Window(m_Windows).Task = hTask

m_Window(m_Windows).Locked = False
m_Window(m_Windows).Borders = (lStyle And WS_BORDER) = WS_BORDER
m_Window(m_Windows).Visible = (lStyle And WS_VISIBLE) = WS_VISIBLE

lResult = GetWindowRect(hWindow, m_Window(m_Windows).WindowPos)
End Sub

Danke für den Code, aber die Folge

hProgman = FindWindow(vbNullString, "Program Manager")
hwnd = GetWindow(hProgman, GW_HWNDFIRST)
:::
hwnd = GetWindow(hwnd, GW_HWNDNEXT)

hangelt sich zwar durch die Top-Window-Fensterliste, aber abgesehen von
diversen System-Fenstern sind das nicht die Desktop-Icons.

Wenn ich in dem Fenster mit dem Titel "Program Manager" mit
hWnd=GetWindows(hWnd,GW_CHILD) dessen erstes Child-Window holen will, dann
kommt hWnd wie gehabt wieder mit Null zurück.

seufz

Am 14.04.2024 um 18:35 schrieb Wendelin Uez:
> Danke für den Code, aber die Folge
>
> hProgman = FindWindow(vbNullString, "Program Manager")
> hwnd = GetWindow(hProgman, GW_HWNDFIRST)
> :::
> hwnd = GetWindow(hwnd, GW_HWNDNEXT)
>
> hangelt sich zwar durch die Top-Window-Fensterliste, aber abgesehen von
> diversen System-Fenstern  sind das nicht die Desktop-Icons.
>
> Wenn ich in dem Fenster mit dem Titel "Program Manager"  mit
> hWnd=GetWindows(hWnd,GW_CHILD) dessen erstes Child-Window holen will,
> dann kommt hWnd wie gehabt wieder mit Null zurück.
>
> seufz

Vielleicht gehst Du dein Unterfangen ja auch suboptimal an.

Würde ich nur die Positionen der auf dem Desktop abgelegten
Icons ermitteln wollen, dann würde ich vermutlich einfach die
Icons aus ssfDESKTOP und/oder ssfCOMMONDESKTOPDIRECTORY auslesen
und mir dann mit FindWinwow(Ex) die Daten zum Fenster holen.

Vermutlich ist der ganze Krempel aber auch in der Registry zu
finden.

Ich habe davon wenig Ahnung, denn alles, was ich mit den Icons
anstelle, das ist, sie alle bei jedem Systemstart zu löschen.
Ich hasse Icons auf dem Desktop. Igitigitt...

Am Sat, 13 Apr 2024 10:43:20 +0200 schrieb Wendelin Uez:

>> Was sagt den GetLastError?
>
> null

Der Rückgabewert von GetLastError() ist ohne Aussagekraft, wenn die zuvor
aufgerufene WinAPI-Funktion dem Compiler per Declare bekanntgemacht wurde
(so wie das hier der Fall zu sein scheint). In dieser Situation wäre
Err.LastDllError die geeignete Schnittstelle, um den vom OS hinterlegten
Fehlercode abzufragen.

GetLastError() hingegen ist das Mittel der Wahl, wenn es kein Declare zur
aufgerufenen Funktion gibt, sondern die Funktion mittels einer TLB dem
Compiler bekanntgemacht wurde.

Freilich kann in einem Projekt auch beides gegeben sein; dann sticht die
Declare-Anweisung. Im Zweifel Rechtsklick auf den Funktionsnamen und dann
"Definition" auswählen. Je nachdem landet man dann im Objektkatalog mit
entsprechend vorausgewählter TypeLib, oder eben in einem Modul bei einer
Declare-Anweisung.

--
Viele Grüße,
Wolfgang
https://www.enzinger.net

Am 15.04.2024 um 23:41 schrieb Wolfgang Εnzinger:
> Am Sat, 13 Apr 2024 10:43:20 +0200 schrieb Wendelin Uez:
>
>>> Was sagt den GetLastError?
>>
>> null
>
> Der Rückgabewert von GetLastError() ist ohne Aussagekraft, wenn die zuvor
> aufgerufene WinAPI-Funktion dem Compiler per Declare bekanntgemacht wurde

Dem kann ich so nicht zustimmen.

Meine Api-Funktionen sind IMMER deklariert, und ich arbeite in vielen
sensiblen Bereichen mit GetLastError().

Hier eine solche Funktion. Da liefert GetLastError immer den Fehler.

Function LoadPrivilege(ByVal Privilege As String) As Boolean
'The access
Dim hToken As Long
Dim SEDebugNameValue As LUID
Dim tkp As TOKEN_PRIVILEGES
Dim hProcessHandle As Long
Dim tkpNewButIgnored As TOKEN_PRIVILEGES
Dim lbuffer As Long

hProcessHandle = GetCurrentProcess()
If GetLastError <> 0 Then
MsgBox "GetCurrentProcess, Error: " & GetLastError()
Exit Function
End If

OpenProcessToken hProcessHandle, (TOKEN_ADJUST_PRIVILEGES Or
TOKEN_QUERY), hToken
If GetLastError <> 0 Then
MsgBox "OpenProcessToken, Error: " & GetLastError()
Exit Function
End If

LookupPrivilegeValue "", Privilege, SEDebugNameValue
If GetLastError <> 0 Then
MsgBox "LookupPrivilegeValue, Error: " & GetLastError()
Exit Function
End If

With tkp
.PrivilegeCount = 1
.TheLuid = SEDebugNameValue
.Attributes = SE_PRIVILEGE_ENABLED
End With

AdjustTokenPrivileges hToken, False, tkp, Len(tkp), tkpNewButIgnored,
lbuffer
If GetLastError <> 0 Then
MsgBox "AdjustTokenPrivileges, Error: " & GetLastError()
Exit Function
End If

LoadPrivilege = True

End Function

Gruß Klaus

Hallo Klaus,

Am 16.04.2024 um 01:13 schrieb Klaus Ketelaer:
> Am 15.04.2024 um 23:41 schrieb Wolfgang Εnzinger:
>> Am Sat, 13 Apr 2024 10:43:20 +0200 schrieb Wendelin Uez:
>>
>>>> Was sagt den GetLastError?
>>>
>>> null
>>
>> Der Rückgabewert von GetLastError() ist ohne Aussagekraft, wenn die zuvor
>> aufgerufene WinAPI-Funktion dem Compiler per Declare bekanntgemacht wurde
>
> Dem kann ich so nicht zustimmen.

Doch, das solltest du. Bei einem Aufruf einer per Declare aufgerufen API
Funktion übernimmt VB implizit den Aufruf von GetLastError().

Siehe auch:
http://www.jasinskionline.com/windowsapi/ref/g/getlasterror.html

Dort wird es eventuell etwas besser beschrieben:
Visual Basic-Specific Issues

Although GetLastError works perfectly in Visual Basic, it will sometimes
not appear to work. This is because Visual Basic implicitly uses the API
frequently to perform tasks which are seemingly intrinsic to the
language. These hidden API function calls will usually overwrite the
error code which your code may be trying to read. To compensate for
this, the LastDllError property of the Err object, predefined in Visual
Basic, caches the error code from the last API function explicitly
called by your program. You should use the expression Err.LastDllError
instead of the GetLastError function to debug failed API function calls.

Gruß Ulrich

Am 11.04.2024 um 19:03 schrieb Wendelin Uez:
> Ich möchte gerne u.a. die Icon-Positionen des Desktops auslesen können
> und bin zur Ermittlung des Desktop-Handles auf die beiden folgenden
> Code-Beispiele gestoßen:

Ich sitze jetzt seit 2 Tagen an den blöden Icons und komme nicht
weiter. Die Positionen sind kein Problem, aber ich komme einfach
nicht an die Texte heran...

Vielleicht hilft es dir ja:

Private Function EnumIcons(ByVal lSysListView As Long) As Long
Dim pid As Long
Dim tid As Long
Dim lpSysShared As Long
Dim hProcess As Long
Dim lWritten As Long
Dim i As Integer
Dim pt As POINTAPI

m_Icons = SendMessage(lSysListView, LVM_GETTITEMCOUNT, 0, 0&)
ReDim m_Icon(m_Icons)

tid = GetWindowThreadProcessId(lSysListView, pid)
lpSysShared = GetMemSharedNT(pid, Len(pt), hProcess)
WriteProcessMemory hProcess, ByVal lpSysShared, pt, Len(pt), lWritten
For i = 0 To m_Icons - 1
SendMessage hSysListView, LVM_GETITEMPOSITION, i, ByVal lpSysShared
ReadProcessMemory hProcess, ByVal lpSysShared, pt, Len(pt), lWritten

m_Icon(i).X = pt.X
m_Icon(i).Y = pt.Y
' m_Icon(i).Text = Ich bin einfach zu blöd den Text auszulenen...
Next i
FreeMemSharedNT hProcess, lpSysShared, Len(pt)

End Function

Vielen Dank. Wenn ich das richtig sehe, dann soll lSyslistView das hWnd des
SystemListView-Objekts sein, aber genau an das komme ich ja leider nicht
einmal, und ich weiß auch nicht warum.

> Hallo Klaus,
>
> Am 16.04.2024 um 01:13 schrieb Klaus Ketelaer:
>> Am 15.04.2024 um 23:41 schrieb Wolfgang Εnzinger:
>>> Am Sat, 13 Apr 2024 10:43:20 +0200 schrieb Wendelin Uez:
>>>
>>>>> Was sagt den GetLastError?
>>>>
>>>> null
>>>
>>> Der Rückgabewert von GetLastError() ist ohne Aussagekraft, wenn die
>>> zuvor
>>> aufgerufene WinAPI-Funktion dem Compiler per Declare bekanntgemacht
>>> wurde
>>
>> Dem kann ich so nicht zustimmen.
>
> Doch, das solltest du. Bei einem Aufruf einer per Declare aufgerufen API
> Funktion übernimmt VB implizit den Aufruf von GetLastError().
>
> Siehe auch:
> http://www.jasinskionline.com/windowsapi/ref/g/getlasterror.html
>
> Dort wird es eventuell etwas besser beschrieben:
> Visual Basic-Specific Issues
>
> Although GetLastError works perfectly in Visual Basic, it will sometimes
> not appear to work. This is because Visual Basic implicitly uses the API
> frequently to perform tasks which are seemingly intrinsic to the language.
> These hidden API function calls will usually overwrite the error code
> which your code may be trying to read. To compensate for this, the
> LastDllError property of the Err object, predefined in Visual Basic,
> caches the error code from the last API function explicitly called by your
> program. You should use the expression Err.LastDllError instead of the
> GetLastError function to debug failed API function calls.
>
> Gruß Ulrich

Ich habe jetzt in allen meinen bisherigen Tests GetLastError() durch
Err.LastDLLError ersetzt, auch hier wird null zurück gegeben.

Am 17.04.2024 um 16:07 schrieb Wendelin Uez:
> Vielen Dank. Wenn ich das richtig sehe, dann soll lSyslistView das hWnd
> des SystemListView-Objekts sein, aber genau an das komme ich ja leider
> nicht einmal, und ich weiß auch nicht warum.

hProgman = FindWindow(vbNullString, "Program Manager")
hTemp = FindWindowEx(hProgman, 0, "SHELLDLL_defVIEW", vbNullString)
hSysListView = FindWindowEx(hTemp, 0, "SysListView32", vbNullString)

"Klaus Ketelaer" <usenet@ketelaer.de> schrieb im Newsbeitrag
news:uvp0ve$2he9$1@solani.org...
> Am 17.04.2024 um 16:07 schrieb Wendelin Uez:
>> Vielen Dank. Wenn ich das richtig sehe, dann soll lSyslistView das hWnd
>> des SystemListView-Objekts sein, aber genau an das komme ich ja leider
>> nicht einmal, und ich weiß auch nicht warum.
>
> hProgman = FindWindow(vbNullString, "Program Manager")
> hTemp = FindWindowEx(hProgman, 0, "SHELLDLL_defVIEW", vbNullString)
> hSysListView = FindWindowEx(hTemp, 0, "SysListView32", vbNullString)

Danke Klaus, aber da liegt ja mein Eingangs-Problem, daß das bei mir unter
WIN8.1 nicht funktioniert, hTemp=0 und Err.dllError liefert ebenfalls null
zurück. Unter WIN10 kein Problem, aber das nutzt mir nichts.

Ich könnte jetzt WIN8.1 und den ganzen sonstigen Krempel nochmals neu
installieren und hoffen, daß das dann doch noch funktionieren könnte, aber
soviel Zeit habe ich nicht mal als Rentner :-), also entfällt in meinem Prog
halt das Feature "DesktopIcons".

Mein nächster neuer Rechner wird sowieso nicht mehr unter Windows laufen,
und WINE wird wahrscheinlich noch viel mehr Probleme machen mit Windows-DLLs
(was mich bisher vom Umstieg auf Linux abgehalten hat, gibt's eigentlich
eine WINE-NG?).

Gruß
wuez

Am 19.04.2024 um 13:44 schrieb Wendelin Uez:
>
> Danke Klaus, aber da liegt ja mein Eingangs-Problem, daß das bei mir
> unter WIN8.1 nicht funktioniert, hTemp=0 und Err.dllError liefert
> ebenfalls null zurück. Unter WIN10 kein Problem, aber das nutzt mir nichts.
>
> Ich könnte jetzt WIN8.1 und den ganzen sonstigen Krempel nochmals neu
> installieren und hoffen, daß das dann doch noch funktionieren könnte,
> aber soviel Zeit habe ich nicht mal als Rentner :-), also entfällt in
> meinem Prog halt das Feature "DesktopIcons".

Das ist ja Quark. Deine Probleme können eigentlich garnicht bestehen.
Irgend etwas machst Du falsch. Würde FindWindowEx bei dir nicht
funktionieren, oder es gäbe kein "SHELLDLL_defVIEW" dann würde dein
ganzes System nicht laufen. Ich würde einfach noch mal alle Api-
Deklarationen prüfen.

> Mein nächster neuer Rechner wird sowieso nicht mehr unter Windows
> laufen, und WINE wird wahrscheinlich noch viel mehr Probleme machen mit
> Windows-DLLs (was mich bisher vom Umstieg auf Linux abgehalten hat,

Ich halte das für eine wirklich gut durchdachte Idee, auf Linux
umzusteigen, wenn man den ganzen Tag mit VB codet. Unter Wine
läuft sicherlich alles viel besser...

> gibt's eigentlich eine WINE-NG?).
Natürlich...