Beiträge von Moombas
-
-
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):
AutoItOpt('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:
AutoIt
Alles anzeigenOpt('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
-
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:AutoIt
Alles anzeigenFunc 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
-
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.
AutoIt
Alles anzeigenOpt('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
-
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.
-
-
Naja Grundsätzlich teste ich Code auf diverse Weise.
Bei Funktionen (oder auch Units :P) kommt es bei mir auf den Anwendungsfall an, da:
- Ich mir die Funktionen step by Step zusammenbaue mit vielen Entwicklungsschritten und damit auch vielen Zwischentests um zu prüfen ob das jeweilig erwartete Ergebnis heraus kommt.
- es meißt viele Abhängigkeiten außerhalb des eigentlichen Skriptes gibt, wo ich auf Test-PC's arbeite aber somit oft nicht nur die Unit/Funktion prüfen muss, sondern das gesamte bis dahin erstellte Skript."Echte" Unit-Tests würde ich behaupten mache ich nur, wenn ich einen Ausgangsstring angeben kann der dann in Ergebnis X umgewandelt werden muss. Bei allem anderen eher wie oben beschrieben.
-
Gesamtspielzeit von aktueller Spielesitzung
Habe ich. Es geht um die Gesamtspielzeit seit ich jemals das Spiel gestartet habe. Führe dazu doch einfach mal mein Script aus. Wenn du weißt, wie es funktioniert, dann bitte erleuchte mich ^^. Ich bekomm es nicht hin.
Auch wenn man es leicht ändern kann und in deinem Fall überschaubar ist: ich für meinen Teil werde niemals fremden Code ausführen der (weder lesend noch schreibend) auf die Registry zugreift.