Beiträge von alpines

  • ChildGUI - zweite While-Schleife freezed random komplette Anwendung

    Zitat von borsTiHD

    Ist das wechseln im Script zwischen GuiGetMessage/OnEvent nicht teufelszeug?

    Kann man schon machen, aber man verliert schnell den Überblick darüber, welche Fenster klickbar sind und welche nicht.

    Wenn man schon wechselt, sollte man darauf achten, dass alle anderen Fenster versteckt oder disabled sind, da ansonsten die Events nicht verarbeitet werden.

    Aber es ist nach wie vor das alte Problem, UDFs sind nicht konsistent. Einige arbeiten lieber mit einer Messageloop, einige widerum mit dem OnEventMode.

    Gäbe es eine einheitliche Wahl würde dieses Problem nicht existieren.

  • Email VersandSystem für Gutscheine

    Zitat von Springstil

    Wie lange würde es dauern das zu machen?

    Das kommt ganz darauf an wie die Daten aufbereitet sind und vorliegen.

    Das Versenden der Mails an sich sollte kein Problem sein, da gibt es z.B. CDO.Message (Objekt) um damit über SMTP-Nachrichten zu verschicken (auch SSL-verschlüsselte).

    Wenn ihr aber Outlook schon installiert habt und von dort eure Mails abschickt kann man auch direkt die Outlook UDF verwenden, dann sollte das ganze etwas besser laufen als direkt mit dem Objekt.

    Dann das ganze zu kopieren sollte denke ich kein Problem sein.

    Wenn man sich ein Bild von der Situation gemacht hat sollte das nicht länger als ein paar Stunden (<10h) Arbeit sein um das ganze zum Laufen zu bekommen.

    Zitat von Springstil

    Was würde das Kosten?

    Das ist immer unterschiedlich, und variiert stark je nach dem ob du mit Stundenlohn bezahlst oder einen Festpreis ermittelst. (Dazu kommen ja noch etwaige Updates, Bugfixes, etc).

    Zitat von Springstil

    Das ganze würde nur für ca ein Jahr genutzt denn dann wird das alles über unsere Webseite gesteuert.

    Bekommt ihr dann das Interface schon gestellt oder wird es erst dann programmiert? Ihr könntet doch direkt auf die Webvariante gehen und spart euch den Umweg über eine Exe oder sehe ich das falsch?

  • ProcessExists für einzelne Benutzer

    Zitat von Springstil

    Für mich dann doch ein wenig Kompliziert

    Das ist ja wohl die faulste Ausrede die ich seit langem gehört habe, du gibst dir ja nicht mal Mühe das ganze zu verstehen.

    Der Hauptgegentand ist die For-Schleife in dem die Prozesse aufgelistet werden, hast du das Skript nicht mal ausgeführt?

    Alles was du machen musst ist nur die Prozessliste durchgehen und zu prüfen ob der Username mit dem übereinstimmt den du vergleichen willst, das sind vielleicht 2 Minuten Arbeit.

  • ProcessExists für einzelne Benutzer

    Zitat von Springstil

    Das würde mir ja auch nichts bringen, da das Programm ja geschlossen wurde aber das Script läuft ja weiterhin.

    Wenn es ein externes Programm ist kannst du das auch über WMI machen, hier mal ein Thread aus dem blauen Forum. https://www.autoitscript.com/forum/topic/94…user-or-system/

    Dort kriegst du den Usernamen des Benutzers angezeigt der den Prozess ausgeführt hat.

  • ProcessExists für einzelne Benutzer

    Zitat von Springstil

    Was macht denn _Singleton genau?

    Ein Blick in die Dokumentation genügt:

    Zitat von _Singleton

    Enforce a design paradigm where only one instance of the script may be running

    Es erlaubt dir dein AutoIt-Skript nur einmal pro System am laufen zu haben. Das $sOccurenceName ist dabei der Identifikator.

    Du nimmst als Identifikator einfach den Benutzernamen und versuchst das Skript zu starten, startet es mit einer Fehlermeldung von _Singleton weißt du, dass der aktuelle Benutzer es noch benutzt.

    Startet es ohne Fehlermeldung, weißt du, dass es nicht läuft und kannst es beenden und dich ausloggen.

  • Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis"

    Ich hoffe es stört nicht, dass ich doppelt poste, aber so kannst du einfacher zu den Themen verlinken die du in den ersten Beiden Beiträgen angeschnitten hattest.

    TreeView DeleteChildren-Bug/Inkonsistenz (Win7 x64 - Au3: 3.3.14.5)

    Hier wurde einfach schlecht programmiert.

    Einige _GUICtrlTreeView-Funktionen akzeptieren das Standard-AutoIt-TreeViewItem (welches man mit der ID anspricht) aber DeleteChildren sträubt sich da, der Grund ist auch "schnell" gefunden.

    Einige Funktionen rufen nämlich intern noch _GUICtrlTreeView_GetItemHandle auf und arbeiten mit dem hWnd des Controls weiter, allerdings passiert das bei _GUICtrlTreeView_DeleteChildren nicht.

    Übergibt man kein hWnd (also einfach nur die ID vom Standard-TreeView-Control), so wird der Else-Zweif in der Funktion ausgeführt und als $lParam von GUICtrlSendMsg wird die AutoIt-Interne-ID eines Items weitergegeben.

    Das selbe Problem sollte auch beim Nicht-Else Zweif auftreten, allerdings muss man dann GUICtrlGetHandle um das TreeView packen und das Item normal übergeben was niemand machen würde.

    Code
    Func _GUICtrlTreeView_DeleteChildren($hWnd, $hItem)
    Local $bResult
    If IsHWnd($hWnd) Then
        $bResult = _SendMessage($hWnd, $TVM_EXPAND, BitOR($TVE_COLLAPSE, $TVE_COLLAPSERESET), $hItem, 0, "wparam", "handle")
    Else
        $bResult = GUICtrlSendMsg($hWnd, $TVM_EXPAND, BitOR($TVE_COLLAPSE, $TVE_COLLAPSERESET), $hItem)
    EndIf
    Return $bResult
EndFunc

    Allerdings erwartet $TVM_EXPAND als $lParam ein hWnd (einen Pointer!) und keine AutoIt-Interne-ID.

    AutoIt erkennt das nicht automatisch und so wird als lParam einfach die ID gesendet welches auf einen ungültigen Speicherplatz zeigt und folglich das Control nicht gelösht werden kann.

    Fix: GUICtrlGetHandle verwenden wenn man Items an _GUICtrlTreeView_DeleteChildren versendet, dann übergibt man nämlich einen Pointer.

    Oder man setzt vollständig auf die UDF und verwendet kein einziges Standardcontrol, dann bräuchte man ehrlich gesagt aber die Tausend Abfragen nicht die in der UDF enthalten sind (die die Standardcontrols akzeptierbar machen).

    Dass hier, $TVM_EXPAND zum löschen mit $TVE_COLLAPSERESET verwendet wird, will ich mal außen vor lassen, bei mir erzeugt das einen visuellen Bug.

    Das [+] vor dem "A" verschwindet nicht, obwohl das Item keine Unteritems mehr hat und man es auch nicht mehr expandieren kann.

  • Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis"

    Tolle Aktion :thumbup:

    Damit das jeder nachvollziehen kann hier der Code zum TreeView-Bug / "-1"-Bug (Win7 x64 - Au3: 3.3.14.5)

    Es wird eine $hMainGUI erstellt die angezeigt wird. Diese dient als Haupt-GUI und öffnet die TreeView GUI und nachdem die TV-GUI angezeigt wird, @SW_DISABLEn wir die Haupt-GUI.

    Nun können wir wahllos Items anklicken und neue Unteritems spawnen lassen und es taucht eine neue GUI von _ArrayDisplay auf.

    Diese schließen wir und versuchen neue Items zu spawnen, dies ist allerdings nur auf den Items möglich die schon existierten.

    Spawnen wir ein Neues Item und versuchen mit dem Klick auf das Neue Item "Neu" wieder ein neues zu spawnen schlägt das fehl,

    denn das Event wurde nicht gesetzt. Da im GUICtrlCreateTreeViewItem kein -1 auftaucht sondern mit der Variable gearbeitet wird wird das Item zumindest erstellt.

    Der Bug ist also der, dass das Setzen von Events (oder andern Sachen die mit -1 funktionieren) auf Controls nicht funktionieren, die korrekt erstellt wurden,

    während eine andere GUI "aktiv" war. Denn das -1 bezieht sich immer auf das letzte Control und inklusive auf die letzte "aktive" GUI. (Aktiv im Sinne von SetState benutzt und nicht unbedingt Controls darauf erstellt!)

    Und nicht wie es überall in der Hilfe steht nur auf das letzte Control.

    Zitat von autoitscript.com - GUICtrlSetOnEvent

    The control identifier (controlID) as returned by a GUICtrlCreate...() function, or -1 for the last created control.

    Der Grund dafür ist, dass das -1 im GUICtrlSetOnEvent auf das falsche Control der falschen GUI zeigt (sollte eigentlich immer auf das letzte Control zeigen).

    Verwenden wir aber nun statt dem -1 die Variable mit dem ID des Controls werden auch bei den neuen Items wieder neue erstellt obwohl die GUI von ArrayDisplay auftauchte.

    Mit dem -1 klappt es nur wenn wir GUISwitch verwenden.

    Btw: Das TreeView-Begin/EndUpdate ist nicht zwangsweise notwendig, allerdings erscheinen die [+] nicht sofort (visuell) wenn man es nicht drin hat.

  • Bild öffnen per Fernwartung

    Welches Skript willst du denn anpassen? Wie sind die Geräte vernetzt? Sowas solltest du schon mitliefern.

    Ansonsten kannst du PSEXEC nehmen und dort die benötigten Informationen (Dateiname, User/Passwortkennung) übergeben und es wird ausgeführt.

  • Vom Dateityp zur Dateiendung

    Zitat von misterspeed

    Versteh das Problem ehrlich gesagt nicht so ganz.


    Um eine Liste und Pfade aller Dateien des Desktops zu bekommen benötigt man lediglich die Funktion _FileListToArray. Hier kann man bei Bedarf auch nach Dateien / Ordnern und bestimmten Dateiendungen wie "*.txt" filtern, oder aber man wertet das Array eben selbst aus wenn auch Dateien mit anderen Endungen verschoben werden sollen.


    Um die Pfade für den eigenen Desktop / AllUser Desktop oder auch Desktop eines spezifischen Users zu ermitteln sind folgende Makros hilfreich:

    Das hatte ich bereits in der SB vorgeschlagen, aber es geht wohl um den Zugriff auf das Desktopcontrol.

    Meiner Meinung nach kann man diesen Teil aber hervorragend über die entsprechenden Funktionen auslagern.

    Wenn man nun auch noch das Datum vergleicht (oder die Größe) hat man die richtige Datei (bei verschiedenen Endungen aber dem gleichen Typen).