Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.vbclassic > #7645 > unrolled thread

Re: Desktop handle

Back to article view | Back to de.comp.lang.vbclassic

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Desktop handle Klaus Ketelaer <usenet@ketelaer.de> - 2024-04-11 20:16 +0200
    Re: Desktop handle "Wendelin Uez" <wuez@online.de> - 2024-04-12 11:54 +0200
      Re: Desktop handle Klaus Ketelaer <usenet@ketelaer.de> - 2024-04-12 13:28 +0200
        Re: Desktop handle "Wendelin Uez" <wuez@online.de> - 2024-04-12 19:31 +0200
          Re: Desktop handle Klaus Ketelaer <usenet@ketelaer.de> - 2024-04-12 20:42 +0200
            Re: Desktop handle Klaus Ketelaer <usenet@ketelaer.de> - 2024-04-12 20:49 +0200
            Re: Desktop handle "Wendelin Uez" <wuez@online.de> - 2024-04-13 10:43 +0200
              Re: Desktop handle Wolfgang  Εnzinger <we_usenet@nurfuerspam.de> - 2024-04-15 23:41 +0200
                Re: Desktop handle Klaus Ketelaer <usenet@ketelaer.de> - 2024-04-16 01:13 +0200
                  Re: Desktop handle Ulrich Möller <knobbi38@arcor.de> - 2024-04-16 02:54 +0200
                    Re: Desktop handle "Wendelin Uez" <wuez@online.de> - 2024-04-17 16:16 +0200

#7645 — Re: Desktop handle

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)

[toc] | [next] | [standalone]

#7647

"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? 

[toc] | [prev] | [next] | [standalone]

#7648

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

[toc] | [prev] | [next] | [standalone]

#7649

>> 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???

[toc] | [prev] | [next] | [standalone]

#7650

Am 12.04.2024 um 19:31 schrieb Wendelin Uez:

Was sagt den GetLastError?

[toc] | [prev] | [next] | [standalone]

#7651

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...

[toc] | [prev] | [next] | [standalone]

#7654

> Was sagt den GetLastError?

null

[toc] | [prev] | [next] | [standalone]

#7661

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

[toc] | [prev] | [next] | [standalone]

#7664

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

[toc] | [prev] | [next] | [standalone]

#7665

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

[toc] | [prev] | [next] | [standalone]

#7668

> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.vbclassic

csiph-web