Ohne es je genutzt zu haben aber vielleicht findest du hier was nützliches: https://woshub.com/powershell-view-change-bios-settings/
Auch wenn es ggf. bedeutet den Umweg über PS zu gehen aber die könntest du über AutoIt ja triggern.
Ohne es je genutzt zu haben aber vielleicht findest du hier was nützliches: https://woshub.com/powershell-view-change-bios-settings/
Auch wenn es ggf. bedeutet den Umweg über PS zu gehen aber die könntest du über AutoIt ja triggern.
Ich denke das hängt auch stark vom BIOS ab.
Bei meinem alten Mainboard gab es extra eine Anwendung mit der ich aus Windows heraus ins BIOS Menü gekommen bin (oder diese zumindestr "emuliert hat") und somit entsprechende Änderungen vornehmen konnte.
Beim jetzigen kann ich es nicht mehr (gleicher Hersteller).
Leider hängt das oft nicht nur stark von den Mitarbeitern, sondern auch oft am Vorgesetzten... will der partou gewisse Sachen nicht (egal wie Sinnvoll sie sind), werden sie abgelehnt.
Diese Erfahrung mache ich als IT'ler auch immer wieder bzgl. anderen IT-Abteilungen aber auch anderen nicht-IT-Abteilungen.
Das Problem liegt oft eher an der Denkweise: das kommt nicht von der entsprechenden Abteilung = schlecht/abgelehnt... oder: oh nein das wäre eine Veränderung: bloß nicht!
Und dann gibts da noch die MS Variante (direkt in Outlook und Office integriert), auch mal so mal so aber generell schon wesentlich besser geworden wenn man so oder so im Programm ist.
Nicht immer Hatte auch da schon bescheuerte Ergebnisse
oops copy paste Fehler
Korrigiert. Damit bekommst du auf jedenfall den Default Browser (sofern gesetzt) und den Pfad zur exe.
Deswegen ja das mit dem run.
Ein Beispiel (kann ich nichtzu 100% testen):
Opt('MustDeclareVars', 1)
Global Const $Homepage = '"http://google.de"'
Global $DB = RegRead("HKEY_CURRENT_USER\Software\Clients\StartMenuInternet", "")
$DB = RegRead("HKEY_CURRENT_USER\Software\Clients\StartMenuInternet\" & $DB & '\shell\open\command', "")
run($DB & ' -new-window ' & $Homepage)
Ich denke eher das das bisher ignoriert wurde (von Windows), es aber nachgebessert wurde und damit führende Leerzeichen entfernt werden (ich kann dies auch mit Lazarus erstellten Programmen nachstellen).
In diesem Fall empfinde ich diese Änderung als durchaus sinnvoll (meine Meinung), da mich solche spielereien in der Regel eher stören.
Wenn es rein um die Optik geht, würde ich dann einfach drauf verzichten oder du musst dir eine titlebar per GUI selber zusammen bauen.
Oder setz halt einfach einen . davor
Freut mich das ich helfen konnte und gleich mal selber wieder was dazu gelernt
So soll es sein.
Danke für die Bestätigung
Das _ArrayDisplay wird natürlich nicht benötigt und habe ich nur zum Zeigen drinnen gelassen, da es mehrere Einträge gibt.
Bekloppterweise funktionierte es nicht den Titel mit wingethandle() mit "|" bzw. "| " zu erweitern (= keine Ergebnisse) aber auf diese Weise klappte es dann.
Btw.: Ich würde die Funktion für eine dynamische Verwendung so nutzen/Umbauen:
Opt('MustDeclareVars', 1)
WinMove(Get_Window('CLASS', 'TeamsWebView', '|'),"", 1, 1, 735, 720)
Func Get_Window($TYPE, $Data, $Extra); Type can be CLASS or TITLE
Local Const $aWinList = WinList("[REGEXP" & $TYPE & ":(?i)(.*" & $Data & "*)]")
For $i = 0 to Ubound($aWinList) - 1
If StringInStr($aWinList[$i][0], $Extra) then
Return $aWinList[$i][0]
EndIf
Next
EndFunc
Alles anzeigen
Ich habe es nochmal probiert und bekam immer 2 handles als Ergebnis. Allerdings war das 2. (in meinem aktuellen Test) immer das Gesuchte.
Dynamisch dann so:
Func Example()
; Retrieve a list of window handles using a regular expression. The regular expression looks for titles that contain the word SciTE or Internet Explorer.
Local Const $aWinList = WinList("[REGEXPCLASS:(?i)(.*TeamsWebView*)]")
_ArrayDisplay($aWinList)
For $i = 0 to Ubound($aWinList) - 1
If StringInStr($aWinList[$i][0], '|') then
WinMove($aWinList[$i][0],"", 1, 1, 735, 720)
ExitLoop
EndIf
Next
EndFunc ;==>Example
Alles anzeigen
Also ein Q&D Test mid dem Beispiel aus der Hilfe und der oben genannten Class funktioniert bei mir einwandfrei (fürs schließen und winmove)
Sicher das du das richtige handle hast?
Teams (ich nutze das "neue") hat im Titel bei mir alles mögliche stehen, und im Taskmanager sehe ich mind. 2 Unterprozesse für Teams, die "Micosoft Teams" enthalten, du hast also eine mind. 50%ige chance das falsche zu treffen (korrigiert mich wenn ich falsch liege).
Bei mir wäre im betreffenden Fenster für den Titel folgendes Konstant und in Kombination einmalig: "|Unternehmensname|account|Microsoft Teams" (evtl. reicht dir hier auch "|Microsoft Teams")
Aber die Class "TeamsWebView" könntest du ggf. auch nutzen.
Ich würde das eher in einer eigenen mini-sub Gui umsetzen, ist wesentlich einfacher und du hast volle Kontrolle.
Opt('MustDeclareVars', 1)
#include <WindowsConstants.au3>
#include <GUIConstantsEx.au3>
#include <GUIConstants.au3>
consolewrite(@CRLF & GUI_Create_1('"Auswahl für Nr. xxxxxx" & " treffen"', $MainGUIHandle) & @CRLF)
Exit
Func GUI_Create_1($Text, $MainGUI)
Local $Return
Local Const $LocalGui = GUICreate("Stammdaten - Auswahl", 320, 160, -1, -1, $DS_SETFOREGROUND + $WS_EX_TOPMOST + $WS_SYSMENU)
Local Const $Doku = GUICtrlCreateButton("Doku öffnen", 5, 100, 100, 25)
Local Const $Druck = GUICtrlCreateButton("Nr.-Druck" , 105, 100, 100, 25)
Local Const $ERP = GUICtrlCreateButton("ERP suchen" , 210, 100, 100, 25)
Local Const $Message = GUICtrlCreateLabel($Text, 10, 5, 310, 90, $SS_CENTER)
GUICtrlSetFont($Message, 12)
GUISetState(@SW_DISABLE, $MainGUI)
GUISetState(@SW_SHOW, $LocalGui)
While 1
Switch GUIGetMsg()
Case $GUI_EVENT_CLOSE
$Return 0
Case $Doku
$Return 3
Case $Druck
$Return 4
Case $ERP
$Return 5
EndSwitch
WEnd
GUIDelete($LocalGui)
GUISetState(@SW_ENABLE, $MainGUI)
Return $Return
EndFunc
Alles anzeigen
Dein 2. Parameter ($MB_ABORTRETRYIGNORE) sperrt das X
Ich habe 13 Jahre mit einem Mitarbeiter zusammengearbeitet und immer mal wieder dessen Code debuggen müssen. Dabei saß ich immer neben ihm und habe genauestens erklärt was ich da mache und warum. 13 Jahre lang.....Mittlerweile ist es schon "viel" besser geworden, aber die Hilferufe kommen immer noch.....nicht mehr so oft, aber sie kommen?! Warum? Ich schreibe "Easy-Code", versuche nur die einfachsten Konstrukte zu benutzen, so dass jeder Dorfdepp in meinem Code lesen kann wie in einem Buch. Dafür musste ich mich vom Geschäftsführer einer (von uns verwendeten) führenden ERP-Branchensoftware als "Oldschool-Dinosaurier" bezeichnen lassen müssen. Die Retourekutsche drücke ich ihm jeden Monat wenn seine Jungs und Mädels als "Vollprofis" wieder mal programmiertechnischen Sondermüll abliefern. Wenn professionelle Datenbankspezialisten Funktionen abliefern die 1000x länger brauchen wie die eines "Freizeit-Oldschool-Dinosaurier"-Programmierers, dann sind wohl Nachfragen erlaubt. Genau wie danach, wieso gefixte Bugs nach diversen Updates "plötzlich" wieder auftauchen.....
Das erninnert mich an meine Azubi Zeit (Komm.Elektroniker), wo wir auch welche hatten, bei denen mann alles vorgeben mussten und kaum eine Schaltung ohne Fehler hin gebratzt haben und dann nicht mal in der Lage waren ihren Fehler selber zu finden (für mich war das wiederum eine gute Übung :P). Ich wunder mich bis heute wie die die Prüfung geschafft haben XD.
____
Btt: Warum ich das geschrieben habe: Wenn du Code nicht lesen kannst (weil schlecht angeordnet, oneliner etc.) wirst du ggf. Probleme haben ihn zu debuggen. Aber ich gebe dir Recht, die Basis von allem ist, den Code zu verstehen, nicht wie er "aufgeschrieben oder eingeordent" wurde.
Ich persönlich bin kein Freund von solchen Zeilen: #AutoIt3Wrapper_AU3Check_Parameters=-d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7
Die angezeigten "Fehler" sind zu 99% keine und während der Entwicklung von Programmen behindern sie mich und stören meinen "Flow" und die Kreativität. Imho sind diese Zeilen dazu geeignet, nach (!) der Erstellung eines lauffähigen Script dieses "schön" zu machen. Was mich als Privatanwender (auch wenn ich Scripte sehr oft im beruflichen Leben verwende) einen Scheiss interessiert! Form follows function....
Dem kann ich nicht zustimmen. Ich hatte bisher keine Fehler die nicht auch welche waren (und ja, das man eine Variable definiert aber faktisch danach nicht nutzt, ist meiner Ansicht ein Fehler, denn unnötiger Code). Und Kreativität gehört für mich nicht in den Code, sondern das Programm selber.
Wenn Beipiele wie oben (der Variablenname ist unterschiedlich, von dir selber aufgezeigt) auftreten, kann das durchaus ein Tippfehler sein wo diese Fehlermeldung drauf zeigt (solche Zeilen gehören dann auskommentiert oder korrigiert). Auch das man strickt drauf achtet, das Variablen deklariert werden und das auch im richtigen Kontext (kein Local im Global scope z.B.)gehört für mich nicht zum"schön machen", sondern zum kleinen 1*1, da sonst Variablen im Global auftauchen können, die da gar nicht hin gehören (in anderen Sprachen sogar ein MUSS), usw..
Code "schön" machen ist für mich eher, sich an Einrückungen zu halten, keiner mag oneliner hinzubratzen etc. wobei ich auch da eher auf "Lesbarkeit" als "Schönheit" verweisen würde.
Ja, es ist Ansichtssache und soll kein "blame" sein aber gewisse Grundregeln gehören für mich dazu, auch wenn man alleine am Code arbeitet.