Ich verstehe ehrlich gesagt noch nicht um was es geht.
Wie sehen die Eingabedaten aus, was stellen diese dar und wie sollen diese schlussendlich aussehen?
Es handelt sich vermutlich um einen Zeitstempel (positionTS). Nun stellt sich hier die Frage ob AutoIt oder das DBS den Integer falsch interpretiert.
AutoIt selbst hat den Hang dazu, große Zahlen nicht mehr vollständig darzustellen sondern beispielsweise als 4.2321e+123.
Allerdings sollte das bei 1430140978241 noch nicht passieren.
Das _Iif kann man sich seit einigen Versionen sparen und durch den ternären Operatoren ersetzen.
_Iif($a = $b, True, False) wird dann zu $a = $b ? True : False
Liegt es vielleicht an deinem PDF-Reader? Ich verwende Windows 7 64-Bit und nutze Chrome um die PDFs zu öffnen.
Hast du auch eine Datei womit man den Fehler reproduzieren könnte? Ein einfacher Test mit einer .txt Datei zeigt nämlich keinen Fehler.
[Blockierte Grafik: https://i.imgur.com/w7HK0rg.png]
Jetzt bin ich versucht, auch die Kurse zu kaufen wenn sie schonmal so reduziert sind 
Im AI Kurs gehts offenbar hauptsächlich darum eine AI selbst zu programmieren also würde ich das nach hinten schieben.
In den anderen beiden sehe ich persönlich keinen wirklichen Grund das eine dem anderen vorzuziehen. Es kommt nämlich in beiden jeweils Themen der anderen dran.
Da aber Deep Learning einen Teilbereich des maschinellen Lernens darstellt (und letzteres vorher schon da war), wäre meine Reihenfolge wohl:
1. Machine Learning
2. Deep Learning
3. Artificial Intelligence
Ginge es in AI nicht um die Programmierung sondern eher um das grobe Verständnis hätte man das logischerweise nach oben setzen sollen.
Bin aber interessiert wie andere das sehen, vielleicht macht eine andere Reihenfolge ja mehr Sinn.
Das sind Begriffe die ziemlich weite Felder umfassen, hast du eventuell eine Kursübersicht zu den einzelnen Kursen und könntest so abschätzen, welches gröber und welches feiner ist?
Dann könntest du dich von den Grundlagen zu den speziellen Themen vorarbeiten. Einige Themengebiete werden sich sicherlich dennoch überschneiden.
In diesem Fall, meiner Meinung nach, absolut vertretbar.
Aber wenn es später dazu kommt, dass man weitere Funktionen der WinAPI.au3 benötigt, muss man sich entscheiden ob man die Funktionen kopiert oder die bereits kopierten löscht und dann die gesamte UDF einbindet. Ich hatte das schon mehrmals mit GdiPlus und _GDIPlus_Get/SetPixel.
Meiner Meinung nach ist das kein guter Stil sich die benötigten Funktionen rauszukopieren, denn das bläht das Hauptscript nur weiter auf.
Wenn ich beispielsweise aus einer UDF 30 Zeilen Funktionen kopiere, hätte ich mir 27 davon (und die Mühe zum Kopieren) sparen können, indem ich den Au3Stripper verwende.
Achso, okay. Hat sich nur komisch angehört. Die Vorbereitungen kommen ja daher zustande, dass AutoIt eben keine eindeutigen Datentypen hat und alles dann für den Call angepasst werden muss.
Die Diskussion hatten wir glaube ich schon mal in der SB ob es sich lohnt, ein Include reinzunehmen, wenn man nur eine einzige Funktion braucht.
Ich glaube es gab sogar eine Option im Compiler die es ermöglicht die benötigten Funktionen aus einem Include zu extrahieren.
Das müsste /sf im Au3Stripper gewesen sein.
Ich habe gerade gesehen, dass _WinAPI_PathYetAnotherMakeUniqueName nur ein Dll-Call der shell32.dll ist.
Darf ich fragen was du erwartet hast? Alle _WinAPI_* Funktionen (vermutlich bis auf ganz wenige Ausnahmen) benutzen die WinAPI und diese sind nur in Dlls verfügbar.
Ein Blick in die WinAPI.au3 bestätigt das ganze.
_FFFormSubmit ( "print" )
_FFFormSubmit ( "service" )
_FFFormSubmit ( "Drucken" )
Schau dir mal die Dokumentation zu _FFFormSubmit an und was du in den ersten Parameter eintragen sollst, dann siehst du warum das damit nicht klappt.
.. muss aber dennoch am Umlaut liegen, siehe untenstehende Aufrufe, die nicht funktionieren bzw. funktionieren - suche daher weiter eine Lösung
Hol dir mal das Objekt des Anchors und lass dir mal anschließend den Text ausgeben (oder scripte die UDF ein wenig um damit sie dir das ausspuckt) um zu sehen, was der tatsächliche Text des Elements ist.
Er sollte sich vielleicht mal Parallels (oder wie das heißt) angucken, damit kannst du in Mac Windows virtualisieren, etwa so ähnlich wie VirtualBox.
Dann muss er keine separate Partition und den ganzen Krams dafür erstellen.
Jemand eine Idee wie ich das nun auf einen beliebigen in Windows eingebundenen Drucker senden kann?
Du könntest das Standardgerät ändern, drucken, und wieder zurückändern.
Ansonsten kannst du ja mal schauen ob Adobe Acrobat (falls du das installiert hast) eine CLI bietet und du dort den Drucker angeben kannst.
Ich selbst hab damit keine Erfahrungen gemacht aber mein Bruder hatte vor paar Jahren ein MacBook Pro und hatte sich wegen den Spielen Bootcamp mit Win7 draufgezogen.
Zu meinem Erstaunen lief alles ziemlich reibunslos ab. Es gab keine Treiberprobleme, alle Anwendungen haben ohne Probleme funktioniert und die Spiele nutzten auch die gesamten Computerressourcen.
Bootcamp drauf, Windows 7 installieren und die Treiber wurden schon teilweise von Bootcamp automatisch mitinstalliert.
Anders siehts aus wenn du einen Hackintosh betreiben möchtest, da hast du ziemlich viele Probleme aber Windows auf Mac läuft ohne Probleme,
zumindest was Windows 7 angeht, darüber hinaus bin ich überfragt.
Du schaust dir den Code im DOM-Explorer an und dort wird er schon gerendert. Das ü ist eigentlich ein HTML-Entity ü welches auch ersichtlich wird, wenn du
den Quellcode der Seite anschaust (bevor die Seite gerendert wird). Wenn du also das ü in deinem Code durch das Entity ersetzt sollte es klappen.
Die Umlaute sind bei einigen Charactersets notwendig, andere erlauben direkt den Einsatz von Unicode-Zeichen.
Du kannst auf Drucken nicht klicken, weil es sich dabei nicht um einen Anchor-Element handelt, vielmehr ist es ein Input-Element für HTML-Forms.
Da gibts mehrere Möglichkeiten das ganze zu bewerkstelligen, eine wäre die Form ausfindlich zu machen und sie zu submitten.
Das wäre diese Form:
<form class="gservprg" method="POST" action="/sonstiges/service/index.php" target="_blank">
<input type="hidden" name="service" value="print">
<input type="hidden" name="a" value="130604">
<input type="submit" value="Drucken">
</form>oder du holst dir (zumindest bei der IE.au3 geht das, ich weiß nicht wie es bei der FF.au3 geht) alle Elemente und iterierst die Collection.
Wenn du ein Element findest mit dem TagName "input" und dem type "submit" und dem value "Drucken" hast du dein gewünschtes Element.
Anderenfalls könntest du noch XPath verwenden (da habe ich allerdings absolut keine Ahnung) und nach dem value-Attribut suchen.
(c) Der DOM-Explorer ist schon ziemlich das beste was du HTML-Seiten kriegen kannst, ansonsten hast du noch die Möglichkeit den Quellcode direkt anzuzeigen,
oder mit dem Netzwerkprotokollierer die Pakete zu sniffen die zum Server hin und her geschickt werden (das ist aber eher was für WinHttp).
(d) Wenn die UDF keine Funktion dafür bietet wirst du da vermutlich nicht viel machen können (schon gar nicht wenn MozRepl nichts dergleichen anbietet).
Deine einzige Möglichkeit wäre wohl den Speicher des Programms auszulesen.
Eventuell kannst du das Problem ja umgehen indem du eine Firefox Instanz mit einem bestimmten Profil startest, du solltest mit ein paar Startparametern sicherlich das ganze steuern können.
Die Hilfe zeigt dir wie man Bilder einfügt, sie bietet dir nicht für jeden einzelnen Anwendungsfall ein Beispiel wie man es lösen kann, dafür bist du selbst zuständig.
Wenn du die Datensätze aus der Datenbank abfragen kannst, dann hast du sie auch im Script in einer Variable oder in einem Array gespeichert, also lies einfach besagte Variable oder Array aus und füge es mit dem entsprechenden Bild in die ListView ein.
Es gibt ein Beispiel in der AutoIt Hilfe zur ImageList und wie sie mit Bitmaps gefüllt wird, schau es dir doch mal an.
In deinem Beispiel ist aber der Code, welcher im DOM-Explorer auftaucht, mit dem identisch.
Wenn du uns nicht mehr Informationen liefern kannst wie die Seite aufgebaut ist oder uns einfach keinen Code zeigst können wir nur ins blaue hinein raten.
Warum sollte man sich den HTML Code nicht runterladen? Ist nicht schön aber ist mir halt so in den Sinn gekommen..
Du solltest den Code ruhig runterladen, aber dein Beitrag (so habe ich ihn verstanden) hatte es so ausgedrückt, dass du diesen Code speichern möchtest und das ist nicht gut.
Wenn der Webserver keine Probleme machen sollte und du nur HTTP Pakete mit GET statt POST abschickst sollte InetRead ausreichen, ansonsten brauchst du was anderes.
Alle Seiten der Traueranzeigen als HTML Code lokal speichern
Das hört sich so an als ob du alle Seiten speichern wolltest.
Warum eine .ini-Datei ? Hier kann man nur Key=Value Paare eintragen.
Fiel im sicher als erstes Speicherformat ein. Ist natürlich keine so gute Wahl.
Alle Seiten der Traueranzeigen als HTML Code lokal speichern
Bloß nicht, du solltest den HTML-Code nicht abspeichern wenn du ihn nicht brauchst.
Was hast du denn für Fertigkeiten? Willst du das mit der IE.au3 UDF machen, oder einfach nur mit InetRead, oder WinHttp?
Am besten du lädst die Seite und parst die Informationen raus, da kriegst du alle benötigten Informationen wie Name, Seitenzahlen etc.
Eigentlich? Ich hatte in meiner 1. Antwort bereits beschrieben warum das so ist. Im Script sollte das allerdings nicht passieren.
Sieht denn wirklich der Code der bei _IEDocReadHTML rauskommt aus wie der beim "Quellcode Anzeigen" im IE Fenster?
