Sei doch mal kreativ.
Was du schon wieder verlangst! ![]()
Ich verwende als Trennzeichen meist ein Nicht-Text Zeichen: Chr(7)
Ich gerne CHR(255), das kann man im Editor (auch Hexeditor) schön sehen
Sei doch mal kreativ.
Was du schon wieder verlangst! ![]()
Ich verwende als Trennzeichen meist ein Nicht-Text Zeichen: Chr(7)
Ich gerne CHR(255), das kann man im Editor (auch Hexeditor) schön sehen
Hi,
just my 2...
Anfangs empfand ich Perseus als schlanke, feine, intelligente Alternative, so wie es sich aber der allgemeinen Featuritis der Programmiersprachen angepasst hat, ist/wird es imho nur ein weiterer Supertanker.
Nix gegen VS, aber dann kann ich gleich in den "Visual-Sprachen" incl. -NET programmieren und muss mir nicht etwas "neues" an den Hals binden!
Wie ist das Feedback, einen weiteren C#/C++ - Clone am Start zu haben?
Gefühlt mit dem selben (oder sogar weniger ?! )Aufwand hättest du einen nativen AutoIt-Compiler erstellen können! ![]()
@NOTHING,
wenn du konkrete Hilfe brauchst, sag Bescheid!
Manchmal sieht man den Wald vor lauter Bäumen nicht, und dann benötigt man nur einen kleinen "Stupser". Wenn man sieht, dass sich jemand mit einem konkreten Problem beschäftigt, ist man wesentlich motivierter zu helfen...
Im umgekehrten Fall ist es aber so, dass hier kaum ein User eine "spezielle" UDF komplett von oben bis unten durchkaut, nur um jemandem "den Arm aus der Sonne zu legen"
. Das zeigt die Erfahrung hier im Forum.
Wenn du dein Problem beschreibst, bleibt die Hilfe sicher nicht aus!
@Alina,
ich weiß nicht, mit welchem Programm du die Funktionen innerhalb einer DLL darstellst.Ich benutze dafür entweder einen Debugger, bspw. die Free-Version von IDA PRO, oder einen Viewer.
Da ich aber mit dem Debugger direkt die Aufrufkonventionen bzw. auch die Anzahl und den Datentyp der Parameter "sehen" kann, ist das mein Favorit.
Ein 08/15-Viewer zeigt mir bspw. folgende Funktionen innerhalb einer DLL:
Hi,
heruntergeladen und entpackt einwandfrei, nach dem Start sieht man aber nur ein weißes, leeres Fenster.
Keine Fehlermeldungen, keine Ausgabe in der Konsole.
Fenster wird erstellt und zentriert.
//EDIT Win7/64
Hi,
ohne Array, wenn man eins benötigt, hilft StringSplit()
#include <Array.au3>
[/autoit][autoit][/autoit][autoit]Global $TEMP
Global $sLangerText
$sLangerText = "Ein sehr langer Text mit vielen Zeichen und vielen Worten der nicht so richtig passen will! Aber der soll hier rein und am besten auf die zweite Zeile!"
[/autoit][autoit][/autoit][autoit]$TEMP = LineBreak($sLangerText, 40)
MsgBox(262144, 'Debug line ~' & @ScriptLineNumber, 'Selection:' & @LF & '$TEMP' & @LF & @LF & 'Return:' & @LF & $TEMP) ;### Debug MSGBOX
Func LineBreak($sText, $iLengthMax,$replace = @CRLF)
$sText_ret = "" ;returnstring
$pos = 1 ;Startposition für den $iLengthMax langen String im Text
Do
$mid = StringMid($sText, $pos, $iLengthMax) ;Text-Block
If StringLen($mid) < $iLengthMax Then $replace = " " ;letzte Zeile, dann Leerzeichen nicht ersetzen
$sText_ret = $sText_ret & StringReplace($mid, " ", $replace, -1) ;letztes Leerzeichen im Block ersetzen
$pos = $pos + $iLengthMax ;nächster Block
Until $mid = "" ;so lange, bis kein Block mehr vorhanden ist
Return $sText_ret
EndFunc ;==>LineBreak
@NOTHING,
wer hindert dich daran, selbst Funktionen zu erstellen / zu erweitern und hier der Allgemeinheit zur kostenlosen Verfügung zu stellen?
Und bei dieser Gelegenheit den Error zu fixen?!
Dein Problem der PDF-Erstellung kann demnach so groß nicht sein, ansonsten hättest du schon einige Stunden Programmiererei in die UDF investiert und hier zur Diskussion gestellt, statt für dich "zufriedenstellende" Lösungen zu suchen....
Hi,
das kommt davon, wenn man nicht richtig liest bzw. etwas hereininterpretiert, was nicht dort steht. Oder auch nicht beachtet, was die eigentliche Funktion zurückgibt:
Zitat von aus der HilfeRückgabewert
Erfolg: Gibt die Position des Unterstrings zurück.
Und die Position wird bei von links nach rechts schreibenden Kulturen schon IMMER von links gezählt.
Und wer lesen kann ist klar im Vorteil! In der zitierten Hilfezeile steht EXAKT was passiert:
Das wievielte Auftreten des Unterstrings soll gefunden werden.
Bingo, die Position des Suchstrings wird zurückgegeben.
Vielleicht verwirrt, dass zwar von rechts gesucht, die zurückgegebene Position aber von links gerechnet ist.
Naja, da ich weiß, dass du die sprachlichen Feinheiten durchaus beherrschst
, schlage doch mal vor, wie man die POSITION des Unterstrings besser beschreiben kann als in der aktuellen Hilfe. Und wie man die SUCHRICHTUNG (die mit der Position nichts zu tun hat) davon trennt.
/whispermode ON
Ich vermute einfach, dass das trotz deiner Mühe genau so viel nützen würde wie die vielen anderen Hinweise in der Hilfe (und nicht nur dort) auch, nämlich nichts! Man muss nicht nur lesen können, sondern auch verstehen. Egal, aber wenigstens ist dem TE zu Gute zu halten, dass er die Hilfe gelesen hat. Die Sache mit dem VERSTEHEN der Sätze, das üben wir dann noch
/whispermode OFF
@'Donsen64
Eine Lösung wenn trotzdem von rechts gesucht werden soll ist folgende:
$iPosTrennzeichen = StringInStr(StringReverse($sText), " ")
Gruß Ingo
Urgs, DAS ist genauso falsch. Es wird immer noch von links GESUCHT, lediglich die POSITION wird von rechts angegeben. Du solltest dir Gedanken darüber machen....
Übrigens muss nicht der gesamte String zeitaufwendig umsortiert werden, ein simples
$test="Organisation"
[/autoit][autoit][/autoit][autoit]$pos_von_links=stringinstr($test,"a",1,-1) ;Position letztes "a"
$pos_von_rechts=stringlen($test)-stringinstr($test,"t",1,-1)+1 ;stringlen() kostet nur einige Takte
Übrigens wurde das Suchen von rechts deshalb implementiert, um bei "großen" Strings die Laufzeiten extrem zu beschleunigen. (Das casesense-Flag bringt den Speed! )
Wenn man in einem 500MB großen Text-String die 12.-letzte Zeile sucht, oder in einer großen Bitmap das letzte rote Pixel, DANN macht das Suchen von rechts sehr wohl Sinn. Und es wird auch die m.E. "sinnvolle" Position zurückgegeben. Denn genau diese Position wird von den Stringfunktionen (bspw. StringInStr(), StringMid(), StringLeft() )verwendet.
Hi,
ich hab da vor kurzem ein Tutorial von jemandem hier im Forum gelesen, der schreibt, dass es mittels einer bestimmten Programmiertechnik sehr einfach ist, bspw. Controls zu erstellen und diesen dann bestimmte Eigenschaften zuzuweisen.
In seinem Tut hat er das sehr Anschaulich mit einem Button gemacht, ich denke, das wäre der richtige Ansatz für dich...
Kannst dich ja mal damit befassen, ist echt interessant!
Hi,
ich hatte gefragt, weil ich unter XP eigentlich keine Probleme mit "fehlenden" Funktionen hatte. Nagut, bissl esoterisches Gedöns, aber da es sich um Grafiken/Bilder handelt, kann man auch unter XP sehr gute Ergebnisse erzielen wenn man bestimmte Funktionen selbst programmiert.
Die von dir angesprochenen verschiedenen "Layer" sind imho ohnehin schon immer im GDI enthalten.
Und für die Transparenz hat sich auch schon jemand gefunden^^
Hi zusammen,
habe beim Aufräumen folgendes gefunden:
2x 1 Gb DDR2 RAM
Athlon 4850 (35W TDP)
Athlon X2 250
Graka HIS 6750
sowie noch ne Kiste voller Kühler/Lüfter/Kabel/Adaptergedöns
Geplant war, einen Media-PC für den/die Fernseher zu erstellen.
Aber nachdem ich dieses Teil für 300€ (neu) angeboten bekommen habe, frage ich mich, ob sich für dieses Geld trotz der vorhandenen Komponenten ein ca. 20x größerer Zuspieler (als PC) überhaupt bauen lässt.
Das Tabletgerät reicht als HDMI-Zuspieler mit integrierter "Fernsteuerung" über BT/Handy völlig aus.
Wenn also jemand ein Mainboard/kleines Gehäuse für meine Komponenten hat bzw. selbst die Brocken gebrauchen kann, oder auch Tips für ein Gerät mit möglichst hohem WAF hat, bitte melden! ![]()
Ich habe nicht die EULA gelesen, so dass ich nur vermuten kann...
Ich kenne niemanden, der jemals eine EULA von Windows gelesen hat!
Wozu auch?
Entweder man nickt (ob gelesen oder nicht ist unerheblich) die EULA bei der Installation ab, oder Windows wird nicht installiert!
D.h im Endeffekt nichts weiter, als dass man das Betriebssystem Windows incl. sämtlicher dafür verfügbaren Software eigenverantwortlich betreibt!
@Troubadour,
welche Funktionen benötigst du konkret?
Hi,
Wert von MouseGetPos(0) in das Textfeld ($X_) hinein schreiben will?
wobei der Sinn dieser Aktion nachzufragen ist.
Mit einer Maus bestimmte Koordinaten anzufahren, diese Koordinaten dann in ein Input-Feld zu schreiben, aus dem sie dann nur per Tastendruck (der Mauszeiger steht ja woanders) übernommen werden können, ist "seltsam"!
@Eugen,
was willst du überhaupt machen?
Generell erstelle ich längere Postings in einem Texteditor/Scite bevor ich poste. Egal in welchem Forum!
Es kann so unendlich viele Probleme bei der Datenübertragung, beim Browser/Provider/Server usw. geben, da verlässt sich hoffentlich niemand darauf, dass alles einwandfrei funktioniert. Mal abgesehen davon, statt auf den "Absenden"-Button zu klicken, F5 zu drücken...
Ein Backup ist imho für ALLE Daten sinnvoll
(wo ist eigentlich der "dicke" animierte Zwinkersmilie aus dem alten Forum geblieben? )
nein eben nicht erhalte von $result nur den wert 0. Es musste aber der Stromverbrauch von ca 30 herauskommen.
also ich würde zum Testen mal einen Fön oder Wasserkocher mit ca. 1000 Watt an diese Steckdose hängen und nicht einen Verbraucher, der 30 Milliwatt "zieht".
Btw. ermittelt getswitchpower die Leistung und nicht den Strom....
Wolfram Alpha?
Wolfram Alpha!
So?
[autoit]#include <Array.au3>
$sInput = 'aaa|41|63|43|70|58|52|||||||||||||||3|0|327|54.500|1|7.50|7.50|aaa' & @CRLF
$sInput &= 'bbb|||||||||||||||||||||2|0|327|54.500|1|7.50|7.50|aaa' & @CRLF
$sInput &= 'ccc|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15|16|17|18|19|20|1|0|327|54.500|1|7.50|7.50|aaa' & @CRLF
; das gibt mir nur den ersten Wert aus. Ich brauche aber zusätzlich die ersten 20 Werte nach den Buchstaben
$aOut = StringRegExp($sInput, '\w+((?:\|\d*){20})\|.+?\R', 3)
_ArrayDisplay($aOut)
[/autoit]Die Geschwindigkeit lässt natürlich zu wünschen übrig,
Die vielen "If´s" kosten Geschwindigkeit.
Fast alle kannst du dir sparen, wenn du einen "Rahmen" von permanenten "Einsen" rund um dein Spielfeld legst.
11111111
10000001
10000001
10000001
11111111
Somit brauchst du nur noch die
If $aKolonie[$y + 1][$x] = 1 Then $iNachbarn += 1
Und selbst die bekommst du alle in eine Zeile...
$iNachbarn=...+....+...+...+.... (lass dir was einfallen
)
Ich vermute, grundlegendes Problem ist wieder mal der Datentyp, der von Funktionen verwendet beziehungsweise zurückgegeben wird.
Wie schon von GTA-Spider angesprochen, ist es völlig unerheblich, in welchem Format Funktionen ihre Parameter zurückgeben, so lange der Programmierer WEISS, welches Datenformat verwendet wird!
In einer reinen (jaja ANSI) *.txt-Datei stehen per se erstmal nur BYTES.
Wie diese Bytes beim Auslesen interpretiert werden, ist Sache des Anwenders!
Somit ist es auch völlig egal, in welchem Format in die Datei geschrieben wird, solange klar ist, wie mit den auszulesenden Daten umzugehen ist.
Ob der Dateiinhalt eine der folgenden Zeilen
ABC
0x414243
414243
ist, macht doch nur beim Auslesen einen Unterschied bzw. bei der Interpretation des Inhaltes! Für das Schreiben ist das völlig unerheblich!
Die Flags beim Fileopen() für den Schreibmodus wandeln doch nur in ein bestimmtes "Anzeigeformat" um.
Ein einfaches Filewrite("test.txt",$irgendwelche_Daten) funktioniert grundsätzlich mit ALLEN Daten! Natürlich auch "binären"...(omfg, jetzt werde ich gleich gekreuzigt, natürlich sind alle Daten "binär"
)
Und auch ein $irgendwelche_Daten=Fileread("test.txt") funktioniert immer.
Wenn man natürlich als Programmierer nicht weiss, welchen Datentyp man in die Datei geschrieben hat, und wie dieser Datentyp nach dem Auslesen weiterzuverarbeiten ist, dann hat man natürlich schlechte Karten...
Gleiches gilt für die "Programmierer", welche sich über "komische Zeichen" in Msgboxen bzw.bei der Anzeige von Dateiinhalten beschweren.
Das liegt einfach daran, dass diese Leute die falschen Anzeigeprogramme benutzen. Hexeditor FTW! ![]()
#include <Crypt.au3>
[/autoit][autoit][/autoit][autoit]; Passwort & zu codierender Text
Local Const $sUserKey = "CryptPassword" ; Deklariert eine Passwort-Zeichenfolge um die Daten zu ver- und entschlüsseln.
Local $sData = "0123456789" ; Dieser Text wird verschlüsselt werden.
; codieren
Local $bEncrypted = _Crypt_EncryptData($sData, $sUserKey, $CALG_RC4) ; Verschlüsselt den Text mit Hilfe der generischen Passwort-Zeichenfolge.
FileDelete("binaere.txt") ;textdatei löschen, da filewrite daten anhängt (append)
FileWrite("binaere.txt", $bEncrypted) ;schreiben
; decodieren
Local $file = FileRead("binaere.txt") ;hier kommt das heraus, was _Crypt_EncryptData() zurückgegeben hat!
$bEncrypted = _Crypt_DecryptData($file, $sUserKey, $CALG_RC4) ; Entschlüsselt den Text mit Hilfe der generischen Passwort-Zeichenfolge. Der Rückgabewert ist ein Binärstring.
MsgBox(0, "decodieren", BinaryToString($bEncrypted)) ;HIER liegt der Hase im Pfeffer^^
[/autoit]warum kann ich jetzt nicht angeben, dass diese rückgabe eine 32 oder 64 ist um dann das richtige (stack/calling convention)
zu veranlassen um die rückgabe richtig zu interpretieren.
Ich bin jetzt mal vorsichtig...
Hast du jemals in Assembler programmiert?
Ich meine jetzt nicht irgendwelche abgetipperten 3-Zeiler, sondern eigenständige Anwendungen, Treiber, Dll´s, oder auch nur irgendwelche kleinen Tools, oder auch nur diese neumodischen "Injections" (früher hat man einfach nur TSR´s "umgebogen" ). Com- oder Exe-Files erstellt?
Generell machbar, aber aufwendig...
Was imho die Frage beantwortet, wieso es die FASM-DLL nicht als "reine" 64-Bit-Anwendung gibt. Es besteht absolut kein Grund dafür! Ich kann doch ohne weiteres die 32-Bit-FASM.exe aus einem 64-Bit-Programm aufrufen!
Die Compilerbauer sitzen in den Hardwareabteilungen der Prozessorhersteller! Die neuen Prozessoren haben unglaublich aufwendige Möglichkeiten bei der Umsortierung und internen Ablauforganisation. Ein Assemblerprogrammierer müsste, um auch nur annähernd an diesen Level zu kommen, ständig für jeden Prozessor die optimalen Abläufe im Hinterkopf haben und das auch parallel für sämtliche verfügbaren Prozessoren in sein Programm implementieren um auch nur annähernd an die Leistungsfähigkeit der Compiler heranzukommen. Völlig illusorisch!
Assembler ist/wird dann interessant, wenn die Compiler nicht an die erwarteten maximalen theoretischen Möglichkeiten der Prozessoren herankommen. Dann schlägt die Stunde der "Hardcore"-Assemblerprogrammierer. Davon dürfte es aber nicht mehr als einige Handvoll weltweit geben. Und die sitzen wiederum wo?
...in den Hardwareabteilungen der Prozessorhersteller! ![]()
@WhiteLion
Anbei meine erste Version zur Benutzung der FASM.dll, input x86-Mnemonics, output Maschinencode. Integriert ist Syntaxcheck und die Fehlermeldungen.
Ich denke, so etwas ähnliches hilft dir weiter...
//EDIT
übrigens funktioniert eukalyptus´ UDF sowohl für 32-Bit- als auch für 64-Bit-Code einwandfrei, ich frage mich, was daran zu bemäkeln ist...
und der bytecode soll optional 32 oder auch als 64 bit variante assembliert herauskommen. (dazu benuzte ich eine checkbox [x] genetiere 32Bit Bytecode (sonst 64))
Oha, wenn du so weit bist, sag Bescheid!
Einfach per Checkbox aus 32-Bit-Code einen 64-Bit-Code zu machen oder umgekehrt, DAS interessiert mich jetzt!
Dir ist mit Sicherheit garnicht klar, was du da schreibst...
Ein ASSEMBLER übersetzt lediglich die in Assemblersprache geschriebenen Mnemonics eins zu eins in Opcodes. Da wird nichts kompiliert oder "übersetzt". Der Programmierer legt mit seinem Code fest, ob 64-Bit-Code oder 32-Bit-Code oder 16-Bit-Code oder 8-Bit-Code erstellt wird! Von den Macros ganz zu schweigen....
64-Bit und 32-Bit sind zwei völlig verschiedene Paar Schuhe!
Das geht bei den calling conventions los und hört beim verwendbaren Adressraum auf. Dazwischen befinden sich sämtliche Interna von x86-Prozessoren, Register, Cache usw.
Aber ich lasse mich ja gerne überraschen
Ein Flag zu setzen, und *schwupps* wird 64-Bit-Code erstellt, DAS hat was ![]()