Beiträge von Oscar

Ich würde das noch etwas abwandeln, so dass man auch das Alter des Geburtstagskindes anzeigen lassen kann.

#include <Date.au3>
Local $aGeburtstage[2][3] = [["Andreas", "28.12.1989 10:43", False], ["Kloppstock", "31.12.1996 00:16", False]]


While Sleep(1000)
	For $i = 0 To UBound($aGeburtstage) - 1
		$aDate = StringSplit($aGeburtstage[$i][1], " ", 3)


		$aTime = $aDate[1]
		$aDate = StringSplit($aDate[0], ".", 3)


		$aTime = StringSplit($aTime, ":", 3)


		$iDiff = _DateDiff("n", StringFormat("%04i/%02i/%02i %02i:%02i:00", @YEAR, $aDate[1], $aDate[0], $aTime[0], $aTime[1]), _NowCalc()) ; die Differenz in Minuten berechnen (wenn Datum/Zeit noch nicht erreicht, dann ist die Differenz negativ)


		If $iDiff >= 0 And Not $aGeburtstage[$i][2] Then ; wenn das Geburtsdatum/-Zeit erreicht wurde und die MsgBox noch nicht angezeigt wurde, dann...
			$iCount = _DateDiff("Y", StringFormat("%04i/%02i/%02i 00:00:00", $aDate[2], $aDate[1], $aDate[0]), _NowCalc()) ; das Alter berechnen
			MsgBox(48, "Alles Gute!", StringFormat("Hallo %s!\nHerzlichen Glückwunsch zum %i. Geburtstag!", $aGeburtstage[$i][0], $iCount))
			$aGeburtstage[$i][2] = True ; MsgBox wurde bereits angezeigt
		EndIf
		$iDiff = _DateDiff("s", @YEAR & "/12/31 23:59:59", _NowCalc())
		If $iDiff >= 0 Then $aGeburtstage[$i][2] = False ; Neujahr alle Geburtstage zurücksetzen
	Next
WEnd

Also entweder hast Du nicht verstanden, was FileInstall macht oder Du interpretierst etwas in Deine Funktion, was sie nicht erfüllt!
Dein Script schreibt die Dateinamen in eine Textdatei, aber keinesfalls den Dateiinhalt.
Wenn das so gewollt ist, ist es ok, aber dann nicht mit FileInstall vergleichen.
Nachtrag: Wenn Du fremde UDFs verwendest, dann solltest Du diese mit anbieten. Nicht jeder hat diese oder weiß, wo er sie finden kann.

Nachtrag2: Achso, jetzt verstehe ich erst, was Du damit bezweckst! Du willst die Textdatei (eigentlich wäre au3-Endung besser) dann als Script ausführen. Ich bezweifle allerdings, ob das wirklich funktioniert, denn:

Zitat von Hilfe

The destination directory path must already exist before this function is called, or the FileInstall() will fail

Das heißt, FileInstall legt keine Verzeichnisse an und würde dann alles in das Zielverzeichnis packen.

Ja, die "Baustellen" sind mir bereits bekannt!

- Steckplätze:
Ich besitze mittlerweile auch ein aktuelleres Mainboard (PCI-Express) und da wird bei MaxDataWidth von Win32_SystemSlot als Antwort auch 5 bzw. 10 ausgegeben.
Das Problem ist, dass es das laut MSDN gar nicht geben dürfte. Natürlich kann ich den "Fehler" abfangen, aber eigentlich würde ich in dem Fall lieber eine korrekte Information ausgeben lassen.
Kennt sich jemand mit PCI-Express genauer aus? WIe wird denn dort die MaxDataWidth interpretiert?
Soweit wie ich das weiß, ist das doch ein serielles Protokoll. Ich weiß aber nicht, wie das mit den unterschiedlichen Anzahl der Lanes gehandhabt wird. Kann man da überhaupt von einer "Datenbreite" sprechen?

- Netzwerk:
Da bin ich schon dabei, das zu ändern.

- Monitor:
Ist eine üble Baustelle, weil das je nach Windows-Version, nicht immer an der gleichen Stelle zu finden ist und auch nicht immer die gleichen Informationen.

- Mainboard:
Die Informationen über WMI sind sehr stark davon abhängig, was der Mainboard-Hersteller dort zur Verfügung stellt. Bei manchen Mainboards funktioniert es, bei anderen nicht.

- Drucker:
Da müsste ich mal nachsehen, ob und wo man an diese Information kommt.

So ein Programm hobbymäßig zu erstellen, ist ziemlich nervig, weil man nur einen beschränkten "Rechner-Park" zur Verfügung hat (bei mir sind das drei: Desktop-, Notebook-, Media-PC).
Die laufen aber alle unter Windows 7. Aber selbst da, gibt es halt schon (Hardware-)Unterschiede. Und wenn dann noch hunderte unterschiedliche Hardware-Konfigurationen und verschiedene
Windows-Versionen dazukommen, dann wird das zur Mega-Aufgabe.

In dem Zusammenhang wäre es schön, wenn sich einige finden würden, die mir mit Rückmeldungen helfen können. Ich würde dann Testskripte zur Verfügung stellen und ihr schickt mir die Ausgaben des Skripts zurück
(am besten per PN, damit der Thread hier nicht unleserlich wird).

Kannst Du mal bitte die Ausgabe von diesem Script posten:

$objWMIService = ObjGet('winmgmts:\\.\root\cimv2')
$colItems = $objWMIService.ExecQuery('SELECT * FROM Win32_PhysicalMemory', 'WQL', 0x30)
If IsObj($colItems) Then
	For $objItem In $colItems
		ConsoleWrite('BankLabel: ' & $objItem.BankLabel & @CR)
		ConsoleWrite('Capacity: ' & $objItem.Capacity & @CR)
		ConsoleWrite('MemoryType: ' & $objItem.MemoryType & @CR)
	Next
EndIf

Laut Screenshot benutzt Du eine veraltete Version (v2.0).
Die Version aus Post #1 ist schon ziemlich lange die Version 2.1.
Teste bitte mal damit und falls es dann noch Probleme gibt, bitte erneut mit Fehlermeldung posten.
Nachtrag: Und das sieht mir stark nach Windows 10 aus. Könnte sein, dass sich da etwas geändert hat.

Der (für mich) wichtigste Aspekt bei einem Umstieg wäre, ob man vorher mal eine Test-Installation machen kann, in der das Forum an unsere AutoIt-Gegebenheiten (Scriptintegration, Syntaxhighlighting, etc.) angepasst wird.
Und wenn das alles perfekt läuft, dass dann erst der richtige Umstieg vonstatten geht.
Ich weiß nicht, ob und mit welchem Aufwand sowas machbar ist, aber wenn es möglich wäre, dann sollte man das so handhaben.
Jeder der "alten" User wird sich sicher an die Probleme der letzten Umstellung erinnern. Das soll kein Vorwurf an die Admins sein, nur ist es sehr frustrierend, wenn man auf Beiträge antwortet und diese sind aufgrund von Problemen (Backup eingespielt) wieder futsch. Man antwortet erneut und das Ganze passiert nochmal. Von den Zeiten der Nicht-Erreichbarkeit des Forums ganz zu schweigen.
Bitte nicht falsch verstehen! Ich bin durchaus für ein Update. Es wäre aber schön, wenn sich die Probleme nicht wiederholen würden.

Ich denke, die Finanzierung des Updates wird nicht so das Problem sein. Ich werde mich auch wieder daran beteiligen.
Allerdings habe ich auch (wie Andy) so Bedenken, ob es dieses Mal reibungslos ablaufen wird.
Gibt es denn eine Auflistung, was sich da alles getan hat (neue Funktionen, Bugfixes, etc.)?

Zitat von Cape-City

Wenn ich allerdings ständig den Mauspfeil bewege, "friert" mein Script nicht ein und läuft so flüssig wie es kann weiter.

Das ist der "normale" Effekt bei einer Msg-Loop-Schleife. Wenn Du also GUIGetMsg benutzt, dann wird das immer so sein, weil der Befehl damit intern die Prozessorlast reduziert.
Willst Du das vermeiden, musst Du zum OnEventMode wechseln. IMHO sowieso der bessere Modus, weil man mehr funktionsorientiert arbeitet.
Edit: Wenn's unbedingt GUIGetMsg sein muss, dann die kritischen Teile per Timer (AdlibRegister oder besser noch die Timer-UDF) aufrufen.

Du musst eine Abfrage einbauen, ob der Browser überhaupt läuft und nur dann die Idletime auswerten.
Im übrigen ist es völlig unsinnig, noch ein externes Programm dafür zu verwenden. Einfach alles in einem Script:

#include <GUIConstantsEx.au3>
#include <Process.au3>
#include <StaticConstants.au3>
#include <WinAPISys.au3>


Global $hGui = GUICreate('Idle-Time', 300, 200)
Global $idFirefox = GUICtrlCreateLabel('Firefox: beendet', 10, 10, 200, 20)
GUICtrlSetFont(-1, 14, 400, 0, 'Times New Roman')
Global $idMSec = GUICtrlCreateLabel('0', 210, 10, 80, 20)
GUICtrlSetFont(-1, 14, 400, 0, 'Times New Roman')
Global $idMsg = GUICtrlCreateLabel('Firefox wird in 10 sek. beendet!', 10, 100, 280, 20, $SS_CENTER)
GUICtrlSetFont(-1, 16, 400, 0, 'Times New Roman')
GUICtrlSetState(-1, $GUI_HIDE)
GUISetState()
Global $fExist = False, $iResttime, $iLasttime
Global $sProcess = 'firefox.exe' ; Prozessname dessen Fenster geschlossen werden sollen
Global $iWaitTime = 3000 ; Wartezeit bis Meldung (Zeit in Millisekunden)
Global $iTime2Close = 10000 ; Zeit bis zum beenden der Fenster (Zeit in Millisekunden)
While True
	If GUIGetMsg() = $GUI_EVENT_CLOSE Then Exit
	If ProcessExists($sProcess) Then
		If Not $fExist Then
			$fExist = True
			GUICtrlSetData($idFirefox, 'Firefox: aktiv')
		EndIf
		$iIdleTime = _WinAPI_GetIdleTime()
		If $iIdleTime > $iWaitTime Then
			If BitAND(GUICtrlGetState($idMsg), $GUI_HIDE) Then GUICtrlSetState($idMsg, $GUI_SHOW)
			$iResttime = Int(($iTime2Close + $iWaitTime - $iIdleTime) / 1000)
			If $iResttime <> $iLasttime Then
				$iLasttime = $iResttime
				GUICtrlSetData($idMsg, 'Firefox wird in ' & $iResttime & ' sek. beendet.')
			EndIf
			If $iIdleTime > $iTime2Close + $iWaitTime Then _WinCloseByProcessname($sProcess)
		Else
			If BitAND(GUICtrlGetState($idMsg), $GUI_SHOW) Then GUICtrlSetState($idMsg, $GUI_HIDE)
		EndIf
		GUICtrlSetData($idMSec, $iIdleTime)
	Else
		If $fExist Then
			$fExist = False
			GUICtrlSetData($idFirefox, 'Firefox: beendet')
			GUICtrlSetState($idMsg, $GUI_HIDE)
		EndIf
	EndIf
WEnd


Func _WinCloseByProcessname($sProcess)
	Local $aList = WinList()
	For $i = 1 To $aList[0][0]
		If _ProcessGetName(WinGetProcess($aList[$i][1])) = $sProcess Then WinClose($aList[$i][1])
	Next
EndFunc

Zitat von BlackHornetttt

Ja es geht um ca 30-40 pcs die, die user offen lassen mit youtube videos oder streams und nicht mehr schließen und dadurch das internet belasten.

Da stellt sich mir die Frage, wie Du erkennen willst, ob der PC "unbenutzt" ist?
Wenn sich jemand ein Video anschaut, dann ist der PC während dessen doch auch "unbenutzt".
Das Script kann nicht erkennen, ob jemand vor dem PC sitzt oder nicht. Es sei denn, Du bastelst eine Hardware-Erweiterung (Bewegungsmelder/Kamera) davor.

Das war ja eigentlich auch nur ein Testscript, um zu verdeutlichen, wie man auf die fehlende Benutzeraktion reagieren kann.
Natürlich wird hier "immer" nach 3 Sekunden Idle-Time das andere Programm aufgerufen.
Wenn das aber nur dann passieren soll, wenn z.B. ein Browserfenster offen ist, dann musst Du diese zusätzliche Abfrage noch mit einbauen.

_WinAPI_GetIdleTime liefert Dir die Zeit in Millisekunden, seit der letzten Benutzeraktion.
Somit reicht eine einfache Abfrage, um irgendetwas zu tun:

#include <GUIConstantsEx.au3>
#include <WinAPISys.au3>


Global $hGui = GUICreate('Idle-Time', 300, 200)
Global $idMSec = GUICtrlCreateLabel('0', 10, 10, 280, 20)
GUISetState()
While True
	If GUIGetMsg() = $GUI_EVENT_CLOSE Then Exit
	$iIdleTime = _WinAPI_GetIdleTime()
	If $iIdleTime > 3000 Then MsgBox(0, 'Test', '3 Sekunden sind um.')
	GUICtrlSetData($idMSec, $iIdleTime)
WEnd

Mir würde sich allerdings die Frage stellen, warum Du einen nicht benutzten Browser schließen willst.
Als Anwender würde ich mir ziemlich bevormundet vorkommen, wenn ich so ein Programm benutzen würde.

Zitat von Tyh_Nel

Aber klappt das auch so bei mehren Monitoren?

Ja, prinzipiell funktioniert das auch mit mehreren Monitoren!
Und solange beim nächsten Programmstart nichts an der Anordnung/Auflösung der Monitore geändert wurde, wird das Fenster wieder an der alten Position geöffnet.
Aufpassen musst Du, wenn Dein Programm im minimierten Zustand beendet werden kann, denn:

Zitat

WinGetPos() returns negative numbers such as -32000 for minimized windows

Und wie autoiter bereits schrieb, kannst Du Dir bei meinem Script gern abschauen, wie man sicherstellen kann, dass das Fenster auch bei deaktiviertem zweiten Monitor angezeigt wird.
Wobei es ja noch die Variante gibt, dass der Monitor zwar angeschlossen ist, aber die Auflösung und/oder Position geändert wurde.
Will man auch den Fall berücksichtigen, wird es noch etwas aufwendiger.

Zu dem, wie Du den Status der Checkboxen abspeicherst, möchte ich auch noch etwas anmerken:
1. Du solltest Dich nicht darauf verlassen, dass die Werte von $GUI_CHECKED und $GUI_UNCHECKED für immer (bei späteren AutoIt-Versionen) 1 und 4 sind. Also lieber die entsprechenden Konstanten verwenden!
2. Eine Checkbox kann nicht nur CHECKED/UNCHECKED sein. Es gibt auch noch den 3State-Mode, weshalb man sich angewöhnen sollte, den Status immer mit BitAnd(GuiCtrlRead($Checkbox), $GUI_CHECKED) abzufragen.
3. Diese Konstruktion:

If GUICtrlRead($AutoConfigSave) = 1 Then
	RegWrite("HKEY_CURRENT_USER\Software\IniStream", "Save_Config_Save", "REG_SZ", 1)
ElseIf GUICtrlRead($AutoConfigSave) = 4 Then
	RegWrite("HKEY_CURRENT_USER\Software\IniStream", "Save_Config_Save", "REG_SZ", 4)
EndIf

ist nicht nur aufgrund obiger Punkte "falsch", sondern man kann das auch in eine Zeile packen:

RegWrite("HKEY_CURRENT_USER\Software\IniStream", "Save_Config_Save", "REG_SZ", GUICtrlRead($AutoConfigSave))

Das ist jetzt schwer zu verstehen, aber falls ich das richtig verstanden habe, dann spielt es doch keine Rolle, wo das Programm liegt, sondern auf welchem Rechner es ausgeführt wird.
Wenn es auf dem lokalen Rechner läuft, dann wandern die Daten immer S -> L -> S. Das würde nur schneller gehen, wenn auf dem Server ein "Kopier-Script" läuft, das vom lokalen Rechner Kopierbefehle ausführen kann.

Auch von mir alles Gute zum Geburtstag!

Von "Simucal" (Simucal@gmail.com) aus dem engl. Forum gibt es eine UDF (siehe Anhang) zum auslesen der Datei-Eigenschaften.

Ja, bei meinen Scripten benutze ich oft kleine Funktionen, die ich früher schonmal geschrieben habe ohne damals eine wirkliche Verwendung dafür gehabt zu haben.
"_InputDateBox" (für die Datums/Uhrzeiteingabe) und "_DateImage" (für das Kalenderblatt) gehören dazu.

autoBert: Das Multimonitorhandling ist hingegen neu (jedenfalls bei mir). Es störte mich, wenn ich das Fenster auf meinen 2. Monitor verschoben hatte (Position wird ja beim Programmende abgespeichert) und dann beim nächsten Programmstart der 2. Monitor gar nicht aktiviert war. Dann ist das Fenster nicht sichtbar.
Also verschiebe ich das Fenster auf den aktiven Monitor, wenn der entsprechende Monitor (bisherige Fenster-Position) nicht vorhanden ist. Das funktioniert wie es soll (jedenfalls bei mir).

Achso, das Hintergrundbild ist von mir fotografiert worden. Nur falls sich jemand wegen des Copyright Sorgen macht. Ich stelle das Bild hier als Freeware zur Verfügung!
Das Calendar-Icon stammt nicht von mir, sondern von "Mihaiciuc Bogdan" und wurde auf "http://www.iconarchive.com" als Freeware zur Verfügung gestellt: http://www.iconarchive.com/show/indigo-ic…endar-icon.html

Irgendwie bin ich schon wieder Urlaubsreif!
Damit ich mich jeden Tag daran erinnern kann, wie lange es noch hin ist, bis zum nächsten Urlaub, habe ich mal ein Script geschrieben, das mir die Zeit bis dahin anzeigt.
Die Bedienung ist ganz einfach: Auf das "Kalenderblatt" links unten klicken und das Anfangsdatum/-uhrzeit eintragen, fertig!

Vielleicht kann es ja noch jemand gebrauchen.

Screenshot:

Screenshot_Tagezaehler.png

Umgehen kann man den Effekt auch, indem man die MsgBox als Child-Window erstellt.
Also beim MsgBox-Befehl $Form1 als Parent eintragen: MsgBox(0, "32bit Geräteübersicht V1.08.3", $geraete32, 0, $Form1)

Zitat von DanteMay

Nun kommt es aber hin und wieder vor das irgendwas verbugt in den Subscripts (Fenster öffnet sich zb plötzlich obwohl es nicht eingeplant ist) und damit die Scripts zum Stillstand kommen.

Schonmal etwas von Debugging gehört?
Anstatt die anderen Scripte neu zu starten, solltest Du lieber erstmal deren Fehler finden und beseitigen.
Einfach zu sagen, ich kenne/finde den Fehler nicht und mache es mir einfach (Script neu starten) ist u.U. eine gefährliche Einstellungsweise(Datenverlust).