| |
|
|
- page 1 - |
|
| |
|
| |
|
|
|
| |
|
- page 1 - |
|
| @Dieter: mon Antwort galt Nico qui IMHO annahm, dass %mousex et %mousey simple umrechenbar wäre, quoi c'est pourquoi wenig utilise, là %mousex et %mousey seulement gesetzt volonté, si qui Mauspfeil sich sur dem HWND est. ^ ^ Dein Beispiel mais est ok, mais est im Grunde selbe comment meins dessus - je meinte seulement cela es besser wäre si XProfan %mousex et y mettons pourrait et getMousePos nativ wäre. |
|
|
| |
|
|
|
Dieter Zornow | Achso, ensuite habe je aussi Nico faux verstanden, bof rapide fortschreitende Alzheimer.
mais grundsätzlich hat il droite, qui Positionen im Hauptfenster pourrait on sur Screen-Koordinaten umrechnen laisser. Ist mais im Hauptfenster wahrscheinlich sinnfrei. |
|
|
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 19.10.2009 ▲ |
|
|
|
|
| chez Omikron-Basic (Atari 1040ST) hiess es aussi GetMousePos - fand je toujours joli. |
|
|
| |
|
|
|
Nico Madysa | oui, dass %MouseX et -Y quelque chose eingeschränkt sommes, vergaß je, jsuis inconsolable.
ensuite wäre mais une Set-Option, qui qui beiden Système entsprechend ändert, doch wesentlich sinnvoller, ou bien? |
|
|
| |
|
|
|
| Nico Madysa, Beitrag=54602, Zeitpunkt=24.10.2009
oui, dass %MouseX et -Y quelque chose eingeschränkt sommes, vergaß je, jsuis inconsolable.
ensuite wäre mais une Set-Option, qui qui beiden Système entsprechend ändert, doch wesentlich sinnvoller, ou bien?
get("MousePos",[Handle]) ist sinnvoll, ändert beide Sysvars. |
|
|
| |
|
|
| |
|
- page 2 - |
|
|
Nico Madysa | |
|
|
|
| Ne - ist Müll, comme wärs de quelqu'un qui sich aucun Gedanken gemacht hat ou bien avec cela aucun Erfahrung hat.
Get("MousePos",... ist aktiv, quoi Du vorschlägst wäre passif.
Um qui Mausposition JETZT bzw. trop un certain Zeit trop beziehen (ist important ca selbst bestimmen trop peut!) - et optionnel relativ trop einem Handle od. rel.z. Bildschrim, nécessaire on une Funktion getMousePos - pourrait on joli verpacken dans get("MousePos",... là oui Système gesetzt volonté et ca imho avec qui Funktion GET im "Einklang" steht.
"GetMousePos" ist aussi joli Basichaft, kenne je jedenfalls so et fands toujours entier pratique et misse es dans XProfan seither weshalb je dans qui Souris.Inc aussi qui Funktion getMousePos hineinpackte. ^ ^
bof, explode J'ai eu aussi vermisst - quoi ist daraus geworden?!
mais naturellement, mannn peux aussi getMousePos verhunzen - pourrait on aussi get("MausÄthsaPosi",Y,Z,X) draus faire gefolgt de %x%mouse et %y%mouse. -.-
un simple getmousepos! |
|
|
| |
|
|
|
Nico Madysa | So, comment du es avons veux, es du avec cela, simple qui API -- meinetwegen per Call -- trop verwenden, avec 70%-iger probabilité plus rapide et besser bedient. |
|
|
| |
|
|
|
| quoi? Pourquoi ist une mehrzeilige XProfanfunktion plus rapide comme si Roland es nativ implementiert et comment mets je Système %mousex et y? |
|
|
| |
|
|
|
Nico Madysa | veux du mir dire, dass Dieters Angebot pour deine Zwecke trop lente ist? |
|
|
| |
|
|
|
| allez um FPS (Programmeffizienz), teste la fois den Unterschied.
pourquoi sollte qui Prozessor sur 100 courir statt seulement sur 5, chez solch wichtiger Funktion aussi chez Echtzeitanwendungen? |
|
|
| |
|
|
|
| cela ici ist naturellement unheimlich vite, mais malheureusement dans Variablen statt Système schreibend: KompilierenMarqueSéparationcls
var mouse.x&=0
var mouse.y&=0
var mouse.xa&=addr(mouse.x&)
var mouse.ya&=addr(mouse.y&)
while 1
GetMousePos(%hWnd,mouse.xa&,mouse.ya&)
locate 1,1
print mouse.x&,mouse.y&," "
waitinput 100
wend
waitinput
end
nProc GetMousePos
Parameters h&,ax&,ay&
var mem&=dim(8)
ClientToScreen(h&,mem&)
var x&=long(mem&,0)
var y&=long(mem&,4)
GetCursorPos(mem&)
x&=long(mem&,0)-x&
y&=long(mem&,4)-y&
dispose(mem&)
long ax&,0=x&
long ay&,0=y&
return 0
endproc
(mais vlt. peut sich avec cela quand même pas mal travailler) |
|
|
| |
|
|