Beiträge von BugFix

Wenn dir nicht mal diese trivialen Dinge bekannt sind, wirst du erst recht an der Kommunikation in einem Chat scheitern. Weiterhin gehören solche Dinge, wie Anmeldedaten, vernünftig verschlüsselt am Besten in eine Datenbank.

Zitat von dieselwiesel

Kannst du mir noch sagen welche bewandnis das Number() in deinem Bespiel hatte?

Die Zahlen, die den Dateistand abbilden, werden aus einem String gelesen. Somit werden sie auch als String verglichen statt als Zahl. Deshalb wird mit Number sichergestellt, dass ein Zahlenvergleich stattfindet.

10 < 9     ; False
'10' < '9' ; True !!

Zitat von skorpion-de

Wie müsste das aussehen wenn ich Titel und Class zusammen verwenden will?

Findest du in der Hilfe: Windows Titles and Text (Advanced)

Statt jedem Label ein Kontextmenü zuzuweisen, empfehle ich dir die folgende Variante.

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <Array.au3>


$MainGUI = GUICreate("", 250, 250)
$Button  = GUICTRLCreateButton("TEST",20,220,100,20)


$CmdGUI = GUICreate('', 200, 105, -1, -1, Default, $WS_EX_MDICHILD, $MainGUI)
$btCmd1 = GUICtrlCreateButton('Funktion A', 5, 5, 190, 20)
$btCmd2 = GUICtrlCreateButton('Funktion B', 5, 30, 190, 20)
$btCmd3 = GUICtrlCreateButton('Funktion C', 5, 55, 190, 20)
$btClose = GUICtrlCreateButton('Close', 5, 80, 190, 20)


GUISetState(@SW_SHOW, $MainGUI)


$arLabels=_CreateLabel()




While True
	$aMsg = GUIGetMsg(1)
	Switch $aMsg[1]
		Case $MainGUI
			Switch $aMsg[0]
				Case $GUI_EVENT_CLOSE
					Exit
				Case $GUI_EVENT_SECONDARYDOWN
					_secCklick((GUIGetCursorInfo($MainGUI))[4])
			EndSwitch
		Case $CmdGUI
			Switch $aMsg[0]
				Case $GUI_EVENT_CLOSE, $btClose
					GUISetState(@SW_HIDE, $CmdGUI)
				Case $btCmd1
					;
				Case $btCmd2
					;
				Case $btCmd3
					;
			EndSwitch
	EndSwitch
WEnd


Func _secCklick($iID)
	If _ArraySearch($arLabels, $iID) > -1 Then
		WinSetTitle($CmdGUI, '', ControlGetText($MainGUI, '', $iID))
		GUISetState(@SW_SHOW, $CmdGUI)
	EndIf
EndFunc


Func _CreateLabel()
	local $Array[10]
	for $i = 0 to UBound($Array)-1
		$Array[$i]=GUICTRLCreateLabel("Test" & $i, 20,20*$i,200,15)
		GUICtrlSetBkColor(-1,0x0B610B)
	Next
	return $Array
EndFunc

Bei Rechtsklick auf ein Label rufst du eine zweite GUI auf und übergibst den Text des Labels (im Bsp. setze ich den Fensternamen damit). Dann kannst du weiterverfahren, wie bei einem Kontextmenü.

Zitat von svart

wenn ich per Kontext-Menü auf "TEST" klicke?

Du hast aber kein Kontextmenü erstellt

Viel zu kompliziert gedacht, geht ganz simpel:

$sOutput = ControlGetText('[CLASS:SciTEWindow]', '', '[CLASS:Scintilla; INSTANCE:2]')

Die SciTE-Konsole kann man mit Lua elegant auslesen. Ich teste nachher mal, ob sich das mit meinem LuaInline aus einem AutoItskript umsetzen läßt.

He, probiere es bitte aus. Natürlich musst du den (Eingabe)Stream schließen, sonst wird die Eingabe doch niemals als beendet erkannt. Genau das machst du per Hand mit ENTER.
Eingabestream und Ausgabestream sind zwei getrennte Dinge. Deshalb heißen die Funktionen ja auch: StdinWrite, StdoutRead.

Das Problem ist, dass der Seiteninhalt statisch mit Variablen belegt ist, die durch ein Javascript dynamisch besetzt werden und somit nicht im Quelltext lesbar sind.
Quelltext:

<div id="wpc_titlebox">
		    	<div id="wpc_intitext">
		    		<span id="wpc_interpret">a</span>
		    		<span id="wpc_listtitle">b</span>
		    	</div>
		    </div>

Somit kann man nur 'a' und 'b' als Abfrageergebnis auslesen:

$html = 'http://www.jumpradio.de/static/webchannel-player/index.html?channel=1&volume=0'
$sRead = BinaryToString(InetRead($html))
$aMatch = StringRegExp($sRead, 'id="wpc_interpret">([^<]+)</span>[\r\n\t\s]+<span id="wpc_listtitle">([^<]+)', 1)
ConsoleWrite('Interpret: ' & $aMatch[0] & ', Titel: ' & $aMatch[1] & @CRLF)

Ob und wie man evtl. auf die dynamischen Daten zugreifen kann, da bin ich nicht auf dem Laufenden.

Zitat von seventh_son

Liegt das vielleicht daran, dass mit StdinWrite keine ENTER-Taste übermittelt werden kann?

Schau dir doch das Hilfebsp. an. Da steht es im Code:

Zitat von Hilfe zu StdinWrite

; Calling StdinWrite without a second parameter closes the stream.
StdinWrite($iPID)

Hier habe ich mal schnell ein Plugin gezimmert, um bis zu einer bestimmten Spalte mit Leerzeichen aufzufüllen.
Dazu:
1. Die angehängte Datei zu den SciTE-Lua Dateien hinzufügen. (Falls du keinen eigenen Skriptordner für Lua-Ordner definiert hast, kopiere die Datei zu den Eigenen Dateien und verlinke per Hardlink in den SciTE-Ordner. Dann bleibt die Datei auch nach einem SciTE-Update erhalten und du brauchst nur neu zu verlinken.)
2. In SciTEUser.properties einen Eintrag machen für die Zielspalte
column.to.fill=53
3. Einen Shortcut definieren in SciTEUser.properties:

command.name.35.*.au3=Fill with Spaces
command.35.*.au3=dofile C:\Code_AutoIt\LUA\InsertSpacesToColumn.lua
command.mode.35.*.au3=subsystem:lua,savebefore:yes
command.shortcut.35.*.au3=Ctrl+Shift+F9

Den Dateipfad, die Command-Nr und den Shortcut anpassen.

Zitat von seventh_son

auch das Senden der Kommandozeilen-Eingabe per ControlSend

*schüttel*
Schau dir mal in der Hilfe an: StdinWrite, StdoutRead
Das löst sowohl die Eingabe als auch die Ausgabe ganz seriös.

Noch einfacher ist es natürlich, wenn du den Inhalt der Batch durch ein AutoIt Skript ersetzt.

Zitat von Kanashius

Welcher Idiot hat sich das denn ausgedacht? Ist doch vollkommen unnötig...

Ist halt in der Sprache gewachsen und somit erhalten geblieben. Ich empfinde bestimmte Dinge in anderen Sprachen als Humbug (z.B. Array-Index 0- ODER 1-basiert, je nach Geschmäckle, in VB). Ist aber so, muß man mit Leben.

Zitat von Phil-IT

Ich denke es liegt an den Adminrechten oder sowas.

Das kann gut sein. OI wird ja im Programme-Ordner erstellt und somit ist das Schreiben eingeschränkt. Gehe einfach im Explorer auf den AutoIt-Ordner und gib dir für den Ordner (inkl. aller Unterordner) vollen Zugriff. Dann sollte das Problem gelöst sein.

Zitat von AutoMit

Dann wird als Arbeitsverzeichnis das Verzeichnis der AutoIt3_x64.exe genommen und nicht das Arbeitsverzeichnis des Scripts

Ja klar, du führst ja auch die AutoIt3_x64.exe aus, dein Skript wird ja nur zur Interpretation als Parameter dorthin übergeben.
Um im Skriptverzeichnis auszuführen mußt du dir einen eigenen Aufruf erstellen. Etwa so: Run("Full_Path_AutoIt.exe 'Full_Path_Script.au3'", "Script_Dir")
Du brauchst also ein kompiliertes Skript, welches vom auszuführenden Skript den Pfad ausliest, den Kommandostring für Run erstellt und Run startet.

Zitat von AutoMit

"D:\! Autoit !\! Autoit 2015\AutoIt3_x64.exe" "%1" %*

Seltsame Syntax. Bei mir sieht das so aus: "C:\Program Files (x86)\AutoIt3\AutoIt3_x64.exe" "%1" %*
Ich hab mal zum Abgleich den Registry-Zweig angehängt. Bei mir sind alle Kontextmenüeinträge vorhanden.

EDIT:
Zum Auslesen des markierten Eintrags im Explorer kannst du das folgende Skript nutzen:

;===============================================================================
; Function Name....: _ActiveExplorer_GetSelected
; Description......: Erstellt ein Array mit
;                    - Anzahl der markierten Dateien/Ordner
;                    - dem Pfad des aktiven Explorerfensters und
;                    - dem/den Pfad/en der markiert/en Datei/en /Ordner
; Parameter(s).....: keine
; Requirement(s)...: offenes Explorerfenster
; Return Value(s)..: Array mit den Daten, $a[0] = Anzahl, $a[1] = Ordnerpfad, $a[2..] = Datei/Ordnername
; .................: ACHTUNG! Letzter Index somit $a[0]+1 !!
; Author(s)........: BugFix ( bugfix@autoit.de )
;===============================================================================
Func _ActiveExplorer_GetSelected()
	Local $oShell = ObjCreate("Shell.Application")
	Local $oExplorer, $sPath, $oFolderView, $iCount = 0, $sSelectedFiles = '', $n = 2
	Local $oShellWindows = $oShell.Windows
	For $i = 0 To $oShellWindows.Count -1
		$oExplorer = $oShellWindows($i)
		$sPath = StringReplace(StringReplace(StringTrimLeft($oExplorer.LocationURL, 8), '%20', ' '), '/', '\')
		If WinGetTitle('[ACTIVE]') = $sPath Then ExitLoop
	Next
	$oFolderView = $oExplorer.Document.SelectedItems()
	$iCount = $oFolderView.Count
	Local $aOut[$iCount +2]
	$aOut[0] = $iCount
	$aOut[1] = $sPath
	If $iCount = 0 Then
		Return ''
	Else
		For $oFolderItem In $oFolderView
			$aOut[$n] = $oFolderItem.Name
			$n += 1
		Next
		Return $aOut
	EndIf
EndFunc  ; ==>_ActiveExplorer_GetSelected

Ich habe ein WinXP in meiner Oracle Virtualbox um die DB-Zugriffe in unserem Firmennetz nachzubilden und so einige Tools testen zu können. Dort läuft eine Firebird-DB. Nun wollte ich ODBC konfigurieren um per ADODB vom Hostsystem auf die DB im Gast zuzugreifen.
Netzwerkverbindung zwischen Host und Gast funktioniert, eine Freigabe ist vorhanden und erreichbar.
Witzig ist übrigens, dass man zur Konfiguration des 32-Bit ODBC-Treibers über den 64-Bit-Pfad gehen muss ("C:\Windows\Syswow64\odbcad32.exe).
Ich habe die Verbindungsdaten analog zu den ODBC-Einstellungen auf den Firmen-PC gesetzt. Datenbank: XPVM/23050:GDILine:/Daten/GDI.GDB, in der Firma: SERVER/23050:GDILine:/Daten/GDI.GDB
Aber der Verbindungstest schlägt immer fehl. Ein lokaler ODBC-Zugriff innerhalb der VM klappt problemlos (Datenbank: C:\GDILine\Daten\GDI.GDB).

Hat jemand eine Idee, warum das daneben geht? Ich wollte zumindest mal testen, ob die Verbindung von der höherwertigeren Hostumgebung zum Gast auch schneller ist als eine Verbindung innerhalb der doch limitierten VM.

Zitat von Racer

100ms 64Bit Zahl zurückgegen das die vergangene Zeit seit 1.1.1600

??
Soweit ich weiß, sind es 100 ns - Intervalle seit dem 1.1.1601 0:00 Uhr. ("w32tm /ntte" weiß das ja )
Zu beachten ist dabei auch, dass "LastLogon" und "LastLogonTimeStamp" nur alle 14 Tage synchronisiert werden! Um den aktuellsten Wert zu finden, musst du jeden Domänencontroller im Netzwerk abfragen.

Zitat von Racer

30 Minuten (für rund 20000 Clients)

Rund 90 ms pro Client halte ich nicht für übermäßig langsam.

Das Problem entsteht, weil du die Daten des Fensters, das bei Rechtsklick aufgeht, nicht mit dem Tool abfragen kannst (Tool gibt das Zielkreuz nur per Linksklick frei und erlaubt keine Klicks).
Du mußt also mal mit WinList dir auflisten lassen, was beim Anzeigen des Kontextmenüs für ein neues Fenster entsteht. Hast du erst das Handle kannst du auch die Menüpunkte selektieren und einzeln aktivieren.

Zitat von AutoMit

Daher verstehe ich Deine Anmerkung nicht, dass sich das entsprechende Programm starten soll.

Bis jetzt hast du ja nur ein Tray-Icon am Idlen, dass erst auf einen Klick von dir das gewünschte Programm bzw. eine weitere Funktion dieses Programms startet. In der Regel kannst du diesen Aufruf auch direkt per Kommandozeile ausführen. Zumindest mit Systemprogrammen ist das, soweit ich weiß, weitestgehend möglich. Bsp. (USB-)Hardware auswerfen: RunDll32.exe shell32.dll,Control_RunDLL hotplug.dll
Einfach mal bei anderen Programmen in der Doku gucken, ob nicht per Flag der gesuchte Menüpunkt im Kontextmenü direkt aufgerufen werden kann.

Wenn ich nicht irre, ist ein "Picker"-Ctrl nur dazu geeignet, Werte auszuspucken, die es selbst bereitstellt in der gewählten Form (Tages-, Monatskalender etc.).
Du kannst ihn also m.M. nicht als Input mißbrauchen.