| |
|
|
| ¡Hola, me es aufgefallen, daß el FindBytes-Befehl no Bytes con el Werten 01-15 encontrar kann (oder Bytefolgen en denen solche Werte vorkommen). Gibts dafür una Grund oder Yo como algo falso gemacht? Yo möchte con el Rutina el Position bestimmter Punkte oder Pixel-Areale innerhalb uno Mapa de bits suchen, esta kommen obige Werte wahrscheinlich auch antes. Yo tener el Rutina con un Profano-Zona# y una InitExtFX()-Array ausprobiert y ausserdem el Parámetro- übergabe via Chr$(x) oder una zweiten Array, con gleichem Ergebnis. MfG Dieter |
|
|
| |
|
|
|
| ¡Hola,
Franco es en el Moment en el Fiesta (el glückliche !) deswegen musst du vorerst con me vorlieb nehmen ;) oder du wartest a Franco otra vez como es.
Von una Fehler en FindBytes me está a ahora nichts bewusst ! Poste doch veces al besten el Codestück, Yo guck veces si Yo como qué encontrar kann.
Moritz |
|
|
| |
|
|
|
| ¡Hola Moritz, sólo no falsche Bescheidenheit, du kannst dich gerne así beschäftigen .Hier el Code, el auskommentierten Zeilen al Ende tener Yo auch probiert. Wenn Si es usted el Disponer memory# al Anfang weglässt kannst du el Rutina auch veces en el Profano- Zona testen. Der Teil-Hexdump es una kleine Mapa de bits, con Paint erstellt. Yo habe simplemente con el Hexeditor Bytefolgen reingeflickt y suchen dejar. El Bytefolge 128 7 128 debería a Adresse $5D gefunden voluntad, funktioniert en me pero no. Wenn uno en lugar de el 7 a Adresse $5E aber una 8 setzt y después de 128 8 128 sucht, entonces klappts otra vez. Oder versuch veces z.B. a Adresse $37 en lugar de el $10 algo kleineres (salvo 8) a conjunto y z.B. después de 16 5 32 a suchen. En Einzelbytes es genauso. Falls algo unklar ser debería, melde dich. Dieter KompilierenMarcaSeparaciónDeclare neu&,text$,such$,lenght&,breite&,höhe&,grösse&
Declare hdc1&,array1&,arrayadr1&
Declare memory#,bereich2#,pixpos&
Dim bereich2#,3
$I Prospeed_Funktionen.inc
*** Profan Hauptprogramm
SetTrueColor 1
neu&=usedll("ProSpeed.dll")
rem
Window (%maxx/2-400),(%maxy/2-300)-800,600
Cls 0
*** Daten und Bitmaps laden und initieren
text$="12_17pixel.bmp"
rem
lenght&=@FileSize(text$)
If lenght&>0
Dim memory#,lenght&
ReadFileFast(addr(text$),memory#,0,lenght&)
hdc1&=LoadExtMemory(memory#,lenght&)
Dispose memory# Profan-Bereich
EndIf
array1&=InitExtFX(hdc1&)
rem Header auslesen
arrayadr1& = Long(array1&,40)
breite& = Long(array1&,4)
höhe& = Long(array1&,8)
grösse& = Long(array1&,20)
rem Suchparameter setzen + suchen
such$ = @Chr$(128)+@Chr$(7)+@Chr$(128)
pixpos& = FindBytes(arrayadr1&,0,grösse&,Addr(such$),3)
rem Ausgabe
Print lenght&,arrayadr1&,breite&,höhe&,grösse&
Print "Pos>";pixpos&
waitkey
pixpos& = @MemPos(memory#,0,such$)
string bereich2#,0= @Chr$(128)+@Chr$(0)+@Chr$(128)
byte bereich2#,0= 128
byte bereich2#,1= 1
byte bereich2#,2= 128
pixpos&=FindBytes(arrayadr1&,0,grösse&,Addr(such$),1)
pixpos&=FindBytes(arrayadr1&,0,grösse&,bereich2#,3)
00000000 42 4D 9A 02 00 00 00 00 00 00 36 00 00 00 28 00
00000010 00 00 0C 00 00 00 11 00 00 00 01 00 18 00 00 00
00000020 00 00 64 02 00 00 C4 0E 00 00 C4 0E 00 00 00 00
00000030 00 00 00 00 00 00 10 10 20 30 10 00 FF FF FF FF
00000040 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000050 FF FF FF FF FF FF FF 00 00 00 10 02 10 80 07 80
00000060 FF FF ../../function-references/XProfan/ff/'>FF
|
|
|
| |
|
|
|
| So como yo ahora verstanden tener, suchst du en el Array después de una Pixel el el Farbwert @rgb(128,7,128) ha, oder ?
Dann versteh Yo allerdings el benutzung de @chr() para zusammen conjunto des Suchstrings no, esta Función liefert dir doch Buchstaben zurück. In deinen Suchstring es entonces €|€ ! Kann uno überhaupt con un String después de Bytefolgen suchen ? Hab a ahora kaum con FindBytes gearbeitet, aber el währ me neu. Scheint pero probablemente doch irgendwie a klappen, como du geschrieben hast
Moritz |
|
|
| |
|
|
|
| Moritz, lo scheint no irgendwie a klappen, es völlig normal una Suchstring en esta Weise a generieren, anders podría uno sí cierto Steuerzeichencodes no eintragen. El Suchroutine wandelt el String sí otra vez en el ANSI-Codezahlen en y sucht después de esta Zahlenwerten y no después de Buchstaben. Was el Werte letztendlich aussagen es irrelevant. Das Suchbeispiel Franco de el prospeed-Ayuda podría uno así más o menos eingeben: such$ = Franco oder such$ = @Chr$(70)+@Chr$(114)+@Chr$(97)+@Chr$(110)+@Chr$(107). Ist beides dasselbe. Übrigens Yo sí al Ende des Listings el Suchcodes auch con el byte bereich2#,x=y -Befehl a una 2.Zona transferencia y así (ergebnislos) gesucht. Yo habe deinen Einwand aber trotzdem überprüft y esta herausgefunden Yo auch algo schieflag. El FindBytes-Rutina kann no sólo Werte<15 no encontrar pero stolpert encima Suchwerte el no liso por 8 teilbar son (y todavía algunos otro, z.B. valor 88). Dies scheint más en una Problema innerhalb el Suchroutine hinzudeuten. Das obige Suchbeispiel z.B. no trabajo para mí.
MfG Dieter |
|
|
| |
|
|
|
| ¡Hola,
>>Die Suchroutine wandelt el String sí otra vez en el ANSI Codezahlen en y sucht después de esta Zahlenwerten y no después de Buchstaben<<
Ahh, ok, el wusst Yo no, entonces ergibts natürlich otra vez Sinn ! Aber por qué manche Werte no erkannt voluntad weiß Yo auch no, solange ellos bajo 256 mentira dürft lo en efecto no Problemas geben. Muss irgendwie una Inkompabilität zwischen el Ansi Signo y el Pagar ser oder algo como, werds auch veces testen, tener en el Moment aber wenig Tiempo, deswegen wohl más morgen.
Moritz |
|
|
| |
|
|
|
| Hi,
kurz veces de mi Fiesta... ) FindBytes() funktioniert korrekt, como el untenstehende Ejemplo beweist. Als Ergebnis se 801 ausgegeben. Wenn du otro Pagar en el Ejemplo übernimmst, wirst du auch rápidamente merken, el deine Theorie con el niedrigen Pagar y Pagar, el por acht teilbar son, falso es. KompilierenMarcaSeparaciónDeclare neu&,x&,y&,z&,text$,bereich#,eingabe#
Dim bereich#,20001
Dim eingabe#,1024
*** Alle Dll-Funktionen einbinden
$I Prospeed_Funktionen.inc
*** Profan Hauptprogramm
SetTrueColor 1
neu&=usedll("ProSpeed.dll")
WindowStyle 80
Window 0,0-800,600
Cls 0
Clear Eingabe#
String Eingabe#,0="120,128,7,128,124,125,126"
SetBytes(Bereich#,800,eingabe#)
text$=Chr$(128)+Chr$(7)+chr$(128)
x&=FindBytes(bereich#,0,20000,Addr(text$),3)
Print x&
WaitInput
freedll neu&
Dispose bereich#
Dispose eingabe#
FIN
Como hast Si es usted el untere Hex-Array en deinem Beispielcode porque überhaupt producido ? Sind el Werte el originalen Mapa de bits ? Oder una abgespeichertes Byte-Array ? Usted mußt wissen, el Windows el Bitmaps como Bytes en un Byte-Array con leichten Variationen einsetzt, de 128,7,128 se also ligeramente 127,7,128, außerdem va el Pixel-Reihenfolge en un Bytes-Array de unten links unten después de bastante oben ! Das gilt lo a beachten... Wenn Hice mi Fiesta otra vez zuhause bin (Samstag), voluntad Yo dein Ejemplo veces genauer testen.
Moritz: Yo super Wetter y jede Menge Spaß...
Saludo, Franco |
|
|
| |
|
|
|
| >>Du mußt wissen, el Windows el Bitmaps como Bytes en un Byte-Array con leichten Variationen einsetzt, de 128,7,128 se also ligeramente 127,7,128, außerdem va el Pixel-Reihenfolge en un Bytes-Array de unten links unten después de bastante oben !<<
Das se el problema ser ! Ha, olle Bill Gates ha veces otra vez schuld
Moritz |
|
|
| |
|
|
|
| ¡Hola Franco, du hast völlig bastante, el ha me gedämmert como Yo später el Ejemplo de el prospeed-Ayuda 1:1 übernommen habe y veces con Getpixel() vom Screen gelesene Daten con un gespeicherten File verglichen habe. Also el war me sí völlig neu. Pensé siempre Farbwert es Farbwert. El Unterschiede son tan teilweise todavía viel stärker como en deinem Ejemplo. Bleibt una Cuestión, dejar el Unterschiede matemáticamente nachvollziehen, d.h. puede ser se darauf verlassen dass el Abweichungen siempre igual ausfallen oder voluntad el Werte vom Sistema sozusagen kreativ encima el digitalen Daumen gepeilt? Gracias de paso para deine respuesta rápida, incluso de el Fiesta. MfG Dieter |
|
|
| |
|
|
|
| hi,
byte-arrays verwaltet prospeed intern siempre en 24 bit, windows de paso auch. en umrechnung de 32 en 24 bit passieren sólo esta kleiner fehler... soweit Yo weiß, kann dieses comportamiento en el system irgendwo eingestellt voluntad, weiß pero no genau, wo...
frank, el de el urlaub otra vez como es, aber desafortunadamente con uno schultereckgelenkssprengung, bänderriss en el schulter ... nächste woche tener Yo mi op..... muß ahora con links escribir y maus lenken... |
|
|
| |
|
|