Beiträge von Andy

ersetze isint durch number, dann gehts

Glücklichen Herzwunsch zum Geburtstag auch von mir!
Mögest du uns allen auch weiterhin zeigen, wo programmiertechnisch "der Hammer hängt"!

wenn du ein "unsichtbares" (volltransparentes) Control in der Grösse des Bildes über das png legst, kannst du das Handle des Contrls abfragen

Hi,
früher war es mal möglich, bei CorelDraw nach Ablauf der Testzeit das Programm als Viewer weiterzubenutzen, wenn man nicht die Vollversion kaufen wollte.

Zitat

Möchte so einen Viewer erstellen wie AutoBert das gemacht hat:

BMP, Gif und JPEG kann jedes x-beliebige Programm einlesen, die Datei-Formate sind bekannt und Algorithmen frei verfügbar.

CDR ist von Corel lizensiert und wird mit jeder Version mitgeändert!
Investiere einige Wochen/Monate in das Reverse-Engineering des Formats und schreibe einen CDR-Viewer!

Ich würde das komplett vom Editor loslösen! Jeder Programmierer hat seinen individuell für sich eingerichteten Editor, und das soll auch so bleiben! Wozu ein rollendes Ding erfinden mit 12 Ecken, wenn es schon ein Rad gibt?
Gerade Scite bietet sich doch hervorragend an, um "von aussen" (per AutoItscript/Lua) gesteuert zu werden. Wen es interessiert, hier gibt es Infos bzgl der Scite Steuerkommandos, die auch ohne weiteres aus AutoIt aufgerufen werden können.
Im Prinzip muss doch nur die Datei auf dem neuesten Stand gehalten werden. Da würde eine Aktualisierung alle paar Sekunden sicherlich ausreichen...

Zitat

Wie ich höre würdet ihr eher zu Datenübertragung per Ftp tendieren...
ich weiß nicht aber ist das nicht zu langsam?

Da nur die Änderungen während einer Session übertragen werden müssen, spielt sich der Aufwand bei einer Datenübertragung im Byte-Bereich ab!
Mal angenommen, der "Refresh" würde 1x in 10 Sekunden erfolgen. Dann müssten nur die Daten übertragen werden, die während dieser Minute gecodet wären. (Wieviel KB Code schreibst du in 10 Sekunden^^)

Ggf. wäre aber auch ein "Ringsystem" vorteilhaft, welches den kompletten Text zum "nächsten" Coder schickt, dort mit dessen Änderungen versehen wird usw...selbst wenn kompletter Code verschickt wird sind das nur einige (sehr gut und schnell komprimierbare) Textdateien.

Ich hatte mal vor einiger Zeit versuchsweise ein "Terminal"-AutoItScript bei mir im (damals 10MBit) Netz laufen. Selbst wenn 5 Leute gleichzeitig gearbeitet/geschrieben hatten, war eine Verzögerung praktisch nicht bemerkbar...
Wenn man dann auch noch so programmiert, dass möglichst viel Code in Funktionen ausgelagert wird (Includes ftw! ), kann jeder Programmierer seine eigenen Brötchen backen und ggf per "Upload"-Hotkey den anderen zur Verfügung stellen...

Über interna, d.h. wer coded welche Funktion bzw in welchem Codebereich, könnte man sich ja Gedanken machen, TS/Chat wäre auch nicht verkehrt (zu Raupi rüberschiel^^).
Die Verwendung der #Regions halte ich für hervorragend! Wenn jemand eine Änderung gemacht hat, könnte z.B. die entsprechende Sequenz mit "Region" Informationen (Coder, Änderung, Datum usw...) für jeden lesbar eingefasst werden. Ideen her und los gehts!

Ich finde die Idee, "zusammen" zu scripten, sehr geil!
Eigentlich dachte ich, dass google mit WAVE aus den Socken kommt, aber der Cloud-Hype hat wohl Entwicklerkapazitäten aufgefressen....
Über die Datenübertragung würde ich mir keine Gedanken machen, da "nur" der veränderte Text verschickt wird. Kaum einer von uns wird 200-300 Anschläge/Minute schaffen, das würde auch ein Akkustikkopler von vor 30 Jahren noch schaffen^^
Aber ich stelle mir gerade vor wie extrem cremig das aussehen würde, wenn sich ein Text/Script auf dem Bildschirm aufbauen würde, der von 3-4 Leuten gleichzeitig erstellt wird^^

Wenn man die meisten Funktionen eines "richtigen" Editors kennt, ist die Größe des Quellcodes unerheblich!
Die Codefaltung wurde ja schon angesprochen, schnelles Navigieren im Script geht mit den entsprechenden Funktionen. In Scite helfen z.B. die Funktionsliste (Alt+L) oder die Sprünge zu den Funktionen Ctrl+J zur Funktion (kann auch in einer includeten Datei sein! ) wobei Ctrl+Shift+J wieder zurück springt.

"Fertige" Funktionen kann man natürlich in Includes auslagern! Was ich zu vermeiden versuche, ist die Deklaration von Variablen (ausser Globals) in diesen Dateien. Wenn man versucht, den Code möglichst in Funktionen zu packen, wird es einfacher. Nichts ist übler zu debuggen als 1800 zusammenhängende Zeilen.
Ausserdem sind Funktionen schnell mal neu geschrieben/verbessert, ohne im Script 266 mal mit "Suchen/Ersetzen" die Zeit totzuschlagen.

Das allerwichtigste meiner Meinung nach sind KOMMENTARE!
Es soll zwar Leute geben, die nach 12 Jahren noch wissen, dass sie in Zeile 8473 mit den 3D-Arrays einen Workaround gebastelt hatten und das dann im handumdrehen fixen können, aber Leute diesen Kalibers sind dünn gesät und meist aufgrund ihres KnowHow´s unkündbar! Aber jeden anderen 08/15 Tastenklopper kann man durch einen ersetzen, der in der Lage ist, seinen Code auch ordentlich zu dokumentieren. Was übrigens auch recht oft gemacht wird...

Zitat von trancexx

And I must say that I was very disappointed seeing that even the writers of the code often lack understanding of it. It's kind of pathetic when you see some code used and when asking author what's this or that you get answer "I don't know". And if you ask for the code to be explained by words (any fucking human language) coders fail terribly. How can you write code if you can't explain it?!?

....dem ist nichts mehr hinzuzufügen....

wen es interessiert, Ida pro in der kostenlosen Version ist hervorragend geeignet, "in" eine Dll hineinzusehen, incl Auflistung der Funktionen uvm

Die API-Funktionen (die auch in diversen Dll´s stehen) gibts eigendlich alle auf MSDN. Ich suche danach mit meiner ErGo (erweiterte Googlesuche), Häkchen bei MSDN(english) machen, Funktionsname im der Eingabezeile eingeben, fertig. Wenn man dann noch ein Häkchen bei AutoIt.de und autoitscript.com macht, bekommt man sogar die Links zu Forenbeiträgen, die diese Funktionen beinhalten^^

hehe, langsam sollte ich mich vielleicht mal überwinden, auch mal eine Zeile C zu schreiben....wenigstens eine^^

wg deinem Problem, ich vermute, dass es einen Überlauf gibt (exception) wenn du das Byte (colors) mit einem Wert von wegen mir 178 mit -2 (kern) multiplizierst....das ergibt mehr als 255 und daher ein Überlauf. Ich könnte mir gut vorstellen, dass es ein Compilerflag gibt, um das abzufangen...wenn das überhaupt den Fehler auslöst....
0xB2 * 0xFFFFFFFE = 0xFFFFFE9C
178 * -2 = -356 = 0xFFFFFE9C ....= 4294966940 ......shit happens^^
/Edit/ sry, hab gerade gesehen ALGO ist INT, dann könnte es ja klappen, lass dir mal die algos als liste ausgeben bis der error kommt, im zweifelsfall MOD 255 oder algo direkt als byte dimensionieren

Zitat

Kleiner als ms kann ich noch nicht messen,

in C++ solltest du eigentlich auch direkten Zugriff haben auf rdtsc, der gibt die anzahl derTAKTzyklen zurück seit dem letzen Rechnerstart. http://msdn.microsoft.com/en-us/library/twchhe95.aspx
also pdeudocode:

ticks_start=_rdtsc
C-code
ticks=_rdtsc-ticksstart   ;anzahl der takte, die deine Funktion verbraten hat

das sollte als Genauigkeit ausreichen fürs optimieren^^

Hi

If Not $checktxt = $text Then

sollte entweder

If Not ($checktxt = $text) Then

oder

If $checktxt <> $text Then

sein!

Zitat

Das ist so öde.

/whispermode on/ es soll Leute geben, die diesen Vorgang per Script automatisieren *zu Greenhorn rüberschiel* /whispermode off/

Extrem cremig!
Allerdings sind die allermeisten API-Funktionen(wenn nicht alle) schon von Yashied in der WinApiEX "AutoItisiert".
Dieses Verfahren bietet sich übrigens auch dafür an, Wasserzeichen und ähnliches in Bilder zu schreiben. Das geht extrem schnell, vor allem, wenn man komplette Bilder-Verzeichnisse "in einem Rutsch" bearbeiten möchte.
Wie ich durch Zufall beim Debuggen herausgefunden habe, werden bei XP die 2D-Beschleunigungs-Funktionen des Grafiktreibers für das Blitten verwendet! Die neueren Windowsversionen (Vista+Win7) unterstützen nur noch 3D-Beschleunigung...
GDI (ohne+) rockt noch immer

Huhu!

Zitat

Zu Zeiten von 8-bit Rechnern habe ich viel in Basic und Assembler programmiert. Als ich dann auf den PC umgestiegen bin, habe ich mich hauptsächlich mit Basic beschäftigt.

Bis darauf, dass du +5 Jahre älter bist, liest sich das wie ein Teil meiner meine Biografie^^. Also: Herzlich Willkommen!
AutoIt unterscheidet sich nicht sehr stark von Basic, bietet aber wesentlich mehr als die "alten" Dialekte.
Auch auf Assembler musst du nicht verzichten!

Zitat

auch PNG-Dateien finden?
Damt ich auch Bilder mit Transparenten Hintergrund finde.

png-Datei einlesen, Alphakanal ausmaskieren und die übrigen Pixel suchen. Da ich sehr stark vermute, dass dein knowhow nicht weit über c&p hinausgeht, erstelle ein Script und poste es hier, damit man darauf aufbauen kann. Oder suchst du jemanden, der dir die Anwendung (wozu braucht man sowas? ) komplett schreibt?

Zitat

z.B. wenn in meinen Editor Hallo steht soll _ImageSearch das finden oder wenn ich Internet Explorer auf den Desktop habe soll er nicht das Icon finden sondern den Namen Internet Explorer aber wenn ich den Hintergrund(Farbe) änder soll _ImageSearch das Bild(Internet Explorer Schrift noch wieder finden)

.ImageSearch macht das nicht, Imagesearch findet Bilder. Was du brauchst/suchst ist OCR unabhängig vom Hintergrund, viel Spass beim Suchen!
Eine Möglichkeit bestünde, wenn zumindest die Schriftgrösse/Schriftart bekannt wäre, einen Screenshot nicht nach zusammenhängenden Pixeln(Bildern) zu durchsuchen, sondern nach Mustern, welche mit dem Referenzschriftzug zu x% übereinstimmen.
Im Prinzip müsste man den eingegebenen Text in sämtlichen Schriftvarianten (Kursiv/Fett usw) in "Pixel" umsetzen, ggf auch 4-5 Schriftarten, (das ist ziemlich einfach) und die allen Schriftzügen "gemeinsamen" Pixel bestimmen.
Der Suchalgorithmus hätte dann nichts weiter zu tun als übereinstimmende Pixel der selben Farbe zu finden.
Hat das Pixel 3 rechts und 4 unter dem aktuellen dieselbe Farbe (abzüglich x% Rendertoleranz) usw...
Wozu braucht man so etwas?

wenn es kein "volltransparentes" Bild/Schrift sein soll (wer macht solch einen Quatsch?^^) könntest du es mit PushTheButton probieren. Damit finde ich auch animierte Buttons....

Hi,
108x75x4Bpp = 32448 das liegt ziemlich nah an an 32768(2^15). Ggf musst du mehr Speicher freigeben, oder es werden immer nur bestimmte Speicherbereiche ge"lock"t. Da scheint irgendein Buffer zu klein zu sein....
Hab aber ehrlich gesagt keine Ahnung^^
Aber wenn du es hinbekommen hast, sag mal Bescheid wg der Geschwindigkeit, ich hatte für das ASM-Tut die AutoItfunktion

_ColorConvertRGBtoHSL()

in Assembler geschrieben, sogar anstatt mit (langsamen) Floats in Integer^^

Zitat

das muss "UBound($zeilen) - 1" heissen, sonst wird die letzte Skriptzeile gelöscht.

Interessant, bei mir nicht, da Stringsplit() ans Array noch eine "Leerzeile" anhängt.
Bei Ubound-1 führt das dann dazu, dass jedesmal eine Leerzeile ans Script angehängt wird, aber du hast Recht, besser meinen Tod gestorben als deinen^^
Ich ändere das!

Zitat

Andy: Das heißt übrigens $verhaeltnis

ach...ICH weiss das^^, aber Rechtschreibfehler in anderer Leute Variablennamen zu verbessern...soweit käme es noch!
/EDIT/ rofl, habs gesehen, ich hatte es tatsächlich verschlimmbessert