| |
| |
|
| - Seite 1 - |
|
Matthias
Arlt | Meine ersten Versuche mit Assembler gestalten sich dank Franks Einführungskurs besser als gedacht...! Nun habe ich aber folgendes Problem bzw. nen Denkfehler drin:
Eine ASM-Routine ermittelt einen String und schreibt diesen in einen Bereich. Das Auslesen klappt mit invoke MessageBox , 0, addr buffer, usw. bestens. Wenn ich nun statt Ausgabe in einer Messagebox den String im Profan-Programm weiterverarbeiten will, wie übergebe ich diesen korrekt? (addr buffer geht ja nur nach einem invoke...)
Matthias |
|
| |
| WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia | 12.12.2006 ▲ |
|
| |
|
|
| |
| |
| - Seite 1 - |
|
Michael
Dell | | Ach so, hier könnte ein einfaches Return txt# nach mov eax, para3 reichen. Wenn das nicht funzt declariere txt2# mit den gleichen werten wie txt# und schreibe Return txt2# und nach der Funktion print string$(txt2#,0). |
|
| |
| Salu Michael...
Hab zwar krumme Fieß awer dofir e' ecklich Gsicht! | 12.12.2006 ▲ |
|
| |
|
|
Jörg
Sellmeyer | | Müßte das hier nicht hdl&,spalte&,Addr(txt#)) heißen? |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 12.12.2006 ▲ |
|
| |
|
|
Matthias
Arlt | | So, alle Varianten durchprobiert (txt#...txt2#...addr(txt#)...), aber Ergebnis leider wie gehabt. Während unter Profan7 immerhin noch unbrauchbare Zeichen mit string$(txt#,0) ausgelesen werden, passiert unter XProfan nach der Messagebox rein garnichts. Versuche mit invoke MemCopy... schlagen wegen Zugriffsverletzung ebenfalls fehl. Das Rätseln geht also weiter... |
|
| |
| WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia | 12.12.2006 ▲ |
|
| |
|
|
Frank
Abbing | lea eax, para3
mov lvi.pszText, eax
mov lvi.cchTextMax, 256
muss heissen:
m2m lvi.pszText, para3
mov lvi.cchTextMax, 256
oder
mov eax, para3
mov lvi.pszText, eax
mov lvi.cchTextMax, 256
para3 ist ja der Zeiger auf einen String und die Listviewmessage erwartet auch einen Zeiger auf einen String.
mov eax, para3
AsmEnd
Ist eigentlich Quatsch, weil der Returnwert = txt# ist.
Übrigens kannst du besser den Debugger anstelle einer Messagebox nutzen, um Zahlenwerte oder Strings anzuzeigen. Probier mal:
PrintDec eax
oder
PrintStringByAddr para3
P.S.: Prima, dass dir mein Kurs gefallen hat.  |
|
| |
| |
| |
|
|
Matthias
Arlt | @Frank
Besten Dank, funktioniert perfekt ! Hast mir sehr geholfen !!!
Ansonsten klappt das DLL-Erstellen schon ganz gut. Ich habe Deinen XPIA quasi als Standalone-Tool in PRFellow eingebunden und bastle mir damit auf recht komfortable Weise aus dem Editor heraus meine DLLs (für derzeit noch Profan7) zusammen. Ggf. lade ich das mal als PRFellow-Erweiterung hier hoch...
Matthias |
|
| |
| WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia | 12.12.2006 ▲ |
|
| |
|
|
Frank
Abbing | Prima, das kann bestimmt der eine oder andere gebrauchen. PrFellow erfreut sich ja immer noch grosser Beliebtheit.  |
|
| |
| |
| |
|
|
Matthias
Arlt | Ich habe inzwischen noch ein weiteres Problem mit einem Stringvergleich. Folgender Code funktioniert zwar als Solcher, liefert aber immer ungleich zurück. Auch wenn Pufferinhalte definitiv gleich sind:
...
cld
mov ecx,sizeof Buffer2
lea esi,Buffer1
lea edi,Buffer2
repe cmpsb
jnz ungleich
jz gleich
...
Habe schon unterschiedlichste Varianten durchprobiert, aber leider erfolglos...!?
Matthias |
|
| |
| WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia | 17.12.2006 ▲ |
|
| |
|
|
Frank
Abbing | | repe cmpsb ist veraltert. Nimm anstelle dessen lieber die APIs lstrcmp(), bzw. lstrcmpi(). Sicherer und viel schneller. |
|
| |
| |
| |
|
| |
| |
| - Seite 2 - |
|
|
Matthias
Arlt | Kurioses Verhalten...
Moin Frank
Danke erstmal für den Hinweis. Werd ich dann probieren. Aber das eigentliche Problem liegt scheinbar schon vor dem Eintritt in den Vergleich. Frage ich nach dem zweiten LB_Gettext den Pufferinhalt ab, habe ich in Prev TTest und in Next Test stehen. Frage ich hingegen einzeln nach jedem LB_Gettext ab, stimmt es aber noch. Keine Ahnung, wodurch sich der Pufferinhalt ändert...???
Das bleibt auch so, wenn ich stattdessen lokale Puffer verwende. Jedenfalls bekommt dadurch der Vergleich ja immer ungleiche Daten angeboten. Und dasmacht mit etwas ratlos...
Profan-Code
declare lb&,dll&
dll&=usedll(E:LB.DLL)
cls
lb&=createlistbox(%hwnd,,10,10,300,200)
addstring(lb&,Test)
addstring(lb&,Test)
waitkey
external(LB.DLL,LBCheckDoublettes,lb&)
freedll dll&
Code in DLL
AsmStart LBCheckDoublettes
Parameters hdl&
.data
szGleich db gleich,0
szUngleich db ungleich,0
szPrev db Prev,0
szNext db Next,0
.data?
Prev db ?
Next db ?
.code
LOCAL ItemCount:DWORD
LOCAL LoopCount:DWORD
invoke SendMessage, para1, LB_GETCOUNT, 0, 0
mov ItemCount,eax
invoke SendMessage, para1, LB_GETTEXT, LoopCount, ADDR Prev
inc LoopCount
invoke SendMessage, para1, LB_GETTEXT, LoopCount, ADDR Next
lea di,Prev
lea si,Next
mov cx, sizeof Next
cld
repe cmpsb
je gleich
jne ungleich
gleich:
invoke MessageBox,0,addr Prev,addr szGleich,MB_OK
ungleich:
invoke MessageBox,0,addr Prev,addr szUngleich,MB_OK
AsmEnd
Kannst Du Dir (und mir) das erklären?
Danke und Gruß
Matthias |
|
| |
| WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia | 18.12.2006 ▲ |
|
| |
|
|
Frank
Abbing | Das hier wird den Fehler auslösen. So reservierst du nur 1 Byte:
.data?
Prev db ?
Next db ?
Machs so:
.data?
Prev db 512 dup(?)
Next db 512 dup(?)
512 bedeuten hier 512 Bytes, die reserviert werden. |
|
| |
| |
| |
|
|
Matthias
Arlt | Danke Frank, genau das war es auch ! Mit dem dup hatte ich mich noch nicht angefreundet bzw. dessen Verwendung mißverstanden (Da ich ja eigentlich nichts verdoppeln wollte...). Das erklärt nun auch gleich andere aufgetretene Fragen !
Auch macht sich der Vergleich mittels API wesentlich freundlicher, weil gewohnter. Schön, wenn man so schnell fachkundige Hilfe bekommt !!!
Besten Dank
Matthias |
|
| |
| WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia | 18.12.2006 ▲ |
|
| |
|
|
Frank
Abbing | |
| |
| |
| |
|
(873)
Deutsch
English
Français
Español
Italia