Beiträge von Andy

Zitat von WhiteLion

dass ich in meiner 64bit kompilieren anwendung bytecode erzeugen lasse, den ich per klick als 32 oder halt 64 bit bitcode ausgeben lasse. (den code an sich und nicht starten oder sowas)

Also nochmal deutlich:
Die Fasm.dll assembliert sowohl 64-Bit- als auch 32-bit-Code!
Die Frage stellt sich, was eine 64-Bit Anwendung macht, die lediglich assemblieren soll?! Assembliere im 32-Bitmodus und alles ist paletti!

Zitat von WhiteLion

das doppelte kompilieren kommt für mich irgendwie auch auch nicht in frage,

Ich vermute stark, du verstehst garnicht was überhaupt vor sich geht...
Grundsätzlich wird nichts kompiliert, sondern assembliert.
Und "doppelt" wird auch nichts assembliert, sondern nur ein Mal.
Im "1. Durchgang" wird der 64-Bit-Code assembliert. Das kannst du, jedenfalls mit der von mir vorgestellten Lösung mit der im Script integrierten Fasm.dll nur im 32-Bit-Modus.
Das braucht man genau ein einziges Mal, um den Assemblercode zu assemblieren. Ich hab ja keine Ahnung, ob du jedes Mal, bevor du ein Programm startest, dieses Programm kompilierst, ich mach das nur ein einziges Mal, dann habe ich meine Exe...

Der "2. Durchgang" schaltet in den 64-Bit-Modus, damit der 64-Bit-Code überhaupt läuft! Wenn du lediglich assemblieren willst, brauchst du das natürlich nicht!

Da im FASM-Paket sowohl FASM.EXE (der Assembler), als auch FASMW.exe (mit integriertem Editor, den benutze ich) enthalten ist, sei die Frage erlaubt, wieso du nicht damit deine ASM-Codes assemblierst? In AutoIt ist das ein Einzeiler!

Vielleicht solltest du uns in einigen Sätzen einfach mal erklären, was du genau mit deinem Code machen möchtest bzw. wieso du diese AutoItlösung fürs assemblieren brauchst. Das erspart allen Beteiligten das rumgeeiere...

Zuerst mal vielen Dank!

Ja, Excel erstellt diesen Code, ich habe mir schon fast gedacht, dass da nicht viel zu machen ist...

Dort HTML-Code selbst zusammenzubasteln bzw. selbst zu generieren ist unnötig, in VBA ist das ein 3-Zeiler, der aus einem Bereich einer Tabelle eine HTML-Datei bastelt.

Der VBA-Code liest Daten aus mehreren Excel-Sheets, schreibt einige Dateien, die wiederum von einem Drittprogramm ausgewertet werden, welches von AutoIt gesteuert wird^^
Letztendlich werden die diversen Bestellungen und Auswertungen/Ankündigungen per Mail und als Fax aus Excel (natürlich auch per VBA ^^) versendet. Fax ist kein Thema, das funktioniert über einen "Drucker" welcher die Tabellen auf eine Seite zusammenfasst (skaliert).
Bei Mail gäbe es die Möglichkeit von Attachements ( Userunfreundlich) , oder eingebetteten Bildern (viel zu viel Speicherbedarf) oder eben als schlanke HTML-Mail. Da hat mir die HTML-Mail am besten gefallen, allerdings lassen sich die Tabellen nicht skalieren. Na gut, dann muss ich mal versuchen die Zellgrößen gleich kleiner zu machen^^

Zitat von rynow

Eigentlich baut man in der heutigen Zeit ein HTML Konstrukt immer so auf, dass es sich automatisch an jedes Display anpasst, daher ist das mit skalieren total unsinnig...

Ja, habe schon "Viewport" gefunden, um unabhängig von den Bildschirmgrößen die gleiche Ansicht zu erhalten, aber das scheint nicht mit Mails zu funktionieren, sondern nur in "richtigen" Browsern?!

Hi,
schau mal nach AssembleIt bzw. AssembleIt2
AssembleIt2 hat die Fasm.dll integriert und bietet auch noch weitere "goodies", allerdings noch nicht den integrierten Debugger aus AssembleIt.

Beispiele für 64-Bit-Code gibts hier,

Die FASM.dll kann sehr wohl 64Bit-Code assemblieren, kann allerdings selbst nicht im 64-Bit-Modus geladen werden (trancexx´s Methode die dll aus dem Script in den Speicher zu laden funzt nur bei 32Bit)
Da du aber sowieso nur den Bytecode benötigst, macht das nichts...

Hier noch kleine Testdateien
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Wer sich wundert, warum es ein AssembleIt2-32 gibt, das ist exakt dieselbe Version, allerdings ist dort das Laden der FASM.dll "außerhalb" der Funktion untergebracht, das spart je Aufruf bei meinem Rechner 100ms.
Da somit AssembleIt2() nur 2-3ms Overhead für einen Aufruf hat(in diesen 2-3ms wird assembliert und der code ausgeführt!!!! ), lohnt sich das assemblieren und der folgende DllCallAddress() nur noch in Ausnahmefällen (oder wenn man seinen Code schlank halten muss...)
Den Unterschied sieht man deutlich im Beispiel mit der Farbpalette, dort bei der #include <assembleit2-32.au3> einfach mal das -32 wegmachen...

Hi zusammen,

ich versende Ausschnitte aus Excel-Tabellen per VBA als HTML-Emails.
D.h. Teile der Tabelle werden als HTML-File gespeichert, welches ich in einer Email verpackt versende.
Das funktioniert einwandfrei, allerdings ist die Darstellung des HTML-Codes in der Email etwas "groß".

Nun habe ich (in Ermangelung tiefergehender HTML-Kentnisse) nach Lösungen zum "skalieren" von HTML-Seiten gesucht, aber nichts passendes gefunden.
Am nächsten wäre wohl das hier http://www.html.de/threads/komple…59/#post-300271
Aber da weiss ich nicht, wie ich diesen "Trick" mit meiner Seite umsetzen muss!
Es geht darum, die gesamte Seite auf ca. 50% der ursprünglichen Größe zu schrumpfen.

Anbei Beispieldatei, wie sie von Excel erstellt wird:

Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

//EDIT
Es geht mir darum, mit einigen zusätzlich einzufügenden Zeilen (oder kleineren Änderungen am Code) die gesamte Seite "kleiner" zu bekommen!

Moinz Raupi,

glücklichen Herzwunsch und alles Gute zum Geburtstag!

Lass es ordentlich krachen und halt den Hammer nicht still

entweder select/case oder , weil einfacher, als Einzeiler

$verz=stringupper(Stringleft(GUICtrlRead($combo1),3))

Glücklichen Herzwunsch und alles Gute!

+1

Funktionen mit #define

Zitat von Techmix

Obwohl ich im Kernel 'if (Local_NotReplace[j] != i)' verwende wird an dieser Position das Ungleich '!=' völlig übergangen und das resultierende Array wir nicht korreckt aufgebaut.

Puuuhhh, ich weiss ehrlich gesagt nicht, ob und wie != in OCL verwendet wird^^

Zitat von AspirinJunkie

Der benötigte Speicher des Skriptes steigt bei 100000 Durchläufen um gerade einmal 2,3mb an, wovon schonmal 0,76mb die Handles ausmachen sollten.

Ich habe per ProcessExplorer und auch per Taskmanager nicht ein einziges Handle mehr angezeigt bekommen! Also während meine Schleife lief.
Das bestätigt nur was ich bereits sagte, dass die Dll nur einmal geladen wird. Die gesammelten "Handles" werden also nur auf ein einziges (das der geöffneten Dll) gemapped. Macht auch Sinn!

Zitat von AspirinJunkie

Tja was ein vergessenes DllClose() nicht alles ausmacht...

Made my day
Erzähl das den Leuten die ihren kompletten Speicher mit Handles füllen...

Zitat von Kanashius

wobei in einer schleife 2x ispressed aufgerufen wird) auf über 2GB Ram hochgeschaufelt

Nach deiner Feststellung mit der linear ansteigenden Zeit würde mich jetzt echt mal interessieren, wie lange bei 2Gb "Handles" der DllOpen() braucht und wie lange bis dahin die gesamte Scriptlaufzeit ist.
Habe das lineare Ansteigen mal ausprobiert und über den dicken Daumen interpoliert:
100000 Durchläufe , der letzte DllOpen() dauert bei mir 0,8ms, sagen wir mal eine, dann lässt es sich schöner rechnen
100000 Durchläufe entsprechen ca. 1mb Handles (lässt sich auch schöner rechnen)
Um 2 GB mit "Handles" zu füllen bräuchte man 2000mb, macht 2000*100000 = 200E6 Durchläufe, die "letzten" Schleifendurchläufe würden also nur für das DllOpen zwei Sekunden benötigen! Die Summe Zeit bis dahin insgesamt ist imho das Integral unter der linearen Funktion. Na das bekomme sogar ich noch hin Die Fläche ist 1/2 *Durchläufe * 2 Sekunden, also 200E6 Sekunden! Sind lange 6 Jahre...
Bei einem Sleep von 30ms bei GuiGetMsg() pro Schleifendurchlauf sind das zusätzlich 6E9 ms = 6E6 Sekunden also nochmal ca. 3 Monate.

Mit dieser Info, dass also nach 6,25 Jahren ununterbrochener Scriptlaufzeit der Speicher vollläuft, kann ICH sehr gut leben
Im Umkehrschluss heisst das nichts anderes, dass es garnicht sein kann, dass ein "vergessenes" DllClose() den Speicher vollschreibt!
Oder der Rechner unseres Kollegen ist 1000x schneller als meiner und benötigt daher statt 6 Jahren nur 2 Tage. Bei einem Rechner dieser Leistungsklasse hat man aber ganz andere Software laufen als ein Script mit 17 Zeilen, 3 Variablen und _IsPressed()
Hmmm....oder es läuft ein Bot im Hintergrund, der mit dem Script gesteuert werden soll. Und in DEM ist das Speicherleck
Hehe, wir kriegen EUCH ALLE! ALLLEEEE!!!!

DAS ist wesentlich interessanter^^

### Messergebnisse bei 100000 Durchgängen ###
Implizit: 4611.10374 ms (0.04611 ms pro Durchgang)
Explizit: 30235.99960 ms (0.30236 ms pro Durchgang)

;Explizite Öffnung durch DllOpen
$hTimer2 = TimerInit()
For $i = 1 To $iLoops
$hDll = DllOpen("user32.dll")
_IsPressed("0D", $hDll)
Next
;DllClose($hDll)
$nTimer2 = TimerDiff($hTimer2)

Mal angenommen, DU wärest der Vorgesetzte des Programmierers der Routine die dafür sorgt, eine bereits im Speicher befindliche Dll NICHT zu laden. Und würdest den Typen jetzt fragen, wie man ca. 700000 Prozessortakte für diese Abfrage "verballern" kann! Das sind auf heutigen Maschinen 700000 Instruktionen....

@chesstiger,
"im Prinzip" gebe ich dir Recht!
Wenn ich dich jetzt aber mal beauftrage, mir ein gestartetes Windows BS zu zeigen, in dem genau diese Dll gerade NICHT geöffnet ist, wirst du merken, wieso ich "im Prinzip" meinte.
Schau dir einfach mal an, welche Funktionen sich in dieser Dll befinden.

@Kanhasius,
der Sinn und Zweck einer Dll ist, dass sie nur EINMAL gleichzeitig geöffnet wird, unerheblich, wie viele Programme die Funktionen nutzen wollen. Das geschieht innerhalb des BS und ist imho auch nicht beeinflussbar. Ansonsten wäre das gesamte Dll/Bibliotheken-Prinzip völlig Schwachsinnig!
Daher kann ich mir viel vorstellen, aber definitiv NICHT, dass hunderte Kopien der user32.dll GLEICHZEITIG im Speicher stehen...

@sedas19,
man braucht die dll nicht explizit zu öffnen. Ein Blick in die Funktion hätte gereicht...

Func _IsPressed($sHexKey, $vDLL = 'user32.dll')
; $hexKey must be the value of one of the keys.
; _Is_Key_Pressed will return 0 if the key is not pressed, 1 if it is.
Local $a_R = DllCall($vDLL, "short", "GetAsyncKeyState", "int", '0x' & $sHexKey)
If @error Then Return SetError(@error, @extended, False)
Return BitAND($a_R[0], 0x8000) <> 0
EndFunc ;==>_IsPressed

@MaxChri
dein Script funktioniert bei mir Win7-64 und 3.3.10.2 einwandfrei. AutoIt ist installiert als 32-Bit-Version.

ööööhhh, das hatten wir doch schon...
Über die String-Dekompression
Im Verlauf dieses Threads ist auch das von mir verwendete Kompressions/Dekompressionsverfahren beschrieben.

Zitat von Lausbube

$wmi_obj liefert bei mir einfach nichts zurück

Was heisst "nichts"?
Ich erhalte im Fall einer nicht erreichbaren Adresse kein Objekt zurück, im Fall einer erreichbaren Adresse ein Objekt.

$flag = 1
For $ip1 = 90 To 94 Step +1
For $ip2 = 35 To 254 Step +1
$flag = Not $flag
If $flag Then
$ip3 = "192.168." & $ip1 & "." & $ip2
Else
$ip3 = @IPAddress1
EndIf
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ip3 = ' & $ip3 & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

Local $wmi_obj = ObjGet("winmgmts:{impersonationLevel=impersonate}!\\" & $ip3 & "\root\WMI")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $wmi_obj = ' & $wmi_obj & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
If IsObj($wmi_obj) = 1 Then
MsgBox(4096, "Juhuuuu", "Test erfolgreich " & $ip3, 1)
Else
MsgBox(0, 0, "Adresse " & $ip3 & " ist nicht erreichbar!", 1)
EndIf

Next
Next

Funktioniert bei mir einwandfrei!
Die Frage ist, was du erwartest. Bei mir dauert deine Abfrage im Fall einer nicht erreichbaren Adresse 25 Sekunden.

schnell mal getippert...ist ja "nur" eine simple Bitmap, die in der Datei steckt. Lediglich zum Bestimmen der Parameter mussten einige Bytes gezählt werden. Hexeditor FTW!

hehe, wie wärs, beim Editieren des Kernels auf die F5-Taste zu hämmern und in der Console steht das Log oder "Kernel ohne Syntax-Fehler compiliert!"

Hi,
das kann doch niemals klappen!

Zitat von Ilse

_ArrayDisplay($Name) ; zeigt z.B. 10 Einträge beim ersten Durchlauf
; zeigt z.B. 13 Einträge beim zweiten Durchlauf, die sollten ngehängt werden!

Wenn mehrere Adressfelder gefunden werden, dann muss man je nach Anzahl der vom RegEx gefundenen Ergebnisse den Text aufbauen!
Jedenfalls ist suboptimal, dass im 11. Post plötzlich von ADRESSEN gesprochen wird, im 1. Post steht nur was von NAMEN! Und wenn ich dann lese

Zitat von Ilse

$Text = "Suche1Hans MüllerEnde1,Suche2HauptstrasseEnde2,Suche366554Ende3,Suche4HamelnEnde4"; hier kommen die Ergebnisse her!
$Name = StringRegExp($text,'Suche1(.*?)Ende',3)
$Strasse = StringRegExp($text,'Suche2(.*?)Ende',3)
$Plz = StringRegExp($text,'Suche3(.*?)Ende',3)
$Ort = StringRegExp($text,'Suche4(.*?)Ende',3)

dann ist das ehrlich gesagt QUARK, denn offensichtlich gibt es mehrere Adressdaten im zu durchsuchenden Text!
Somit ist Oskars Beispiel zwar richtig, aber für den von Ilse gesuchten Anwendungsfall nur eine "Speziallösung" (bei genau EINER gefundenen Adresse! )
Also Ilse, bitte beim nächsten Mal nicht nach mehreren Lösungsvorschlägen mit dem "Problem" rausrücken, sondern schon im Startpost, das macht es allen Beteiligten wesentlich einfacher!

Letzter Versuch, zusammengeklaubt aus den vorliegenden Informationen....

nein, die Variable p hatte ICH eingebaut, um die Warnung zu provozieren
Und ja, der Compiler wirft diese Meldungen!
Sehr aussagekräftig jedenfalls!
Was hälst du davon, wenn als Rückgabe einer Funktion _CL_CheckKernelSyntax($kernel) das Logfile zurückgegeben wird. Im optimalen Fall (kein Fehler/Warnung) wird ein Leerstring zurückgegeben, ansonsten das Log. Ggf. sollte man drüber nachdenken, die Warnungen auch auszublenden und nur bei "echten" Fehlern das Log zurückzugeben.