Used Robot.js extension from the example to allow keyboard accessible palette selection.
Works fine but I can’t understand the mouseMove and what values should it take. It doesn’t seem to change much and the mouse up seems to be the important one to set correctly.
Thanks
In order to replicate the normal behaviors users get with the mouse or finger or stylus, one should generate down-move-and-up events, not just an up event.
That is needed in order to cause the appropriate tool to run, such as the DraggingTool.
So if I get what you’re saying, we need to mimic all operations, but the mouseMove coordinates don’t mean much and could just match the mouseUp for clarity, if anything ?
It depends on the tool that is running. The ClickSelectingTool, for example, doesn’t care about move events. The DraggingTool behavior may well depend on the intermediate move points, depending on side effects that the programmer may have implemented that happen during a drag.
So it really depends on the situation.
Not sure if it’s related to this exact question about MouseMove, but my palette keyboard operation are not working reliably and I’m lost as how to debug it.
Since this is for palette operations, I am dealing with a palette diagram (source) and my main diagram (target).
I am registering my drop location passed to mouseUp and added a small utility based on the coordinate example to click (Ctrl-Shift-Click) any place to get the coordinates and I see that I am dropping at the right location. Dragging with the mouse to that location works fine.
Now I added a console log on my dragging tool computeEffectiveCollection and it is not called. I did the same for the mouse move and mouse up in robots and they are called, but I am not sure of what they are doing.
For example, the mouse move is defined in terms of the source, i.e. the palette, so where should it move to, to outside the range of the palette diagram?
What else can I do to track what is going on here?
Thanks
Alain
Is everything working the way that you want when the user interacts with the diagrams?
You want that to be true before you start testing your app. We would like to understand whether you are talking about using the app or about testing with Robot.
The app has been running well for years, and still does.
It is when using robots that the issue happens. The first step about a week ago was to use robot to drag from the palette in diagrams that have no drop constraints. It picks a location at the center and just above the current top and drops there.
Now for diagrams that have specific drop locations we need to determine the drop location and drag and drop to a specific spot. This works, but not reliably. And it is where I’m stuck, as to how to best debug the behavior of robot compare to the mouse user.
I now added a bunch of console log and even added a DebugDraggingTool to capture logs as well to see what a mouse drag does.
The strange thing is that it works with the logs:
Palette Drop loc:Point(-330,-622.1546417308602)
Robot.js:97 Robot mouseDown:^@Point(92.5,60.76819353119392),tool:ToolManager Tool
Robot.js:125 Robot mouseMove:^@Point(100,100),tool:ToolManager Tool
Robot.js:155 Robot mouseUp simulated:^@Point(-330,-622.1546417308602),src:undefined,target:Diagram "mainDiagramDiv"
DebugDraggingTool.js:40 calling doDropOnto:Point(-330,-622.1546417308602),obj:Shape(RoundedRectangle)#2021
Robot.js:157 Simulated mouse up returning
Is it possible that there is some timing issues when robot runs, since it is too fast?
Alain
Are you passing reasonable, realistic values for the timestamp argument?
Instrumenting the behavior with the mouse is a good idea.
If you have a particular GraphObject at which you want an event to happen, call its GraphObject.getDocumentPoint method.