Beiträge von chesstiger

    Es ging beim Auslagern der Postings in einen anderen Thread lediglich darum, den ursprünglichen Sinn des Threads zu erhalten, nämlich eine Sammlung von nützlichen regulären Ausdrücken. Nicht direkt auf den Schlips getreten fühlen. ;)


    Bei dem Punkt mit der Erklärung gebe ich dir grundsätzlich recht. Auch der Tipp zu regex101 war gut. Aber genau für solche Zwecke gibt es mindestens ein gutes, deutschsprachiges Tutorial hier im Forum, welches auch auf die Unterschiede zwischen AutoIt-PCRE und dem Rest eingeht. Link hab ich leider gerade wegen nicht funktionierender Suchfunktion nicht parat. Darüber hinaus gibt es noch etliche andere gute RegEx-Tutorials in Englisch oder Deutsch, die zwar nicht auf AutoIt eingehen, aber dennoch RegEx an sich anschaulich vermitteln. Das ist imho auch der bessere Weg, eine formale Sprache wie RegEx zu lernen. Jeden Ausdruck in der angesprochenen Sammlung nochmal haarklein zu erklären macht deswegen wenig Sinn und erzeugt eher Overhead. Wer RegEx (meinetwegen dank des Tutorials) kann, braucht es nicht. Und zum Lernen und Verstehen der Ausdrücke nützt eine komplette Erklärung ob der Komplexität und den fehlenden Grundlagen vermutlich auch eher wenig.


    P.S.:

    Eigene Beiträge in Foren in der Art zu löschen ist unhöflich. So kann man später nicht mehr nachvollziehen, was warum geschrieben worden ist. Man nimmt der Diskussion den Zusammenhang. In einem echten Gespräch kann man ja auch nicht einfach ganze Sätze im Nachhinein rausstreichen.

    Hi,


    ich bin im Rahmen eines größeren Projektes mit AutoIt auf ein kleines Problem gestoßen. Konkret betrifft das das Thema Subclassing, also Veränderung der internen Nachrichtenverarbeitung eines Fensters (und damit Controls). Dazu gibt es grundsätzlich mehrere Möglichkeiten. Man kann einmal die Subclassing-API verwenden, man kann aber auch simpel über SetWindowLong die WndProc verändern (siehe Code). Ich präferiere eigentlich die zweitere Möglichkeit, weil die Subclassing-API bei mir immer mal wieder Probleme verursacht hat.


    Nun stehe ich jedoch vor dem Problem, dass beim Ersetzen der WndProc scheinbar AutoIts internes Nachrichtenhandling nicht mehr greift. Das heißt, ich kriege weder im OnEvent-Modus noch über GUIGetMsg() irgendwelche Aktionen mit dem Control mit. Auch ein Minimalbeispiel zeigt, dass das Problem nur beim Ersetzen der WndProc auftritt, nicht beim Nutzen der Subclassing-API. In den jeweiligen WndProcs/SubclassingProcs kommt jedoch die entsprechende Klick-Nachricht korrekt an. Übersehe ich etwas, oder geht hier AutoIt-Intern was gewaltig schief?


    Zunächst: Was ist eine ID? Nicht zwangsläufig ein aufsteigendes Nummernfeld. Eine Software, die wir im Haus verwenden, nutzt beispielsweise einen Hash aus UserId, Timestamp und Objektdaten. Da ich gar keine rein numerische ID habe, die sich aufsteigend bildet, kann ich Datensätze beliebig tauschen, ohne Angst vor doppelten IDs haben zu müssen.

    Wann immer ich in AutoIt mit TCP-Verbindungen hantiere, nutze ich Kips TCP-UDF. Diese basiert auf Events, d.h. du registrierst eine Funktion für ein Ereignis (bspw. Datenempfang), die dann von der UDF aufgerufen wird. Das finde ich wesentlich angenehmer zu programmieren. Dort gibt es auch die Möglichkeit, ein Verbindungsabbruch-Ereignis zu registrieren. Ich weiß nicht, wie Kip das intern umgesetzt hat, aber wenn du die Info in AutoIt irgendwie bekommen kannst, dann wird diese UDF das auch weiterreichen. Einfach mal probieren:


    https://www.autoitscript.com/f…325-tcp-udf-event-driven/

    Hm, vielleicht habe ich da einen anderen Grad an Professionalität im Kopf.

    Wir hatten einen einzigen Computerraum mit insgesamt 14 Clients. Sind in meinem letzten Schuljahr alle auf Windows 8.1 umgestellt worden. Das waren einfache Desktoprechner mit Unterklasse-Ausstattung. Darauf lief dann wie bereits gesagt Windows in einer Home-Variante, nicht mal Pro (d.h. keine Domänenfunktionen). Zur Absicherung haben wir praktisch nur uralte PC-Wächter-Karten gehabt, mehr nicht. Der Switch war so ein TP-Link-Ding, ohne smarte Funktionen. Da haben wir auch sehr viel mit AutoIt-Skripten administriert, vorher (=> die AutoIt-Skripte habe ich in der 9. Klasse programmiert) wurde Turnschuh-Administration gemacht, d.h. bei einem Update von LibreOffice hat der zuständige Lehrer einen kompletten Nachmittag geopfert und jedes Update an jedem Rechner von Hand installiert.

    Aber auch wir haben schon Prüfungen an diesen Rechnern geschrieben, damals noch auf Windows XP. Das war aber vor der Zeit, in der ich aktiv bei der Administration mitgewirkt habe. Lief damals über eine Software namens NetSupport School.

    War bei uns nur begrenzt der Fall. Heißt: Die Verwaltung hatte zwar ein separiertes Netz, welches auch mit intelligenten Switches unterteilt war, aber wir (mit Wartung beauftragte Lehrer und Schüler) hatten nur Zugriff auf unser abgekapseltes Subnetz, ohne an die Switches zu dürfen.


    Gut, das passiert ja hoffentlich, bevor Schüler den Raum betreteten. Sonst könnte man ja auch einfach den Au3-Prozess, der gpupdate ausführt, abschießen.

    Das kannst du auch nicht. Das ist der von mir angesprochene Informationsverlust. Du kannst aus Tagen nicht wieder Monate oder Jahre machen.


    Du musst bei der Differenzbildung schrittweise bei der größten Einheit (Jahre) anfangen. Wenn das nicht mehr geht, mit Monaten weitermachen usw...


    So kann man das schön simpel machen:

    Edit:


    Kurz nochmal der Algorithmus in Worte gefasst. Mag effizienter gehen, aber so habe ich es auf einem Blatt Papier auch gelöst.

    1. Beginne bei Einheit Jahren.

    2. Addiere so lange 1 Einheit auf das Startdatum, bis es bei der nächsten Addition größer als das Enddatum wäre. Zähle dabei die Additionen.

    3. Ausgehend von dem neuen Startdatum wiederhole Schritt 2 mit der nächstkleineren Einheit, bis keine nächstkleinere Einheit mehr existiert.

    4. Die gezählten Additionen sind der Abstand der beiden Daten.

    Naja, wer als Schüler die per GPO vorgegebene lokale Firewall aushebeln kann, der hat's auch verdient, zu spicken. :D


    Grundsätzlich ist eine Hardware-Firewall natürlich besser geeignet, obwohl auch diese umgehbar ist. Aber verglichen mit einer reinen Software-Lösung (vorhandenes AD vorausgesetzt) steht hier ja ein anderer Kostenfaktor im Raum. Ich weiß noch, was es für ein Krampf war, in der Schule Anträge für neue Hardware durchzubekommen. Und ich war schon Mitglied in allen wichtigen Gremien wie SchuKo usw... Ich könnte mir schon denken, was für eine Diskussion bei 400 Euro für einen Switch mit Firewall fällig wären.

    - Per zentraler Firewall

    Den Vorschlag finde ich tatsächlich am besten. Wenn ihr bei euch an der Schule schon so Microsoft-verbunden seid, dann habt ihr ja mit Sicherheit nicht nur 20 Client-Rechner in einem Raum stehen, sondern es existiert auch irgendwo ein Windows Server und ein Active Directory. Falls ja, würde ich einfach bei Bedarf über eine Gruppenrichtlinie die Firewall-Einstellungen auf den Zielrechnern so einstellen, dass ausschließlich Verbindungen zum DC und zu *.microsoft.com (o.Ä.) hergestellt werden dürfen. Per AutoIt könnte man dann noch ein gpupdate auf den Zielrechnern durchführen, weiß nicht, ob das zwingend nötig ist. Das ist allemal besser als selbstgeschriebene Frickellösungen. Und eine Gruppenrichtlinie in einem AD bekommt man ohne administrative Rechte auch nicht so schnell ausgehebelt.


    Wir haben damals in der Schule viel mit der Windows Firewall administriert und gearbeitet. Es gab bspw. eine Software aus dem Fachbereich Biologie, deren Hersteller mittlerweile insolvent gewesen ist. Allerdings hat die Software bei jedem Start versucht, den Herstellerserver nach Updates zu fragen. Allerdings war da ein Timeout von ~10 Minuten gesetzt. Nervig ohne Ende. Also einfach die Verbindung zu diesem Host per Firewall deaktiviert und fertig, Programm startet ohne Verzögerung. ^^

    weil ich nicht weiß, wie Schaltjahre etc. einzurechnen sind

    Das ist - glaube ich - das größte Problem. Du hast bei der Angabe X Jahre, Y Monate, Z Tage zwangsläufig mit einem Informationsverlust zu kämpfen. Selbst nach alpines' Methode (die an sich eigentlich die richtige Lösung darstellt) unterscheidest du nicht zwischen normalen Jahren und Schaltjahren, geschweige denn nach Monaten mit unterschiedlich vielen Tagen (es wird pauschal 30 Tage angenommen).


    Deshalb wird das nicht die gewünschte Genauigkeit erbringen. Wenn ich dich richtig verstehe, möchtest du ja, dass bspw...

    - zwischen dem 1.1.2015 und dem 2.1.2016 genau 1 Jahr, 0 Monate und 1 Tag liegen.

    - zwischen dem 1.1.2016 und dem 2.1.2017 genau 1 Jahr, 0 Monate und 1 Tag liegen. (2016 ist ein Schaltjahr, d.h. das eine Jahr sind 366 Tage)


    Richtig?

    Dann ist TimerInit/TimerDiff nicht das richtige für dich. Speichere dir einen Timestamp (entweder a la "yyyy-mm-dd hh:ii:ss" oder als UNIX-Timestamp) und berechne die Differenz zu jetzt mit den Date*-Funktionen.

    Korrekt, beim Namen liegt ein großes Problem der Sache. Ich habe einige PDF-Drucker getestet, bekomme als Originaldokumententitel allerdings immer "PDF.js" (der Name des Chrome-internen PDF-Viewers). Daher die Notlösung, mit pdftotext im Dateiinhalt zu schauen.


    Andy

    Eine Automatisierung des ERP-Systems ist grundsätzlich möglich, klar. Allerdings handelt es sich um ein Rolling-Release-System (mehrere Updates pro Woche), welches auch noch beim Anbieter gehostet wird. Das heißt, ich habe praktisch keine Möglichkeit, Updates zu verhindern. Eine Automatisierung der Oberfläche bedeutet daher extrem viel Wartungsaufwand. Der Aufwand als solches hält sich bei uns allerdings in Grenzen. Mitarbeiterin steht im Lieferschein, klickt auf das kleine Drucker-Icon => PDf-Vorschau des Beleges wird angezeigt, Systemdruckdialog plopt automatisch auf. Wenn der richtige Drucker bereits ausgewählt ist, reduziert sich der Aufwand also auf 2 Klicks, was ich für okay halte.


    BugFix

    Ja, unsere Damen sind an dem Punkt auch sehr verwöhnt. IBM AS/400 und textbasierte Warenwirtschaft lässt grüßen. Bisher haben die Damen den entsprechenden Druckbefehl eingegeben (bspw. drucke LS 5344 oder drucke alle noch nicht gedruckten Rechnungen), dann hat das System selber entschieden, welchen der Drucker es angesteuert hat (Nadeldrucker für LS, Nadeldrucker für RE, Laserdrucker für Protokolle). Die meisten unserer Bürodamen empfinden die manuelle Druckerauswahl also als extremen Rückschritt.

    Generell haben wir auch ein Problem damit, herauszufinden, ob ein Beleg wirklich gedruckt worden ist. In der AS/400 wusste das System genau, ob der Job schon an den Drucker weitergeleitet worden ist (Ansteuerung über TwinAx-Kabel). Im neuen ERP geht das natürlich nicht, der Browser bekommt ja keine Rückmeldung. Und wenn eine Dame sich beeilen wollte und u.U. den Druckdialog NACH Erzeugung der PDF abgebrochen hat, wird der Beleg trotzdem als gedruckt markiert. Da verliert man bei >400 Lagerbelegen am Tag schon mal die Übersicht, dann geht auch was verloren. Dafür habe ich auch noch keine elegante Lösung.

    Hi,


    ich hatte das Thema in der SB ja schon mal angeschnitten, aber es wohl wirklich zu umfangreich, um dort geklärt zu werden. Daher nochmal hier.


    Mein Problem

    Wir benutzen seit dem 24.09.2018 ein neues ERP-System, welches komplett im Browser (bei uns generell Chrome) läuft und beim Anbieter gehostet wird. Das heißt, Modifikationen direkt am ERP-System sind nicht möglich. In diesem ERP-System erzeugen wir sämtliche Belege als PDF-Dateien, also (u.A.) Auftragsbestätigungen, Lagerbelege (Kommissionierzettel), Lieferscheine und Rechnungen. Da wir aber keine klare Trennung zwischen unseren Büroabteilungen haben, nimmt eigentlich jeder Mitarbeiter Aufträge telefonisch entgegen und schreibt auch gleichzeitig Lieferscheine und Rechnungen. Die Problematik liegt jetzt beim Drucken der so erzeugten Belege. Alle Rechnungen und Lieferscheine werden auf Drucker A im Büro gedruckt, bestückt mit unserem Briefbogen. Alle Lagerbelege werden auf Drucker B im Lager gedruckt, damit die Kommissionierer diese direkt von dort bearbeiten können. Und - wie sollte es anders sein - wird natürlich regelmäßig vergessen, den richtigen Drucker zu wählen.


    Bisheriger Lösungsansatz

    Aus eigenem Antrieb und auf Anraten einiger User hier habe ich versucht, den Umweg über einen PDF-Drucker zu nehmen (in meinem Fall 7-PDF). Das sollte wie folgt funktionieren: Die Damen drucken IMMER auf dem PDF-Drucker, dieser schmeißt den Ausdruck als PDF immer ins selbe Verzeichnis. Dieses Verzeichnis wird dauerhaft von einem AutoIt-Skript überwacht, welches anhand des Dateinamens den Druck auf dem richtigen Drucker anstößt. Das ist schon relativ umständlich, finde ich. Erschwert wird das ganze noch durch die Tatsache, dass der PDF-Drucker nicht den Original-Dateinamen weitergeben kann. Ich habe also im Moment folgende (lauffähige) Konstruktion: ERP -> PDF-Drucker -> AutoIt-Skript -> xpdfs pdftotext (Rausfinden des Belegtypes) -> Sumatra-PDF (stilles Drucken). Das sind also alleine schon drei externe Softwarekomponenten PLUS mein Skript. Ich hätte da gerne eine standsicherere und elegantere Lösung, um ehrlich zu sein.


    Vom Wunschdenken her wäre ein Dummy-Druckertreiber das Mittel der Wahl. Oder ein Chrome-Plugin, welches den Drucker passend wählt. Oder, oder, oder... Es gibt sicherlich einige Möglichkeiten. Aber ich habe noch nichts anderes realisiert bekommen, mal von der bereits genannnten Lösung abgesehen. Fällt noch jemandem was ein?

    Das ist so ziemlich eins der ersten Sachen im Kapitel GUI-Programmierung in jedem Tutorial lernt. Zu sagen, das man nichts passendes gefunden hat kann ich da nicht glauben.

    Ist jetzt zwar etwas Off-Topic, aber: Jeder lernt anders. Ich schreibe zwar gerne Tutorials, aber selber welche lesen? Fehlanzeige. Lieber rumprobieren und so dazu lernen. Copy&Paste aus dem Netz, dann Zeilen oder Parameter verändern, beobachten, was passiert etc... Wenn ich mich richtig erinnere, war meine erste Frage in diesem Forum, wie man die Id eines Controls bekommt. Auch nicht viel besser. ^^

    Man könnte auch den direkten Weg gehen. Im Header einer ausführbaren Datei ist vermerkt, für welchen Prozessortyp sie gedacht ist. Das kann man einfach aus einer Office-Datei auslesen. Dann pfuscht einem auch nicht diese SysWOW64-Redirect-Geschichte da rein.


    Müsste so eigentlich gehen.