Beiträge von Moombas

    @TE hast du deinen Fehler mittlerweile gefunden? Ich glaube das ein Fehler hier liegt:

    Code
    1. Switch $tmp
    2. Case 6 ; JA, verschieben der jpgs
    3. FileMove(($source & $jjjjup & "\" & $proup & "\Berechnungen\*.jpg"), ("F:\TESTUMGEBUNG\SERVER\Daten\Dokumente\" & $jjjjup & "\" & $proup & "\Fotos\"), $FC_OVERWRITE + $FC_CREATEPATH)
    4. copyup()
    5. Case 7
    6. copyup();NEIN, kein verschieben, Daten werden komplett verschoben in AD Ordner
    7. Case 2 ; CANCEL, Programmabbruch
    8. Exit ;Warum schließt du das ganze Programm an dieser Stelle? Im Prinzip müsstest du dir Case 2 sparen können (Cancel = keine Aktion, das Programm bleibt aber offen)
    9. EndSwitch


    Wo ich mir nun nicht sicher bin: Löst das "Schließen" der MsgBox das $GUI_EVENT_CLOSE aus? Wenn ja, solltest du für das Beenden des Programms einen extra Button einführen der dein Programm beendet und

    Code
    1. Case $GUI_EVENT_CLOSE
    2. Exit

    entfernen.

    Dazu kann ich selber nichts sagen aber ein anderer "Logikfehler" ist bei dir zu finden (meiner Meinung nach):

    In der Kopierfunktion "Func copydown()" scheibst du folgendes:

    Code
    1. Local $CopySuccess
    2. $CopySuccess = DirCopy(($source & $jjjjdown & "\" & $prodown & "\Berechnungen"), ($dest & $jjjjdown & "\" & $prodown & "\Berechnungen"), $FC_OVERWRITE)
    3. DirCopy(($source & $jjjjdown & "\" & $prodown & "\Katasterunterlagen\Risse"), ($dest & $jjjjdown & "\" & $prodown & "\Katasterunterlagen\Risse"), $FC_OVERWRITE)
    4. ConsoleWrite('< DirCopy = ' & $CopySuccess & @CRLF)
    5. If Not $CopySuccess Then
    6. MsgBox(16, "Ergebnis von DirCopy : ", "Die Kopieraktion ist fehlgeschlagen ! ")
    7. Else
    8. MsgBox(64, "Ergebnis von DirCopy : ", "Die Kopieraktion war erfolgreich ! ")
    9. EndIf

    Du prüfst ob das kopieren erfolgreich war, Das gilt aber nur für den ERSTEN Kopiervorgang. Ob der Zweite erfolgreich war, weißt du nicht! Mein Vorschlag (basierend darauf, das DirCopy bei Erfolg als Wert "1" zurück gibt und bei Fehlschlag "0"):

    Code
    1. Local $CopySuccess
    2. $CopySuccess = DirCopy(($source & $jjjjdown & "\" & $prodown & "\Berechnungen"), ($dest & $jjjjdown & "\" & $prodown & "\Berechnungen"), $FC_OVERWRITE)
    3. $CopySuccess = $CopySuccess + DirCopy(($source & $jjjjdown & "\" & $prodown & "\Katasterunterlagen\Risse"), ($dest & $jjjjdown & "\" & $prodown & "\Katasterunterlagen\Risse"), $FC_OVERWRITE)
    4. ConsoleWrite('< DirCopy = ' & $CopySuccess & @CRLF)
    5. If $CopySuccess <> 2 Then
    6. MsgBox(16, "Ergebnis von DirCopy : ", "Die Kopieraktion ist fehlgeschlagen! " & $CopySuccess & "/2") ;Ggf. noch einfügen: & " Kopierfehler: " & @error
    7. Else
    8. MsgBox(64, "Ergebnis von DirCopy : ", "Die Kopieraktion war erfolgreich ! ")
    9. EndIf

    Danach solltest du sicher sein, das beide oder maximal ein Kopiervorgang erfolgreich war.

    Deine Abfrage ist ja auch verkehrt (Die Korrektur gibst du dir eine Zeile drüber schon vor):

    Code
    1. Func Abfragen()
    2. ;MsgBox(0, "", GUICtrlRead($sComputer))
    3. printerInfo($sComputer)
    4. EndFunc

    Müsste die nicht so heißen:

    Code
    1. Func Abfragen()
    2. printerInfo(GUICtrlRead($sComputer))
    3. EndFunc

    Oder bin ich jetzt verkehrt?

    @EL: Ich habe in meinem vorigen Post mal ein Beispiel angehängt. und ich (für meinen Teil) würde an deiner Stelle select Case nehmen anstatt switch.


    Warum:

    Select..Case:

    Zitat

    If the expression is true the following statements up to the next Case or EndSelect statement are executed. If more than one of the Case statements are true, only the first one is executed.


    Switch..Case

    Zitat
    An expression that returns a value. The value from the expression is then compared against the values of each case until a match is found. This expression is always evaluated exactly once each time through the structure.


    Bei Select wärst du damit aus meiner Sicht auf der sicheren Seite UND wenn er ein passendes Case gefunden hat, prüft er nicht weiter.

    Zur Abfrage der Buttons etc.: Schau mal hier: https://www.autoitscript.com/a…s/functions/GUIGetMsg.htm


    Mit GUICtrlSetState und dem Status $GUI_DISABLE/$GUI_ENABLE kannst du genau das machen.

    Du musst diese States beim Klick auf die Checkbox setzen.

    Dafür musst du deinen Labels etc. aber beim erstellen Namen zuweisen!

    Also z.B.: $NAME= GUICtrlCreateLabel("Erwarte Dateneingabe...",45,385,180,20,BitOr($SS_CENTER,$SS_CENTERIMAGE),-1) damit du drauf zugreifen kannst.

    Und dann GUICtrlSetState($NAME, $GUI_DISABLE) bzw GUICtrlSetState($NAME, $GUI_ENABLE)

    ... Ich kann eben die Leistung heutiger integrierter Grafikchips nicht einschätzen. ...

    Für normale Office-Anwendungen & reines Internet surfen reichen On-Board Karten aus. Sobald du 3D Rendering, Phys-X etc. brauchst kommst du um eine "normale" Graka nicht herum. Auch beim schauen von ((U)HD-)Videos / Streams kann es bei einer onBoard-Karte zu rucklern kommen, habe ich bisher aber selten gesehen. Ich selber würde dir, zumal du auch FlugSim spielst, zumindest zu einer LowBudget Graka raten, die diese Techniken mitbringt bzw. es würde auch nichts dagegen sprechen diese nachzurüsten falls notwendig oder?


    Die günstigste AMD kostet ~43€ bzw. Nvidia ~34€, das wäre doch nun wirklich nicht die Welt. Da ich aber weder deinen FlugSim kenne (evtl. nimmst du diesen als Maßstab für die Graka), weiß ich nicht ob du hier höher greifen müsstest, da du aber überlegst evtl. nur die Onboard zu nutzen, glaube ich schon das diese deinen Anforderungen gerecht würden.

    BugFix : Ja ich habe SciTe neu gestartet (mehrfach) :( Habe zum testen extra einer Variable die Deklaration genommen, aber leider keine Fehlermeldung. Trage ich es direkt ein bzw. über Abbrev, dann funktionierts. Das ich eine bestehende .au3 verwende und keine neue dürfte ja egal sein odeR?


    Musashi : Ich bin diese Prüfung eigentlich generell gewöhnt (Pascal -> Delphi) und kenne es so, das Variablen deklariert werden MÜSSEN, bevor sie verwendet werden. Aktuell ist heute ein Skript auf Fehler gelaufen, weil eine Variable durch eine Besonderheit an einem PC nicht deklariert wurde -> Fehlermeldung im Skript.


    Das würde ich gerne generell vermeiden und wenn ich bei Foren-Skripten halt Variablen nachdeklarieren muss, wäre ja eigentlich sogar sauberer :P



    Nachtrag: Wenn ich JETZT versuche Opt("MustDeclareVars", 1) einzutragen, ändert er es in Opt("MustDeclareVars", 0)!



    Nachtrag 2: Ich habe in deiner Au3OptMustDeclareVars.lua den Eintrag local mustdeclare = tonumber(props["Opt.MustDeclareVars.au3"]) or 0 geändert in local mustdeclare = tonumber(props["Opt.MustDeclareVars.au3"]) or 1. Jetzt gehts!

    Also vorerst schon mal Danke, das du dich meinem Problem angenommen hast :D


    Aber irgendwas mache ich noch falsch. Eingefügt habe ich

    SciTEUser.properties (als letzte Zeile): Opt.MustDeclareVars.au3=1

    SciTEStartup.lua (am Ende, nach "EventClass:BeginEvents()"): LoadLuaFile("Au3OptMustDeclareVars.lua")

    Au3OptMustDeclareVars.lua in den lua Ordner von SciTe


    Beim Kompilieren bekomme ich jedoch keine Warnung.

    Andy : Bezüglich der Steckplätze: Weißt du VORHER wie viele Steckplätze der Fertig-PC hat? Im optimalen Fall wird beim RAM MITTLERWEILE angegeben wie viele Steckplätze das Board hat und wie viele belegt werden, das war aber auch mal ganz anders! Zusätzlich weißt du so gut wie nie wie viele Steckplätze die Graka blockiert (durch Verwendung von 2 oder mehr Slots).


    Bezüglich Harmonisieren: Hier hatte ich bisher keine Probleme. Wir reden hier von PC's für "Normalos" und von keinem High-Precision-PC wo das letzte Quäntchen Leistung rausgeholt wird (das wirst du wie selber geschrieben auch beim Fertig-PC nicht vorfinden. Wenn deine Aussage stimmt (war mir auch neu), ja eher im Gegenteil um Strahlungswerte einhalten zu können.

    Habe bisher immer auf die Details bei Prozessor, Mainboard, Arbeitsspeicher etc. geachtet (Was für eine Taktfrequenz kann der Prozessor (beim RAM), welches das MB und welchen Arbeitsspeicher habe ich in dem Bereich zur Verfügung usw. usw.) und daher habe ich hier bisher keine Kompatiblitätsprobleme gehabt. Ich bin das erste mal ein wenig in Verlegenheit gekommen, wo ich die erste SSD verbaut habe aber auch das ließ sich durch Literatur lösen, selbes galt für ein Crash Problem mit dem aktuellen Ryzen 7 (da ich eigentlich nur Intel nutze, aber der Ryzen schneidet aktuell einfach zu gut ab) auch hier nach kurzer Suche die Problemstelle gefunden (Win10 BIOS-Setting machte Probleme) und beseitigt. Auch mit der Zeit habe ich mich z.B. auf bestimmte Hersteller "fixiert", einfach weil ich hier gute Erfahrungen gemacht habe und keine Probleme bekommen habe, das hat sich bisher immer bewährt.

    Ich baue die PC's in der kompletten Familie nach Bedarf zusammen und je nach Anforderungen unterschiedlichste Systeme (ohne manuelles OC) und bin bei techn. Fragen (auch außerhalb von PC's) oft der erste Ansprechpartner. Bisher waren alle glücklich und mir macht das Schrauben Spaß.


    Dein Extrem-Beispiel ist natürlich sagen wir typisch für "möchtegern" Typen, die am besten den PC auf dem Teppich schön mit statischer Aufladung umbauen und sich später wundern warum das System muckt. Sollte ich sowas mitbekommen, ist die Entscheidung schnell gefällt: DIY (Do-It-Yourself), da mutwillig selbst verschuldet, ist aber bisher bei mir im Bekanntenkreis nicht der Fall, eher (zu) vorsichtig und einmal mehr Fragen (hab sie gut erzogen :rofl:).


    Zum Rest: Ich habe mir zugegebenermaßen nicht den ganzen Text durchgelesen aber viele der von dir hier angesprochenen "Probleme" kann ich bisher nicht bestätigen. Weder das eine Graka nicht lief/erkannt wurde noch das Problem mit Kurzschlüssen. Gut, ich arbeite mit Erdungsband und wenn mal eine Schraube flöten geht, wird kein Strom eingeschaltet, solange bis sie gefunden wurde.


    Natürlich sollte jemand der gar keine Ahnung hat lieber bauen LASSEN, wenn man aber bereit ist sich mit der Materie auseinander zu setzen. Man sollte durchaus wissen wie viel Wärmeleitpaste man nutzen muss bzw. ab wann es zu viel ist usw. Wenn man damit nicht aufwarten kann -> durch den Shop zusammen bauen lassen und glücklich sein.

    Mal ganz davon abgesehen: Viele (Online-)Shops bieten auch an die zusammengestellte HW zusammen zu bauen (natürlich für €) oder bei den über die Konfiguratoren zusammen gestellten diese auf Stabilität zu prüfen etc.. In wie weit sich das lohnt oder Vertrauenswert ist, fehlt mir selber jede Grundlage da ich immer selber zusammenbaue. Aber für einen "Normalo" evtl. eine Alternative.


    Für mich gilt: Nie wieder einen fertig PC bei dem man nicht mal den RAM nachrüsten kann oder eine Festplatte (von den anderen bereits genannten Punkten mal abgesehen) weil einfach keine freien Steckplätze existieren.

    Zudem ist mir es ein graus, wenn ich die Kabelführung bei diesen Dingern sehe (auch bei denen, die man zusammenbauen lässt im (Online-) Shop). Da kann ich dann gleich von Anfang an selber Hand anlegen.


    Meiner Meinung nach spart man beim selber (zusammen-)bauen nicht, aber man weiß was man hat und (normalerweise) das die Komponenten miteinander Harmonieren und ob / wie viel man aufrüsten kann.


    ...

    Es gibt im "normalo"-Segment keinen Grund mehr, selbst zu bauen. Ich kann mir ein mit meinen ausgesuchten Komponenten funktionierendes System mit Garantie und allem Schnickschnack zusammenbauen und am nächsten Tag liefern lassen, und das für einen Mehrpreis, der 1-2 Stunden Zeitungsaustragen entspricht.

    ...

    Andy : Auch beim selber zusammenbauen hast du Garantie auf jede einzelne Komponente! Das kann durchaus auch ein großer Vorteil sein, da man die Garantie direkt beim Hersteller abwickelt und ggf. Sondergarantien hast (siehe z.B. bei Samsung SSD's) wo du mehr als 2 Jahre bekommst. Die würdest du beim Fertig-PC NICHT bekommen.

    Andy : MEines wissens muss ab (spätestens) Win7 bei Mainboard wechsel (anderes Modell) auch Win7 neu installiert werden. Mit XP ging das noch aber wir müssen unsere Festplatten seit Win7 Hardwaregenau installieren. Dann würde das mit dem Win7-Image nicht fuktionieren, da er ein anderes MB erwartet.

    Dafür gibt es zig Ansatzmöglichkeiten. Ich hätte beim Aufruf des Logging die Parameter als einen String übergeben.


    Deine Elseif Variante funktioniert aber nur wenn du nur EINE Funktion hast die EINEN Parameter hat, das gleiche gilt für 2,3,4,5,N-Parameter.


    Hier mal mein Beispiel wie man das individuell umsetzen könnte (ungetestet!):

    Wie ich das sehe sagt die Funktion:



    Nicht aus, das du die Control ID des geklickten Controls bekommst, sondern dem über dem der Cursor aktuell ist. Daher müsste er dir die ID vom Button (der den "autoklick" auslöst) bekommen, was ja auch so ist, wenn ich dich richtig verstanden habe.


    Der Unterschied ist einfach ein virtueller Mausklick (MouseClick(); Cursor bleibt wo er ist) vs. tatsächlicher Mausklick (Benutzereingabe; Cursor wird zum Ziel bewegt). Daher kannst du dies nicht mit GUIGetCursorInfo() auslesen.


    Wenn du den Cursor mittels MouseMove() an die Position bewegst und dann GUIGetCursorInfo() machst, müsste er dir dir die richtige ID ausspucken. (Tipp: Erst MouseMove(), dann MouseClick(), dann GUIGetCursorInfo() ) Habe ich selber aber auch noch nicht getestet, daher keine Gewähr!


    -----------------------------------


    Mal anders gefragt: Wozu brauchst du das? du kannst doch beim drücken von Button 2 die Funktion _button1() einfach aufrufen. Warum der komplizierte Umweg über einen Mausklick?

    Wichtig dabei: Bedenke, je nachdem wie oft Funktionen aufgerufen werden etc. das deine Log-Datei immens groß werden wird!

    Ein wenig eingrenzen könntest du es nur, wenn du nur an den Stellen loggst, an denen Fehler auftreten (Siehe 3.).


    Dann kannst du das Error-Logging als Funktion schreiben, die du bei einem Fehler aufruft. Zu Übergebene Werte wären dann z.B.:

    1. Funktionsname + aktueller Arbeitsschritt
    2. dafür notwendige Parameter mit Namen
    3. das "falsche" Ergebnis
    4. @error (falls vorhanden)

    Vorteil: Kleinere Log-Datei mit weniger (scheinbarem) Datenmüll

    Nachteil: Bei einem Programmabsturz weist du nicht wo er war, da das Logging hier meist nicht mehr greifen kann.

    Also generell kommt es viel darauf an was/wie du Programmierst. Also wie oft werden Funktionen aufgerufen etc.

    Machst du bei deinen Arbeitsschritten (wo es möglich ist) Prüfungen? Wenn ja kannst du diese auch mit loggen, wenn nein warum nicht?


    Generell kannst du eine Logdatei schreiben, in die du alles rein schreibst.


    Du könntest z.B. einen "Debug-Modus" per Ini oder so setzen, wenn der gesetzt ist, wird geloggt, sonst nicht oder du loggst generell um bei Programmabstürzen oder -fehlern immer eine Log-Datei zur Hand zu haben.


    Meine Empfehlungen:

    1. Dauerlogging betreiben
    2. Wenn du eine Funktion aufrufst, schreibt die Funktion als erstes z.B. "Function AB start" und als letztes "Function AB ende". Damit grenzt du einen Ausfall meistens schon mal auf eine Funktion ein.
    3. Alles was man prüfen kann, ob es erfolgreich war oder einen Fehler gab -Prüfen! Dieses dann loggen entweder egal ob Fehler oder nicht oder nur die Fehler mit dem Fehlerwerten (alle Werte die hierzu gehören!).
    4. Und ansonsten liegt es an dir was du mit loggst oder nicht, aber diese Stellen musst du schon selber einprogrammieren, ich wüsste aktuell keine Logik oder .au3 die sowas selber erkennt/erkennen könnte und halte das auch für unmöglich.


    Zuletzt stellt sich die Frage, wie du die Log-Datei handeln willst (beim Dauerlogging):

    - Nach jedem Programmstart wieder neu?

    - Ein Archiv über x Log-s?

    - Alles was älter ist als x-Tage löschen?

    - ...

    Ich bin jetzt natürlich nur von deinem letzten Post ausgegangen und da füllst du $sPaket ja in der genannten Abfrage, welche ich hier in eine While-schleife gepackt habe, damit diese so lange immer wieder befüllt wird.


    Aber ich merke gerade, so würdest du immer wieder auch den Loginversuch neu starten. Dürfte also nicht funktionieren. Theoretisch müsste es also so heißen:


    Code
    1. $sPaket = _WinHttpSimpleSSLRequest($hConnect, 'POST', '/LaenderEANV_Web/registrierung', 'https://leanv.zks-abfall.de/LaenderEANV_Web/registrierung?action=displaylogin', $sPOST)
    2. $timeout = 0
    3. while $sPaket = "0"
    4.     sleep(500)
    5.     $timeout = $timeout + 1
    6.     if $timeout = 40 then ;Nach 20 Sekunden Abbrechen
    7.         ;Fehlermeldung ausgeben
    8.         Exitloop
    9.     Endif
    10. WEnd

    ABER: Ich weiß nun nicht, ob sich an diesem Punkt $sPaket noch ändert.