Beiträge von card0384

nach zahlreichen Versuchen und Fehlschlägen wende ich mich wieder an die Community in der Hoffnung, weiter zu kommen.

Ich möchte eine größenveränderliche GUI erstellen, in welcher ich einen Windows-Explorer einbetten möchte.
Der Benutzer soll die Möglichkeit haben, Dateien per Windows-Drag/Drop oder Copy/Paste raus- und rein zu kopieren.
Er soll aber nur das eigentliche Explorerfenster zu sehen bekommen, keinen Schnick-Schnack ringsrum, keine Adressleiste, keine Symbolleiste, keine Statusleiste, keine Vorschau und keine Navigationsleiste.
Die Darstellung soll Detail-Ansicht sein. Ich kann/möchte keinerlei Windows-Einstellungen dazu verbiegen/müssen - der Aufbau des embedded-Explorers muss dies alles bewerkstelligen.

Soweit zu meiner Idealvorstellung. Bei meinen weiteren Beschreibungen verzichte ich der Einfachheit halber auf die Größenveränderlichkeit...

Bislang habe ich verschiedene Wege getestet:

1. mit dem shell.explorer.2-Objekt:

[autoit]

$object = ObjCreate("Shell.Explorer.2")
$GUI_ActiveX = GUICtrlCreateObj ($object, 10, 10, 300, 400)
$object.navigate("\\Server\Freigabe\Ordner")

[/autoit]

Dies macht genau meine Ansicht die ich benötige. Problem hier speziell unter Windows 7: Drag/Drop auf eine Datei klappt nicht, bei Rechte Maustaste-Kopieren hängt sich die GUI auf, bei Klicken auf einen Ordner geht immer ein neues Windows-Explorerfenster außerhalb der GUI auf.
Das Problem hier scheint mir, das shell.explorer.2-Objekt ist ein Internet-Explorer-Objekt, welcher im Windows 7 keine Windows-Explorer-Darstellung mehr übernimmt, sondern dies dem Windows-Explorer übergibt, welcher in einem separatem Fenster startet. Dies kann man prima nachstellen, wenn man im Internet-Explorer C:\ eingibt, dann startet ein neues separates Windows-Explorer-Fenster. Dieser Weg wird also meiner Einschätzung nach im Windows 7 nicht mehr gehen. Oder kennt da jemand einen Ausweg?

Ein richtiges Windows-Explorer-Objekt mit IDispatch scheint es im Windows 7 nicht zu geben - ich kenn bislang nur shell.explorer oder Internet.Application oder so ähnlich...

2. mit dem explorer.exe-Prozess:

[autoit]

Run('explorer.exe /n, \\Server\Freigabe\Ordner', "", @SW_HIDE)
WinWait("[CLASS:CabinetWClass]")
$hExplorer = WinGetHandle("[CLASS:CabinetWClass]")
_WinAPI_SetParent($hExplorer, $MaskeChildWin); Explorer als embedded-Objekt setzen
WinMove($hExplorer, "", 10, 10, 300, 400)
_WinAPI_SetWindowLong($hExplorer, $GWL_STYLE, 0x06800000); damit wird der Rahmen entfernt incl. Close- und Minimier-Button
WinSetState($hExplorer, "", @SW_SHOW)
$hList = ControlGetHandle ($hExplorer, "", "[CLASS:DirectUIHWND; INSTANCE:3]"); komischerweise ist es bei Windows 7 nicht "[CLASS:SysListView32; INSTANCE:1]"
$ausgabe = ControlListView ($hExplorer, "", $hList, "ViewChange", "details"); Auf Detail-Ansicht umschalten
;jetzt aus dem Handle das Objekt ermitteln
$o_Shell = ObjCreate("Shell.Application")
$o_ShellWindows = $o_Shell.Windows(); collection of all ShellWindows (IE and File Explorer)
For $o_window In $o_ShellWindows
If $o_window.LocationURL = "file:" & StringReplace($folder, "\", "/") Then
$hExplorerobj = $o_window
ExitLoop
EndIf
Next

[/autoit][autoit][/autoit][autoit]

;Hier noch erste fehlerhafte Ideen, die Navigationsleiste weg zu bekommen (die links neben der File-Ordner-Ansicht im W7 steht)
$objPane = $hExplorerobj.LocationURL
$o_Shell = ObjCreate("Application.ActiveExplorer")
$objPane = $o_Shell.NavigationPane
$objPane.IsCollapsed = True

[/autoit]

Kann mir bitte jemand weiterhelfen, wie ich ein eingebettetes Windows-Explorer-Fenster ohne jeglichen Schnick-Schnack in meine GUI bekomme?

Wie genau kann ich denn mit einem Zertifikat die exe beim Erstellen signieren?
Gibts da ein #AutoIt3Wrapper_...-Eintrag, mit welchem ich das Zertifikat einbinden kann?

Ich hab das ganze noch ein wenig analysiert.
Ich konnte feststellen, daß die meiste Zeit (und Prozessorlast) draufgeht beim DllStructSetData($tCustDraw, 'clrTextBk', "Farbe").
Ich habe darauf hin den Weissanteil optimiert, jetzt läuft das Script doch recht flüssig und ohne nennenswerte Prozessorlast.
Hier die simple Erweiterung als Beispiel, sollte Bugfix eventuell in Ansätzen in sein Beispielscript übernehmen (die Farbe wirste wohl mit deiner DefaultColor ersetzen...):

[autoit]

If DllStructGetData($tCustDraw, 'clrTextBk') <> 0xFFFFFF Then DllStructSetData($tCustDraw, 'clrTextBk', RGB2BGR(0xFFFFFF))

[/autoit]

Ich hab auch inzwischen ne etwas tricky-Variante gefunden, ohne die Listview-Zeile zu markieren, an die Werte für Zeile und Spalte ranzukommen:
Listviewcreate mit $LVS_EX_FULLROWSELECT und

[autoit]

Case $NM_DBLCLK
Local $tInfo = DllStructCreate($tagNMITEMACTIVATE, $lParam)
Local $aInfo[2] = [DllStructGetData($tInfo, "Index"), DllStructGetData($tInfo, "SubItem")]
$AWUeberblickLV[5] = $aInfo
$DoubleClicked = True
Case -100
Local $tInfo = DllStructCreate($tagNMITEMACTIVATE, $lParam)
$AWUeberblickLV[4] = DllStructGetData($tInfo, "Index")
Case -101
If $AWUeberblickLV[4] > -1 Then _GUICtrlListView_SetItemFocused($AWUeberblickLV[1], $AWUeberblickLV[4], False)

[/autoit]

So richtig gefällt mir die Lösung aber nicht. Ich habe aber analysiert und festgestellt, daß bei keinem Casewert in der $tInfo-Struktur die Zeile zu finden ist, wenn nicht $LVS_EX_FULLROWSELECT als ex-Schalter gesetzt ist (wenn irgend ein anderer Ex-Schalter gesetzt wird). Hat da jemand noch eine bessere Idee?

Es taucht noch ein Problem auf, wenn ich das Script laufen lasse und mir dabei eine Tabelle mit 365 Tagen = Spalten anzeigen lasse, wird das Script ca. ab der 5. Zeile extrem langsam. Wo kann man da noch etwas verbessern (speziell im WM_Notify)?

Hi Autobert und Bugfix,

so, ich habe mir jetzt anhand von FormatSubItemLVex.au3 und den Array-Beschreibungen von Bugfix eine funktionierende Routine zusammengebaut, die genau das macht, was ich benötige:

[autoit]

Global $AWUeberblickLV[4] = ["","","",""]
;0 - ListView
;1 - ListView-Handle
;2 - ListView-Spalten
;3 - ListView-Formatset

[/autoit][autoit][/autoit][autoit]

Func Abwesenheit aktualisieren()
...
GUICtrlDelete($AWUeberblickLV[0])

[/autoit][autoit][/autoit][autoit]

$AWUeberblickLV[0] = GUICtrlCreateListView($Text, 16, 16, $Breite, 544, -1, bitOr($LVS_EX_GRIDLINES, $LVS_EX_FLATSB))
GUICtrlSetFont(-1, 9, 400, 0, "Microsoft Sans Serif")
$AWUeberblickLV[1] = GUICtrlGetHandle($AWUeberblickLV[0])
_GUICtrlListView_SetColumnWidth($AWUeberblickLV[0], 0, 0)
$Breite1 = INT(($Breite-220)/($Ende-$Start))
_GUICtrlListView_SetColumnWidth($AWUeberblickLV[0], 1, $Breite-50-($Breite1*($Ende-$Start)))
For $i = 2 To $Ende-$Start+2
_GUICtrlListView_SetColumnWidth($AWUeberblickLV[0], $i, $Breite1)
Next
$AWUeberblickLV[2] = _GUICtrlListView_GetColumnCount($AWUeberblickLV[0])
;Farbwerte füllen
Dim $aSubItemSet[UBound($AWUeberblickMA,2)][$Ende-$Start+3]
;1.Dim - Zeile je MA
;2.Dim - Spalte (Zeitachse)
;Eintrag = Farbwert

[/autoit][autoit][/autoit][autoit]

For $i = 1 To UBound($AWUeberblickMA,2)-1
GUICtrlCreateListViewItem($i &"|" & $AWUeberblickMA[0][$i][1], $AWUeberblickLV[0])
For $j = $Start-$AWUeberblickMA[0][0][4] To $Ende-$AWUeberblickMA[0][0][4]
If $AWUeberblickMA[$j][$i][2] <> "" Then
If $AWUeberblickMA[$j][$i][3] = 1 Then
$aSubItemSet[$i][$j-($Start-$AWUeberblickMA[0][0][4])+2] = "0x"&StringRight($AWUeberblickMA[$j][$i][2], 6)
Else
$aSubItemSet[$i][$j-($Start-$AWUeberblickMA[0][0][4])+2] = "0x"&StringLeft($AWUeberblickMA[$j][$i][2], 6)
EndIf
EndIf
$AWUeberblickLV[3] = $aSubItemSet
Next
Next
...
EndFunc

[/autoit][autoit][/autoit][autoit]

Func WM_NOTIFY($hWnd, $MsgID, $wParam, $lParam)
Local $hWndFrom, $iIDFrom, $iCode, $tNMHDR
$tNMHDR = DllStructCreate($tagNMHDR, $lParam)
If @error Then Return 0
$hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom"))
$iIDFrom = DllStructGetData($tNMHDR, "IDFrom")
$iCode = DllStructGetData($tNMHDR, "Code")
;If $icode = -5 Then ConsoleWrite($code)
; AND $icode = -101 Then $Clicked = True
;If NOT GUICtrlRead($wParam) = 0 AND $icode = -100 Then $LeerClicked = True
If $icode = -5 AND $RightClick = False Then Return 0
If NOT GUICtrlRead($wParam) = 0 AND $icode = -3 Then $DoubleClicked = True
$AktObjekt = $wParam
Switch $hWndFrom
Case $AWUeberblickLV[1]
Switch $iCode
Case $NM_CUSTOMDRAW
If Not _GUICtrlListView_GetViewDetails($hWndFrom) Then Return $GUI_RUNDEFMSG
Local $tCustDraw = DllStructCreate($tagNMLVCUSTOMDRAW, $lParam)
Local $iDrawStage, $iItem, $iSubitem, $hDC, $tRect, $aSubItemSet
$iDrawStage = DllStructGetData($tCustDraw, 'dwDrawStage')
Switch $iDrawStage
Case $CDDS_ITEMPREPAINT
Return $CDRF_NOTIFYSUBITEMDRAW
Case BitOR($CDDS_ITEMPREPAINT, $CDDS_SUBITEM)
$iItem = DllStructGetData($tCustDraw, 'dwItemSpec')
$iSubitem = DllStructGetData($tCustDraw, 'iSubItem')
$aSubItemSet = $AWUeberblickLV[3]
$hDC = DllStructGetData($tCustDraw, 'hdc')
If $iItem < UBound($aSubItemSet,1) AND $iSubitem < UBound($aSubItemSet,2) Then
If $aSubItemSet[$iItem][$iSubitem] = "" Then $aSubItemSet[$iItem][$iSubitem] = 0xFFFFFF
DllStructSetData($tCustDraw, 'clrTextBk', RGB2BGR($aSubItemSet[$iItem][$iSubitem]))
Else
DllStructSetData($tCustDraw, 'clrTextBk', RGB2BGR(0xFFFFFF))
EndIf
Return $CDRF_NEWFONT
EndSwitch
EndSwitch
EndSwitch
Return $GUI_RUNDEFMSG
EndFunc

[/autoit][autoit][/autoit][autoit][/autoit]

Dies sind nur Auszüge aus meinem Programm, aber das Prinzip sollte ersichtlich sein.
Ich hab die verschiedenen Farbstati in einer SQL-DB stehen, diese werden, falls Farbwerte für den jeweiligen Tag/Mitarbeiter vorhanden sind, in das Array geschrieben, welches dann (ohne Array-Search) direkt ausgewertet werden kann. Ich konnte mein WM_NOTIFY dahingehend anpassen, daß es sowohl Doppel-Klick (für meine anderen Funktionalitäten) wie auch die Befärbung der Tabelle übernimmt.

Ich habe jetzt auch das Prinzip verstanden, man kann den einzelnen Wert nicht direkt ansprechen, sondern muss warten (millisekunden ), bis das System das entsprechende Tabellenfeld selbst auf Aktualisierung anspricht, hakt dabei ein und verändert die Werte - stimmt das so?

Jetzt hätte ich noch zwei Ergänzungsfragen.

1: wie muss ich das WM_NOTIFY anpassen, damit ich im Falle des Doppelklicks für die Tabelle den Wert für $item und $subitem zurückbekomme?
Ich hab aus LV_Edit_Subitem den entsprechenden Codeschnippsel und mein WM_Notify übernommen, bekomme aber nur die Spalte, nicht die Zeile zurück - siehe hier - alles unter Case $NM_DBLCLK:

[autoit]

Func WM_NOTIFY($hWnd, $MsgID, $wParam, $lParam)
Local $hWndFrom, $iIDFrom, $iCode, $tNMHDR
$tNMHDR = DllStructCreate($tagNMHDR, $lParam)
If @error Then Return 0
$hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom"))
$iIDFrom = DllStructGetData($tNMHDR, "IDFrom")
$iCode = DllStructGetData($tNMHDR, "Code")
;If $icode = -5 Then ConsoleWrite($code)
; AND $icode = -101 Then $Clicked = True
;If NOT GUICtrlRead($wParam) = 0 AND $icode = -100 Then $LeerClicked = True
If $icode = -5 AND $RightClick = False Then Return 0
If NOT GUICtrlRead($wParam) = 0 AND $icode = -3 Then $DoubleClicked = True
$AktObjekt = $wParam
Switch $hWndFrom
Case $AWUeberblickLV[1]
Switch $iCode
Case $NM_CUSTOMDRAW
If Not _GUICtrlListView_GetViewDetails($hWndFrom) Then Return $GUI_RUNDEFMSG
Local $tCustDraw = DllStructCreate($tagNMLVCUSTOMDRAW, $lParam)
Local $iDrawStage, $iItem, $iSubitem, $hDC, $tRect, $aSubItemSet
$iDrawStage = DllStructGetData($tCustDraw, 'dwDrawStage')
Switch $iDrawStage
Case $CDDS_ITEMPREPAINT
Return $CDRF_NOTIFYSUBITEMDRAW
Case BitOR($CDDS_ITEMPREPAINT, $CDDS_SUBITEM)
$iItem = DllStructGetData($tCustDraw, 'dwItemSpec')
$iSubitem = DllStructGetData($tCustDraw, 'iSubItem')
$aSubItemSet = $AWUeberblickLV[3]
$hDC = DllStructGetData($tCustDraw, 'hdc')
If $iItem < UBound($aSubItemSet,1) AND $iSubitem < UBound($aSubItemSet,2) Then
If $aSubItemSet[$iItem][$iSubitem] = "" Then $aSubItemSet[$iItem][$iSubitem] = 0xFFFFFF
DllStructSetData($tCustDraw, 'clrTextBk', RGB2BGR($aSubItemSet[$iItem][$iSubitem]))
Else
DllStructSetData($tCustDraw, 'clrTextBk', RGB2BGR(0xFFFFFF))
EndIf
Return $CDRF_NEWFONT
EndSwitch
Case $NM_DBLCLK
Local $tInfo = DllStructCreate($tagNMITEMACTIVATE, $lParam)
Local $aInfo[5] = [$hWndFrom, $iIDFrom, $iCode, DllStructGetData($tInfo, "Index"), _
DllStructGetData($tInfo, "SubItem")]
ConsoleWrite(@CRLF)
For $i = 0 To UBound($aInfo)-1
ConsoleWrite($i & "-" & $aInfo[$i] & " - ")
Next
EndSwitch
EndSwitch
Return $GUI_RUNDEFMSG
EndFunc

[/autoit]

Edit: habs inzwischen rausgefunden, es liegt am Ex-Style bitOr($LVS_EX_GRIDLINES, $LVS_EX_FLATSB). Sobald ein Ex-Style angegeben wird, kommt die Zeile nicht mehr zurück. Ich bekomm nur die Zeile, wenn ich in der ersten Spalte direkt auf den Texteintrag dblklicke. Bei allen anderen Spalten kommt nichts zurück, zumal ja auch nichts drin steht...
Mit $LVS_EX_FULLROWSELECT komm ich wieder an die Zeile ran, dann ist aber die betreffende Zeile blau (markiert). Dies nützt mir auch nichts - wenn überhaupt, sollte max. das angeklickte Feld markiert sein - es würde mich aber auch nicht stören, wenn gar nichts markiert ist. Gibts da ne Möglichkeit, dennoch an die Zeile ranzukommen?

Edit: Wenn ich bei $iCode den Switch nach Case -100 erweitere, dann komm ich, bevor die Zeile markiert wird, an $item ran.
Gibts da ne Möglichkeit, nachdem ich den $item-Wert ausgelesen habe, das Markieren der Zeile zu unterbinden?

2: ist es über diese Variante möglich (falls ja wie), die Gridlines manuell zu befüllen? Ich stelle mir vor, nur die Felder zu befüllen, die zum Array gehören, also wo auch Werte vorkommen können, und dabei der Übersichtlichkeit halber nur jede 7.Spalte und nur jede 2. Zeile mit Gridlines zu bestücken. Wenn ich mittels DllStructSetData($tCustDraw, 'clrTextBk'... den Hintergrund verändern kann, gibt es doch bestimmt einen anderen Wert, mit dem ich z.B. den unteren Rand des Feldes mit einer bestimmten Strichstärke und Farbe bestücken kann.
Gibts da Links zu MS, wo die Werte, wie z.B. 'clrTextBk' und die anderen Werte beschrieben werden?

Das würd ich gern - aber deine UDF verwendet Subroutinen (RGB-Farbe und WM_Notify), die ich bereits in meinem Programm enthalten habe.
Dies macht es nicht unbedingt einfacher.

PS: mein Programm liegt derzeit bei 15700 Zeilen (ohne die includes) - du siehst also, es ist leider nicht so einfach, einfach ein weiteres UDF einzubauen...

dein Beispiel färbt doch auch erst eine ganze Zeile rot und dann eine ganze spalte blau. Dabei werden die rot-Anteile der Blauspalte überschrieben. Aber leider färbt dein Script keine einzelne Zelle.
Ist eine einzelne Zelle überhaupt nicht ansteuerbar?

ok, damit lässt sich was anfangen - wie bekomm ich nicht die Spalte, sondern nur ein bestimmtes Feld (Zeile 3 Spalte 5) farbig? Dein Script färbt immer die gesamte Spalte...

Hi AutoBert,

danke für deine Antwort, aber die Zeile 61 erwartet ne Änderung im $iSubitem - da weiß ich derzeit noch nicht, woher ich die nehmen soll.
Ich hatte eher mit ner Variante geliebäugelt, in der ich zwischen Zeile 10 und 19 den Wert für $iItem und $iSubItem und die Farbe angeben kann und damit die Änderung ausgelöst wird. Da fehlt mir noch der Ansatz dazu...

ok, nur weiß ich jetzt immer noch nicht, wie ich in deinem konkreten Beispiel (ohne Klicken in das Listview) z.B. dem item 3, Subitem 14 sagen kann, färbe dich rot...

Hi BugFix,

danke für deine schnelle Rückinfo - damit lässt sich doch bestimmt was anfangen...

Zwei Frage hab ich da noch:
1. Du hast im WM_Notify $iItem und $iSubItem nur als Ergebniss, nicht aber als Vorgabe drin. Ich muss nur programmtechnisch die Felder füllen, bei mir soll kein User da irgendwo hin klicken, damits bunt wird. Ich muss also direkt dem Programm mitteilen, z.B. $item 3, $subitem 25 muss rot sein. Dies muss ich auch nur ein einziges Mal je Listview machen - wie kann ich dies dem Programm beibringen?
2. Geht das Ganze aufgrund 1. auch ohne WM_Notify, also direkt im Script-Ablauf? Hast da ne Idee? Man müsste doch die Strukturen 1x direkt nach dem Listviewcreate definieren können und dann während der Befüllung des Listviews verändern? Oder veranlasst die Veränderung der Befüllung den WM_Notify zur Ausführung? Dann müsste ich die Veränderung doch der entsprechenden Struktur mitteilen - nur wie?

Hi @all

ich kenn hier im Forum die nette Lösung von Bugfix, wie man jedem Feld eines Listviews eigene Farben zuordnen kann.
Ich möchte (auch der Geschwindigkeit halber) eine extrem abgespeckte Lösung dessen verwenden.
Ich erstelle eine Urlaubsliste, in der stehen links die Namen der Leute und ansonsten steht im Listview nichts drin, also alle Spalten (eine je Tag - 31 in der Darstellung) sind leer.
Ich möchte direkt beim Erstellen eines Listviewitems in dieser Zeile das Subitem 5, 23,24 und 25 blau färben.
Ich muss jedes dazu einmal ansteuern, das ist mir schon klar.
Wie lässt sich dies mit möglichst wenig Programmschritten machen?

Das Gesamte Listview muss nicht sortierfähig sein, ich benötige keine Textfärbung, Fontgröße, Art etc., ich benötige keine Default-Werte, die StandartListViewfärbung ist ok, es wird auch nicht aktualisiert, da die flüssigste Aktualisierung (z.B. der Benutzer schaltet die Darstellung auf den nächsten Monat) bei mir aus zwei ChildGUIs besteht, eine wird dargestellt, eine zweite ChildGUI wird ausgeblendet. Bei der Aktualisierung wird in der ausgeblendeten ein Listview erzeugt, dieses gefüllt - farbig angepasst und anschließend sichtbar gemacht. Dabei wird das bis dahin sichtbare ChildGUI ausgeblendet und das Listview darin deleted.
Daher benötige ich auch keinen Firlefanz bei der Einfärbung der einzelnen SubItems - bei jeder Aktualisierung wird das gesamte Listview wieder entfernt.

Kann mir jemand (Bugfix selbst vielleicht) eine Möglichkeit aufzeigen, das Subitem direkt nach dem Erzeugen des Items anzusprechen?
Gibts da nen DLLCall oder an welcher Stelle des BugFix-Codes genau wird das Subitem gefärbt? Ich seh da immer nur nen Schwung DllStructGetData, aber keinen DLLCall, bei welchem das ganze wieder an das ListView übergeben wird.

BspCode:

[autoit]

For $i = 1 To UBound($AWUeberblickMA,2)-1 ;Die MAs werden einzeln durchgegangen
GUICtrlCreateListViewItem($i &"|" & $AWUeberblickMA[0][$i][1], $AWUeberblickLV[$AWUeberblickLV[7]+1]) ;Einbindung desListViewItems - bestehend aus dem Namen des MAs
For $j = $Monatsstart To $Monatsende ;Die einzelnen Tage des Monats werden nach Werten durchsucht
If $AWUeberblickMA[$j][$i][2] <> "" Then XXX (ListviewSubitem-BKColor einstellen) ;Wenn eine Farbe im MA-Array vorhanden ist, dann soll diese zum Einfärben verwendet werden
Next
Next

[/autoit]

Hi water,

hab ein Statement von MS, nachdem ich den Bug offiziell gemeldet habe.
Der Bug ist denen bekannt, wenn ich darlegen könnte, daß mir durch den Bug Millionen und Abermillionen an Gewinnen verloren gehen, dann würde eine eher unwahrscheinliche Chance entstehen, den Fehler zu fixen.
Also ich übersetz mal frei: Egal was du versuchst, wir werden dir bei einem OS, was eigentlich schon nicht mehr aktuell sein sollte, nicht mehr helfen...

Soviel dazu...

Schlussendlich bedeutet dies für uns, entweder wir finden eine mini-DLL, die die reine Anmeldefkt. übernehmen kann oder die Anmeldung über dein GetLastError-Objekt wird erst ab Windows 7 (bei Vista keine Erfahrung bislang) mit Bordmitteln klappen.

card

ja, auf jeden Fall, das AdFind ist nur ne gute Lösung, um ohne Autoit schnell mal zu testen, obs geht.
Das Adfind und GetLastError die gleiche DLL schlussendlich verwenden, wird GetLastError immer gehen, wenn AdFind geht...

Zitat von water

Ich habe gerade eine Windows 7 Machine bekommen und werde da mal ein bischen spielen.

Habs unter W7 getestet - geht... (mit AdFind)
Hast du ein Vista-PC zum probieren?

ich könnt fast wetten, daß dort das Ganze geht, weil ähnlich aktuell wie W2008. Es reicht schon, wenn du ADFind.exe zum testen nimmst...

Ich hab übrigens nen Beitrag im WWW aus 2006 gefunden, da wird sich auch über das Problem ausgelassen - da gibts nen MSler, der mein, sollst LDAP_BIND_S mit LDAP_AUTH_NEGOTIATE nehmen, weil SIMPLE_BIND_S von MS nicht unterstütz werden will, wegen Klartext-PW...

siehe hier

LDAP_BIND_S bekomm ich irgendwie nur nicht zum laufen - sagt er mir immer Error 7 - muss heißen: Authentifizierungsmethode wird vom Server nicht unterstützt... Sollte aber bei W2003-AD klappen

Beispielaufruf - passt in meine anderen Scripte aus meinen älteren Beiträgen hier rein:

[autoit]

Func ldap_bind_s()
$fkt = "ldap_bind_s"
$dn = DllStructCreate("char")
;DllStructSetData($dn,1, "")

[/autoit][autoit][/autoit][autoit]

$userdata = DllStructCreate("char[" & (StringLen($username) + 1) & "];" & _
"ULONG;" & _
"char[" & (StringLen($domain) + 1) & "];" & _
"ULONG;" & _
"char[" & (StringLen($Passwort) + 1) & "];" & _
"ULONG;" & _
"ULONG;")
DllStructSetData($userdata,1, $username)
DllStructSetData($userdata,2, StringLen($username))
DllStructSetData($userdata,3, $domain)
DllStructSetData($userdata,4, StringLen($domain))
DllStructSetData($userdata,5, $Passwort)
DllStructSetData($userdata,6, StringLen($Passwort))
DllStructSetData($userdata,7, $SEC_WINNT_AUTH_IDENTITY_ANSI)

[/autoit][autoit][/autoit][autoit]

Return DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "ptr",DllStructGetPtr($dn), "ptr",DllStructGetPtr($userdata), "ULONG", $LDAP_AUTH_NEGOTIATE)
EndFunc

[/autoit]

Hi Water - ich nochmal,

da ich hier langsam mal Erfolge sehen möchte, habe ich eine Supportanfrage bei MS gestellt. Die Kostet zwar 299,- Euro, wird aber im Falle eine MS-Bugs (welcher dies hier nunmal ist) kostenlos.
Da werd ich dem Techniker mal das Problem mit W-XP und Co. zur WLDAP32.DLL mitteilen und die werden darauf hin hoffentlich ein WindowsUpdate verteilen...
Schaun wir mal. Dies wäre dann auf jeden Fall eine Alternative, daß ich den Leuten, die diese Anwendung ausführen wollen, sage, sie sollen Windows-Update mit KBxxxxxx installieren...
Das kann jeder selbst und die meisten haben es eh auf automatisches Update.
Bin mal gespannt, wie schnell MS da arbeitet...

Hi Water - wie wars im Urlaub?

Zitat von water

Hast Du ne Ahnung, warum Du hier von ADFind die Extended Error Information wie gewünscht kriegst und dann später nicht mehr? Was hat sich geändert? Welches OS hast Du da verwendet?

Ich hab dies mit meinem W2008-Server getestet - dort bekomm ich sie auch immer noch zurück - ist aber leider der einzige, wo es geht - die gleichen Scripte bei W2003 oder W-XP bringen keine Rückmeldung, trotzt Rückmeldung im Sniffer - also sie ist da, nur die WLDAP32 gibt sie nicht mehr aus...
Mein W2008 ist übrigens 64bit, die anderen OS sind 32bit - weiß nicht, ob es von Bedeutung ist...

Ich habe inzwischen mal den Support von ldapbrowser.com angeschrieben - hier die Antwort:

Zitat

Hello,

LDAP Browser uses Netscape LDAP C API (now it’s Mozilla LDAP C API). You can find it here https://wiki.mozilla.org/LDAP_C_SDK.

Sincerely yours,

Anton Kascheev
Software engineer
Softerra Ltd.

Meine Anfrage:
Hallo, LDAP-Browser Team,

Ich habe ein Problem und bitte um Ihre Unterstützung
ich hätte da eine Frage. Ich benötige für mich selbst eine exe oder dll, die den LDAP_SIMPLE_BIND_S durchführt und mir den extended-Error-String zurückgibt.
Dies habe ich versucht, über die WLDAP32.dll zu lösen. Leider habe ich PCs, an denen bekomme ich mit meinem Script den Error-String (z.B. W2008 ), aber auch andere PCs, an denen bekomm ich den String bei gleichem Script leider nicht (z.B. W-XP-SP3 oder W2003). Mit eurem ldapbrowser wird der String in jedem Fall zurückgegeben. Ihr macht da also etwas anders/besser, wie die WLDAP32.dll abzufragen.
Könnt Ihr mir bitte verraten, welche API/dll ihr verwendet (und wie), um den extended-Error zurück zu bekommen?
Ihr setzt eigene DLLs (im Installverzeichnis des ldapbrowsers) ein. Diese müssen jedoch auch auf System-APIs bzw. DLLs zurück greifen - denke ich jedenfalls.
Wie genau macht ihr das? Es wäre sehr nett von euch, wenn ihr mir eine Tip geben könntet, wie eure Freeware dies anstellt.
Ich möchte nur ein LDAP_init, ein LDAP_SET_Version=3 und ein LDAP_SIMPLE_BIND_S ausführen, um zu verifizieren, ob Benutzername+Passwort beim Anmelden an ein Active-Directory-LDAP stimmen und falls nicht, was genau der Fehler ist.

Alles anzeigen

Dies habe ich an joe weitergegeben - seine Antwort:

Zitat

I had a feeling that was the LDAP lib they were using. I have no intention of switching to that library. Too much useful functionality in the Windows LDAP lib that I am not willing to give up.

joe

--

O'Reilly Active Directory Fourth Edition - http://www.joeware.net/win/ad4e.htm

Meine Anfrage:

Hi Joe,

is this interested for you?
This is my Contact with ldapbrowser.com-Support…

Best regards…

Alles anzeigen

Joe hatte mir in einer früheren Mail bestätigt, daß er WLDAP32 verwendet - daher wird es hier keine Lösung für unser Problem geben - man müsste von https://wiki.mozilla.org/LDAP_C_SDK das SDK kompilen zu ner DLL oder EXE mit nur den von uns benötigten Funktionen oder noch besser, in deren Quellcode (ist im SDK dabei) sehen, wie die das machen und ob man dies in Autoit nachstellen kann - aber dies übersteigt meinen Horizont etwas.
Kannst dir das SDK ja mal ziehen - es wird nur in ein Verzeichniss entpackt, da ist alles drin, was ldapbrowser.com verwendet, um die Rückinfo aus dem System zu kitzeln...

Vermutlich reichen den paarn die Rückinfos, obs geht oder nicht. Nur warum es nicht geht, daß scheint keinen zu interessieren.
Ich seh allerdings viele sich mit dem Problem in Verbindung mit java und WebProgrammierung rumschlagen...
Ich hab joe mal auf den ldapbrowser angesetzt, bei dem bekomm ich immer die Rückinfo - vermutlich, weil der seine eigenen dlls mitbringt.
Vielleicht checkt joe, was der ldapbrowser anders macht...

Was mir bei Tests noch aufgefallen war, die ADsGetLastError-Abfrage erzeugt keinen IP-Traffic, also die Information wird wirklich vom Memory-Stack der API, die vorher die LDAP-Abfrage iniziiert hat, abgefragt.
Da scheint dabei schon das Problem zu liegen...
Die WLDAP32.DLL sieht auch diese Abfrage vor, nur leider hab ichs nicht geschafft, mittels DLL-Call die Info aus ihr rauszukitzeln.

Mein Codeausschnitt

[autoit]

Const $LDAP_AUTH_SIMPLE = 0x80
Global $ldapldll = DllOpen("WLDAP32.DLL")

[/autoit][autoit][/autoit][autoit]

Func ldapinit()
$Hostptr = DllStructCreate("char[" & (StringLen($Host) + 1) & "]")
DllStructSetData($Hostptr,1,$Host)
$fkt = "ldap_open"
Return DllCall($ldapldll, "ptr", $fkt, "ptr",DllStructGetPtr($Hostptr), "ULONG", "")
EndFunc

[/autoit][autoit][/autoit][autoit]

Func ldap_simple_bind_s()
$fkt = "ldap_simple_bind_s"
$dn = DllStructCreate("char[" & (StringLen($domain & "\" & $username) + 1) & "]")
DllStructSetData($dn,1, $domain & "\" & $username)
$passwd = DllStructCreate("char[" & (StringLen($Passwort) + 1) & "]")
DllStructSetData($passwd,1, $Passwort)
Return DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "ptr",DllStructGetPtr($dn), "ptr",DllStructGetPtr($passwd), "ULONG", $LDAP_AUTH_SIMPLE)
EndFunc

[/autoit][autoit][/autoit][autoit]

Func ldap_get_option()
$ldaperr = DllStructCreate("ULONG")
;DllStructSetData($ldaperr,1, 0)
$fkt = "ldap_get_option"
;$ldaperr = 0
;$ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x11, "ptr", DllStructGetPtr($ldaperr))
$ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x32, "ptr", DllStructGetPtr($ldaperr))
$ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x33, "ptr", DllStructGetPtr($ldaperr))
$ergebnis = DllCall($ldapldll, "DWORD", $fkt, "ptr", $ldapinit[0], "int", 0x34, "ptr", DllStructGetPtr($ldaperr))
$ergebnis = DllCall($ldapldll, "ULONG", $fkt, "ptr", $ldapinit[0], "int", 0x30, "ptr", DllStructGetPtr($ldaperr))

[/autoit]

bringt mir eine erfolgreiche Anmeldung, aber als Returncode, bzw. $ldaperr kommt immer nur Kauderwelsch.. Vielleicht hast du ne Idee, wie man die WLDAP32 dazu bekommt, den extended Returnstring auszuspucken..
Vielleicht ist die WLDAP32 auch der Schlüssel, um immer eine Returnmeldung zu bekommen - wenn sie denn mal eine ausspuckt. Die 0x30-0x34 sind die Parameter, die die verschiedenen Returns ausspucken...
Const $LDAP_OPT_ERROR_NUMBER = 0x31
Const $LDAP_OPT_ERROR_STRING = 0x32
Const $LDAP_OPT_SERVER_ERROR = 0x33
Const $LDAP_OPT_SERVER_EXT_ERROR = 0x34
Const $LDAP_OPT_PROTOCOL_VERSION = 0x11

Da hast du recht - mich wundert nur, warum noch keiner im großen google das gleiche Problem bemerkt hat...

Ich will die Vorfreude nicht bremsen, aber Activeds.dll gibt die Fehlermeldungen genau so zurück wie adfind.exe - also auf meinem W2008 gehts und auf meinem W-XP-SP3 gehts nicht - gleiches Script...
Edit - noch ein Test, mit W2003 gehts auch nicht...

Diese dll ist also auch nicht der Stein des Weißen - man müsste die dlls des ldapbrowsers ansprechen können - aber wie kommt man an die Aufrufroutinen?