schleicher on 31/1/2017 at 13:08
Quote Posted by Unna Oertdottir
Not very likely. ;)
Is this a notebook or something?
No. Its a Desktop-PC.
And the Idea about the mainboard is the only one I have.
Win7 could not be the reason, I think. There is no special driver or setting.
And dromed is the only program here, that shows this behaviour.
Unna Oertdottir on 31/1/2017 at 13:31
You could try to edit dromed.cfg
Quote:
; movement threshold (in pixels) that the mouse must move before a drag-edit operation will be initiated in
; in the editor viewport (a drag-edit operation is translating/rotating/scaling a brush directly in a viewport)
; default is 8 pixels
;dragedit_move_threshold 16
schleicher on 31/1/2017 at 13:35
I've found the reason:
I wrote a little testprogram and found out, that on my system the WM_MOUSEMOVE-Message
is fired the whole time. Without moving the mouse. This happens on some systems, as I found
in the net.
To avoid this, the programmer has to detect whether there are REAL mouse-movings (as example via testing the position).
In dromed it seems, there is no such test.
schleicher on 31/1/2017 at 13:37
Quote Posted by Unna Oertdottir
You could try to edit dromed.cfg
Thank you ! I will test it, when I am back at home.
Maybe this could be an workaround for the problem, I wrote above.
Unna Oertdottir on 31/1/2017 at 13:40
This isn't funny :erg:
schleicher on 31/1/2017 at 15:23
@Unna: Thank you, for your idea with dragedit_move_threshold. But unfortunately it doesn't helps.
So I have to move/scale via the edit-fields.
It is a bit circuitous, but at least: It works ;-)
qolelis on 31/1/2017 at 16:31
This can also happen if a large part of the DromEd window is off-screen, so a suggestion is to check that.
schleicher on 31/1/2017 at 19:58
No. Dromed is a pretty small window here.
john9818a on 1/2/2017 at 01:07
What would happen if you removed the mouse driver and then let Windows find it again?
schleicher on 1/2/2017 at 07:52
Same Behaviour after reinstalling the driver.
