| |
|
|
| KompilierenMarkierenSeparieren {$cleq}
cls
subClass hWnd,true
do {waitInput}
subClassProc{
select sWnd
caseOf hWnd
select sMessage
caseOf wm_getminmaxinfo
pokeDW sLparam+24,600
pokeDW sLparam+28,420
pokeDW sLparam+32,800
pokeDW sLparam+36,600
endSelect
endSelect
setWinProc true
}
pokedw(long adr,float v){
long vi
rtlMoveMemory(adr+2,addr(vi),2)
vi=int(v-(vi*2^16))
rtlMoveMemory(adr,Addr(vi),2)
}
oder KompilierenMarkierenSeparierenDECLARE __cf1&
Def __cf1(2) !KERNEL32,GetProcAddress
Def __cf2(1) !KERNEL32,GetModuleHandleA
__cf1&=__cf1(__cf2(KERNEL32),RtlMoveMemory)
CLS
SUBCLASS %HWND,1
WHILE 1
WAITINPUT
ENDWHILE
SUBCLASSPROC
SELECT &SWND
CASEOF %HWND
SELECT %SMESSAGE
CASEOF $0024
POKEDW &SLPARAM+24,600
POKEDW &SLPARAM+28,420
POKEDW &SLPARAM+32,800
POKEDW &SLPARAM+36,600
ENDSELECT
ENDSELECT
SETWINPROC 1
endproc
proc POKEDW
PARAMETERS ADR&,V!
var VI&=0
call(__cf1&,ADR&+2,ADDR(VI&),2)
VI&=INT(V!-(VI&*2^16))
call(__cf1&,ADR&,ADDR(VI&),2)
endproc
|
|
|
| |
|
|
|
| ...was mich daran erinnert schon x mal vorzuschlagen das peek und poke niemals in einem XProfan fehlen darf/kann/sollte/wird. |
|
|
| |
|
|
|
RGH | POKEDW ADDR& + OFFSET&, WERT& WERT& = PEEKDW(ADDR& + OFFSET&)
ist identisch mit
LONG ADDR&, OFFSET& = WERT& WERT& = LONG(ADDR&, OFFSET&)
Es heißt halt nur anders.
Gruß Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 22.02.2008 ▲ |
|
|
|
|
Frank Abbing | Gibt es noch Speicherarten, auf die LONG nicht zugreifen kann? Z.B. durch API definierte Speicher? War zumindest in früheren Profanversionen so. |
|
|
| |
|
|
|
RGH | Beim Befehl LONG muß als erster Parameter ein Variablenname stehen. Dies darf aber auch ein LongInt (&) oder Integer(%) sein. Ein Ausdruck ist hier (noch?) nicht gestattet.
Bei der Funktion LONG darf der erste Parameter ein beliebiger Ausdruck sein. (Auch wenn es in der Hilfe nicht an die große Glocke gehängt wird. ;) )
Vor Version 11 galt hier die gleiche Einschränkung wie beim Befehl und in früheren Versionen (ich weiß nicht mehr genau, wann ich das geändert habe) waren in beiden Fällen nur Bereichsvariablen erlaubt.
Gruß Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 22.02.2008 ▲ |
|
|
|
|
Frank Abbing | Danke, Roland! Das sollte generell für alle Befehle/Funktionen zutreffen, die auf Bereiche oder Strings zugreifen. |
|
|
| |
|
|
|
RGH | Frank Abbing
Danke, Roland! Das sollte generell für alle Befehle/Funktionen zutreffen, die auf Bereiche oder Strings zugreifen.
Ich werde noch mal nachschauen, wo ich da noch was tun kann. (In der Regel geht es ja nur darum, einige Sicherheitsabfragen herauszunehmen. Prinzipiell finde ich alles sympathisch, was den Code schlanker macht, aber den Anwender trotzdem nicht im Regen stehen lässt.)
Gruß Roland |
|
|
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 22.02.2008 ▲ |
|
|
|
|
Frank Abbing | Sehe ich genauso! Zumal ich den Unterschied zwischen Strings und Bereichen nicht einsehe. Im Grunde ist Speicher ja Speicher. Ich wäre froh über jede Lockerung in dieser Beziehung. |
|
|
| |
|
|