Beiträge von nuts

Zitat von Raupi

Das hat aber nichts mit speichern zu tun. Du ruftst die Func Test innerhalb von _DoubleClickOnListView auf. Da existiert der Pointer auf $lParam auch noch. Nach verlassen von _DoubleClickOnListView eben nicht mehr.

Hö? ich speichere $lParam in einer globalen Variable und rufe diese in meiner Testfunktion auf.

Hm als Variable gehts ja:

Na klar. Siehe mein Zusatz zur Funktion von Progandy.
Dort werden weitere Infos aus $ilParam geholt (Zeile 17-27).

Ansonsten hast du ein konkretes Problem dazu? So gut erklären kann ich die halbverstandenen Sachen auch nicht :wacko:

Das funktioniert bei WM_Notify über eine Structur (jetzt frag mich aber nicht wieso und weshalb :D)

Func _SHLV_WM_NOTIFY($hWnd, $iMsg, $iwParam, $ilParam)
; Prog@ndy
#forceref $hWnd, $iMsg, $iwParam
Local $hWndFrom, $iIDFrom, $iCode, $tNMHDR, $tInfo

$tNMHDR = DllStructCreate($tagNMHDR, $ilParam)
$hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom"))
$iIDFrom = DllStructGetData($tNMHDR, "IDFrom")
$iCode = DllStructGetData($tNMHDR, "Code")
Switch $hWndFrom
Case $hListView1
Switch $iCode
Case $NM_DBLCLK ; Sent by a list-view control when the user double-clicks an item with the left mouse button
;Local $ItemText = _GUICtrlListView_GetItemText($hListView1, _GUICtrlListView_GetSelectedIndices($hListView1), 0)
;_Browse($ItemText)

Case $LVN_KEYDOWN
;Nuts-mod ohne Garantie
Local $tagLVKEYDOWN = $tagNMHDR & "; USHORT wVKey; UINT flags;"
$tNMHDR = DllStructCreate($tagLVKEYDOWN, $ilParam)
Switch DllStructGetData($tNMHDR, "wVKey")
Case 0x27; rechte Pfeiltaste
;Local $ItemText = _GUICtrlListView_GetItemText($hListView1, _GUICtrlListView_GetSelectedIndices($hListView1), 0)
;_Browse($ItemText)
Case 0x25 ;linke Pfeiltaste
;_Browseback()
EndSwitch
EndSwitch
EndSwitch
Return $GUI_RUNDEFMSG
EndFunc ;==>_SHLV_WM_NOTIFY

Hilft dir das?

Ähm subzero
Vielleicht durch 100?

Also wirklich versucht hast du das nicht oder?

$1 = (65/1.7)/1.7
MsgBox(1, "", $1)

$2 = 100*24 + 100*24*0.1
MsgBox(1, "", $2)

Sehe ich ähnlich.
Die Info wo das Programm seine Programmversion hinterlegt gehört daher auch ausgelagert (.ini, .txt oder sowas).

Klicks kannst du so auswerten. Funktioniert im OneventModus genauso.

edit \
Hab hier noch eine etwas erweiterte mit Pfeiltasten:

Sehe keinen Fehler, habe nur die Fehlermeldung kommentiert (anschließend selbst ausprobiert und gemerkt: am Aufruf liegts nicht)
Ist schon seltsam :wacko:

Liegt der Schluss nahe, dass deine Anfrage nicht korrekt ist.
http://msdn.microsoft.com/en-us/library/aa390788(VS.85).aspx

edit \ bei mir gehts übrigens

$HKLM = 0x80000002
$BaseKey = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\"
$objReg = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\" &"." & "\root\default:StdRegProv")
dim $test
If IsObj($objReg) Then
$objReg.GetStringValue($HKLM, $BaseKey, "allocatecdroms",$test)
endif
MsgBox(1,"", $test)

Absoluten Schutz gibt es sicher nicht.
Nach "Autoit + Decompilierer" googeln ist aber doch etwas zu einfach.

Um kommerzialisieren gehts mir gar nicht, eher darum per Autoit verschlüsselte Daten nicht so einfach (decomilieren des Decrypt-Scripts) zugänglich zu machen.

Was meint ihr dazu:
Eine Inputbox zur Passwortabfrage, Fileinstall mit Randomziel/Randomnamen des Autoitscript und ein einfaches Run in einer Hochsprache "richtig" compliliert. Vom Programmieraufwand würde sich der Deckmantel in Grenzen halten und man könnte fürs Hauptskript bei Autoit bleiben.
Bringt das was? Die genaue Vorgehensweise wäre ja im Deckmantel verborgen und sozusagen geheim.

Wie soll das den Sourcecode schützen?

Gedanken sollte man sich trotzdem mal über das Thema machen.
Die Decomplilierer verhindern, dass man "sensible" Daten in Autoitprogrammen verwenden kann, da per Decompilierer sofort die Verschlüsselungsmethode inkl. Passwort zu sehen ist.
Vielleicht könnte man einen simplen Deckmantel mit Passwortschutz in einer Hochsprache über das Autoitskript legen?
Allerdings ist mir nicht klar, ob der Code nicht zur Laufzeit abgreifbar bleibt, schließlich muss das Skript trotzdem durch den Interpreter.

Also die Umsetzung wäre mal wirklich interessant. Gibts dazu dann ein fertiges Skript?

Genau, bei dem Schritt die ID des Controls gleich mitzunehmen bin ich dann irgendwie durcheinander gekommen.
Aber naja läuft ja jetzt.

So mach ich das eigentlich auch, nur kam in diesem Fall nur Unsinn raus.
Muss genauer untersucht werden, aber okay läuft ja erstmal - danke dir.

edit \ So nochmal: Die Nachricht "Enter wurde gedrückt" kommt gar nicht vom Input Control richtig (sondern vom Fenster?)?

So wollte noch kurz ein Feedback geben. Die Methode von Funkey hat jetzt den Alltagstest bestanden und wird weiterhin verwendet.
Eine Frage dazu: Wie wurde der abgefeuerte Wert für "Enter" ermittelt (Zeile 53 im Bsp.)?

water: Bei deiner Variante sind mir auch keine "Nebenwirkungen" aufgefallen, WM_Command war mir aber lieber.

Sehr schön.

Grundsätzlich ist das möglich (s. Anhang).
Allerdings ist Directshow sehr kompliziert und per Autoit imho nicht zufriedenstellend nutzbar.
Eine Mediaverwaltung ist schon ein interessantes Projekt, die Wiedergabe würde ich allerdings externen Playern überlassen (mpc-hc z.B.).

Beziehe doch noch die Feiertage mit ein.
Gibts dazu nicht auch schon ne UDF?

Sehr cool.
Fehlen 2 includes zum Testen, habs mal angehängt.