There seems to be no keydown event associated with jointjs paper. How we can capture such event ?
Solutions that I tried:
Solution 1: Capture keydown on the div element (which holds paper). It didn't work.
$('#myholder).on('keydown', (e) => {
console.log(e.which);
});
Solution 2: It seems a bit tough.
$(document).on('keydown', (e) => {
if( the previous event fired in 'blank:pointerdown' on paper and no other event is fired after that [which is equivalent to keydown on paper]) {
console.log(e.which);
}
});
Answer in this question does the trick How to grab keyboard events on an element which doesn't accept focus?
$('#paper')
.attr('tabindex', 0)
.on('mouseover', function() {
this.focus();
})
.on('keydown', function(e) {
console.log(e.which);
});
Also in the RappidJS (framework bases on the JointJS) there is the ui.Keyboard plugin which makes the keyboard handling easier http://resources.jointjs.com/docs/rappid/v2.1/ui.html#ui.Keyboard
Related
I've been trying to get a FabricJs canvas work with multitouch pan and zoom, but to no avail. I've tried countless custom builds but the event doesn't have any touch information to work on. Here's the code I use:
let fabricCanvas = new fabric.Canvas('myCanvas', {
width: canvasContainer.current.offsetWidth,
height: canvasContainer.current.offsetHeight,
isDrawingMode: true
})
fabricCanvas.on({
'touch:gesture': function(e) {
console.log(e) // returns empty object wen fired with fabricCanvas.fire("touch:gesture")
}
});
fabricCanvas.fire("touch:gesture") // I can only make the listener fire, by doing this
How can I make the gestures provided work normally?
If you look at the library code, there's a line preventing gesture event being fired when isDrawingMode is true.
in /src/mixins/canvas_gestures.mixin.js
__onTransformGesture: function(e, self) {
if (this.isDrawingMode || !e.touches || e.touches.length !== 2 || 'gesture' !== self.gesture) {
return;
}
var target = this.findTarget(e);
if ('undefined' !== typeof target) {
this.__gesturesParams = {
e: e,
self: self,
target: target
};
this.__gesturesRenderer();
}
this.fire('touch:gesture', {
target: target, e: e, self: self
});
},
I'm also trying to use gesture with drawingMode and don't know why it prevents gesture on drawingMode.
Currently, I'm trying to use a custom build with modified source code.
Or you can try not to use isDrawingMode and use mouse events to implement freedraw
I have both rowclick and rowdblclick handlers for a tabulator table, I'd like to debounce the rowclick handler so I don't get two rowclick's then a rowdblclick firing off whenever I dblclick on a row, is there a built-in method to do this? I'm aware that I can use rxjs and create a subject and debounce, but I would like to use a built in debounce if it exists.
I have a very similar issue - global row/cellClick also fire when column based cellClick fire.
My work around is to place e.stopImmediatePropagation() into the column based cellClick function. This also still allows the rowDblClick event to pass upwards/downwards etc (bubbling?). However, this is probably the reverse of what you need, unless you remove the need for a double click by putting in an event column?
var editIcon = function(cell, formatterParams, onRendered){ //plain text value
return "<i class='fa fa-edit'></i>";
};
var table = new Tabulator("#table", {
columns:[
{title:"Name", field:"name"}, //etc
{formatter:editIcon, headerSort:false, width:40, align:"center", cellClick:function(e, cell){
// do whatever
e.stopImmediatePropagation(); //prevent table wide rowClick() from also triggering
},
],
rowClick:function(e, row){
//all rows/cells will inherit this function, however the cell level cellClick function will take the first bite of the event before bubbling up to rowClick
},
});
Don't know if this helps, probably some more elegant way, but sort of works for me.
This is a standard JavaScript click event behaviour rather than anything specific to Tabulator
Any time you bind a click and double click handler the click handler will be triggered first.
I would suggest that you use a set timeout to detect if the double click has happened, you then make the double click event clear the timeout preventing the click action from happening:
var debounce = null; //hold debounce timer
var table = new Tabulator("#table", {
rowClick:function(e, row){
debounce = setTimeout(function(){
//do something
}, 100)
},
rowDblClick:function(e, row){
clearTimeout(debounce);
},
});
What I ended up doing in the end is using an EventEmitter and doing a .emit and passing the id from the row that was clicked on. Then in my pipe for my subscription to the EventEmitter I did a .distinct, eliminating the second click on the same row when double clicking.
export class XYZComponent implements AfterViewInit {
ngAfterViewInit(): void {
this.tabX = new Tabulator('#xyz', {
columns: [
// 1
{
title: 'clickable column',
field: 'X'
headerSort: false,
// visible: false,
width: '5rem',
cellDblClick: this.itemDblClick.bind(this),
cellClick: this.itemClick.bind(this),
},
//...
]
}
);
}
private itemClick(e, item) {
// both cells and rows have a getData function
this.onItemSelect(item.getData());
}
private itemDblClick(e, item) {
// both cells and rows have a getData function
this.onItemEdit(item.getData());
}
}
export class ABCComponent implements AfterViewInit {
ngAfterViewInit(): void {
this.selectItemSubject
.pipe(
takeWhile(() => this.active)
, distinctUntilChanged() // this will eliminate the second click
)
.subscribe(item => {
// load additional data for item
});
this.editItemSubject.pipe(
takeWhile(() => this.active)
)
.subscribe((item) => {
// do whatever to edit the item
});
}
}
Relative newbie; forgive me if my etiquette and form here aren't great. I'm open to feedback.
I have used create-react-native-app to create an application using PouchDB (which I believe ultimately uses AsyncStorage) to store a list of "items" (basically).
Within a TabNavigator (main app) I have a StackNavigator ("List screen") for the relevant portion of the app. It looks to the DB and queries for the items and then I .map() over each returned record to generate custom ListView-like components dynamically. If there are no records, it alternately displays a prompt telling the user so. In either case, there is an "Add Item" TouchableOpacity that takes them to a screen where they an add a new item (for which they are taken to an "Add" screen).
When navigating back from the "Add" screen I'm using a pattern discussed quite a bit here on SO in which I've passed a "refresh" function as a navigation param. Once the user uses a button on the "Add" screen to "save" the changes, it then does a db.post() and adds them item, runs the "refresh" function on the "List screen" and then navigates back like so:
<TouchableOpacity
style={styles.myButton}
onPress={() => {
if (this.state.itemBrand == '') {
Alert.alert(
'Missing Information',
'Please be sure to select a Brand',
[
{text: 'OK', onPress: () =>
console.log('OK pressed on AddItemScreen')},
],
{ cancelable: false }
)
} else {
this.createItem();
this.props.navigation.state.params.onGoBack();
this.props.navigation.navigate('ItemsScreen');
}
}
}
>
And all of this works fine. The "refresh" function (passed as onGoBack param) works fine... for this screen. The database is called with the query, the new entry is found and the components for the item renders up like a charm.
Each of the rendered ListItem-like components on the "List screen" contains a react-native-slideout with an "Edit" option. An onPress for these will send the user to an "Item Details" screen, and the selected item's _id from PouchDB is passed as a prop to the "Item Details" screen where loadItem() runs in componentDidMount and does a db.get(id) in the database module. Additional details are shown from a list of "events" property for that _id (which are objects, in an array) which render out into another bunch of ListItem-like components.
The problem arises when either choose to "Add" an event to the list for the item... or Delete it (using another function via [another] slideout for these items. There is a similar backward navigation, called in the same form as above after either of the two functions is called from the "Add Event" screen, this being the "Add" example:
async createEvent() {
var eventData = {
eventName: this.state.eventName.trim(),
eventSponsor: this.state.eventSponsor.trim(),
eventDate: this.state.eventDate,
eventJudge: this.state.eventJudge.trim(),
eventStandings: this.state.eventStandings.trim(),
eventPointsEarned: parseInt(this.state.eventPointsEarned.trim()),
};
var key = this.key;
var rev = this.rev;
await db.createEvent(key, rev, eventData);
}
which calls my "db_ops" module function:
exports.createEvent = function (id, rev, eventData) {
console.log('You called db.createEvent()');
db.get(id)
.then(function(doc) {
var arrWork = doc.events; //assign array of events to working variable
console.log('arrWork is first assigned: ' + arrWork);
arrWork.push(eventData);
console.log('then, arrWork was pushed and became: ' + arrWork);
var arrEvents = arrWork.sort((a,b)=>{
var dateA = new Date(a.eventDate), dateB = new Date(b.eventDate);
return b.eventDate - a.eventDate;
})
doc.events = arrEvents;
return db.put(doc);
})
.then((response) => {
console.log("db.createEvent() response was:\n" +
JSON.stringify(response));
})
.catch(function(err){
console.log("Error in db.createEvent():\n" + err);
});
}
After which the "Add Event" screen's button fires the above in similar sequence to the first, just before navigating back:
this.createEvent();
this.props.navigation.state.params.onGoBack();
this.props.navigation.navigate('ItemsDetails');
The "refresh" function looks like so (also called in componentDidMount):
loadItem() {
console.log('Someone called loadItem() with this.itemID of ' + this.itemID);
var id = this.itemID;
let totalWon = 0;
db.loadItem(id)
.then((item) => {
console.log('[LOAD ITEM] got back data of:\n' + JSON.stringify(item));
this.setState({objItem: item, events: item.events});
if (this.state.events.length != 0) { this.setState({itemLoaded: true});
this.state.events.map(function(event) {
totalWon += parseInt(event.eventPointsEarned);
console.log('totalWon is ' + totalWon + ' with ' +
event.eventPointsEarned + ' having been added.');
});
};
this.setState({totalWon: totalWon});
})
.catch((err) => {
console.log('db.loadItem() error: ' + err);
this.setState({itemLoaded: false});
});
}
I'm at a loss for why the List Screen refreshes when I add an item... but not when I'm doing other async db operations with PouchDB in what I think is similar fashion to modify the object containing the "event" information and then heading back to the Item Details screen.
Am I screwing up with Promise chain someplace? Neglecting behavior of the StackNavigator when navigating deeper?
The only other difference being that I'm manipulating the array in the db function in the non-working case, whereas the others I'm merely creating/posting or deleting/removing the record, etc. before going back to update state on the prior screen.
Edit to add, as per comments, going back to "List screen" and the opening "Item Details" does pull the database data and correctly shows that the update was made.
Further checking I've done also revealed that the console.log in createEvent() to print the response to the db call isn't logging until after some of the other dynamic rendering methods are getting called on the "Item Details" screen. So it seems as though the prior screen is doing the get() that loadItem() calls before the Promise chain in createEvent() is resolving. Whether the larger issue is due to state management is still unclear -- though it would make sense in some respects -- to me as this could be happening regardless of whether I've called my onGoBack() function.
Edit/bump: I’ve tried to put async/await to use in various places in both the db_ops module on the db.get() and the component-side loadItem() which calls it. There’s something in the timing of these that just doesn’t jive and I am just totally stuck here. Aside from trying out redux (which I think is overkill in this particular case), any ideas?
There is nothing to do with PDB or navigation, it's about how you manage outer changes in your depending (already mounted in Navigator since they are in history - it's important to understand - so componentDidMount isn't enough) components. If you don't use global state redux-alike management (as I do) the only way to let know depending component that it should update is passing corresponding props and checking if they were changed.
Like so:
//root.js
refreshEvents = ()=> { //pass it to DeleteView via screenProps
this.setState({time2refreshEvents: +new Date()}) //pass time2refreshEvents to EventList via screenProps
}
//DeleteView.js
//delete button...
onPress={db.deleteThing(thingID).then(()=> this.props.screenProps.refreshEvents())}
//EventList.js
...
constructor(props) {
super(props);
this.state = {
events: [],
noEvents: false,
ready: false,
time2refreshEvents: this.props.screenProps.time2refreshEvents,
}
}
static getDerivedStateFromProps(nextProps, currentState) {
if (nextProps.screenProps.time2refreshEvents !== currentState.time2refreshEvents ) {
return {time2refreshEvents : nextProps.screenProps.time2refreshEvents }
} else {
return null
}
}
componentDidMount() {
this._getEvents()
}
componentDidUpdate(prevProps, prevState) {
if (this.state.time2refreshEvents !== prevState.time2refreshEvents) {
this._getEvents()
}
}
_getEvents = ()=> {
//do stuff querying db and updating your list with actual data
}
I need make an App that has about 30k Objects, a user can Pan, Zoom or "Select on click" any of those objects.
Fabric.js Canvas is being used
I have done the same using SVG's and the svg-pan-zoom plugin (no Canvas Element) with better results
Problem: there is a significant Lag while Zooming, Panning or Object on Click
will removing Fabric.js improve performance?
will switching to WebGL improve performance?
Have tried Fabric specific options
fabric.Object.prototype.objectCaching = false;
fabric.Object.prototype.statefullCache = false;
fabric.Object.prototype.noScaleCache = true;
fabric.Object.prototype.needsItsOwnCache = false;
UPDATE
Heres the updated Fiddle
for reference :
canvas-vs-svg-vs-div Stackoverflow
Stackoverflow
Don't Render in IO EVENTS!
Though not a complete fix to the update speed this answer will about double the interaction speed.
A common, almost standard, mistake made with mouse and event interaction with the canvas (and DOM) is to delegate rendering to mouse/touch events. This is very bad practice as mouse events fire at much higher rates than the display can display. It becomes worse when your rendering time is high as you queue up mouse events (pseudo render events) and do a re render for every movement of the mouse
Note blocking code will stop mouse events but as soon as the engine is idle the mouse will start firing at full rate again.
Use the mouse events just to get the mouse state. Use an animation loop that is synced to the display to render only when needed and there is time available. Things like the wheel and mouse movement deltas should be recorded cumulatively.
mouse.dx += event.movementX;
mouse.dy += event.movementY;
mouse.wheel += event.wheelDelta;
And consume them in the main render loop...
function update(){
// ... code to use mouse
// consume deltas
mouse.x = mouse.y = mouse.wheel = 0;
...this ensures that the mouse state is accurately followed when you may have many mouse events between render updates.
Example, separating events from rendering.
Change you code in the fiddle you provided to the following, on my machine it about doubled the rendering speed (which is still very slow).
// from just after the function applyZoom replace all the code
var mouse = { // holds the mouse state
x : 0,
y : 0,
down : false,
w : 0,
delta : new fabric.Point(0,0),
}
// event just track mouse state
function zoom(e) {
if(e != null) { e.preventDefault() }
var evt=window.event || e;
mouse.x = e.offsetX;
mouse.y = e.offsetY;
mouse.w += evt.detail? evt.detail*(-120) : evt.wheelDelta;
return false;
}
canvas.on('mouse:up', function (e) { mouse.down = false });
canvas.on('mouse:out', function (e) { mouse.down = false });
canvas.on('mouse:down', function (e) { mouse.down = true });
canvas.on('mouse:move', function(e) {
if (e && e.e) {
mouse.delta.x += e.e.movementX;
mouse.delta.y += e.e.movementY;
}
});
// main animation loop
function update(){
if(mouse.w !== 0){ // if the wheel has moved do zoom
var curZoom = canvas.getZoom();
canvas.zoomToPoint(
{ x : mouse.x, y: mouse.y },
canvas.getZoom() + mouse.w / 4000
);
mouse.w = 0; // consume wheel delta
}else if(mouse.down) { // if mouse button down
canvas.relativePan(mouse.delta);
}
// consume mouse delta
mouse.delta.x = 0;
mouse.delta.y = 0;
requestAnimationFrame(update);
}
requestAnimationFrame(update);
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Cross-browser way to get automatically repeating keydown events when key is held down
I'm trying to create a simple game in JavaScript/CSS/HTML, and I am using jQuery (and a little bit of Underscore) to handle key presses. The player controls a block using arrow keys. I've run into a problem with handling multiple keypresses at the same time. I have a system in place where a closure keeps track of all arrow keys that are pressed. This works well if the player presses keys in the following sequence:
Player presses Down (block moves down)
Player presses Left (block moves diagonally down-left)
Player releases Down (block moves left)
Player releases Left (block stops
However, the block stops if steps 3 and 4 are reversed. Here is what actually happens in that case:
Player presses Down (block moves down)
Player presses Left (block moves diagonally down-left)
Player releases Left (block stops)
The expected behavior is that on step 3, the block would continue to move down, rather than stopping completely.
From traces I have put in the code, it appears that a keyup event actually stops the propagation of further keydown events, even when my finger is still holding down one of the arrow keys.
Here is a snippet of relevant code. Can anyone tell me where the problem might be?
// Creates an animation handler for a specific element.
// Animation reacts to any changes as they are submitted
var getMovementAnimator = function(element) {
var params = {},
$element = $(element);
return function(changes) {
_.each(changes, function(val, key) {
// Remove null or zeroish keys from animation params
if ( (val == 0 || !val) && _.has(params, key)) {
delete params[key];
} else {
params[key] = '+=' + val + 'px';
}
});
$element.animate(params, {duration: 0, queue: false});
console.log(params);
};
};
// Determines direction and speed of movement for an element
// after a keypress event
var getMovementChange = function(keyEvent, keydown) {
var isMoving = !!keydown,
params = {},
dir = '',
speed = keydown ? 5 : 0,
arrows = {left: 37, up: 38, right: 39, down: 40};
switch (keyEvent.which) {
case arrows.left:
dir = 'left';
speed = -speed;
break;
case arrows.up:
dir = 'top';
speed = -speed;
break;
case arrows.right:
dir = 'left';
break;
case arrows.down:
dir = 'top';
break;
}
// If key hit not one of above, do nothing
if (!dir) {
return false;
}
if (!speed) {
console.log('key up: ', dir);
}
params[dir] = speed;
return params;
}
// Sets up key handlers
$(document).ready(function() {
var board = $('#board'),
animatePlayer = getMovementAnimator('.player');
$(document).keydown(function(e) {
e.preventDefault();
var changes = getMovementChange(e, true);
animatePlayer(changes);
}).keyup(function(e) {
e.preventDefault();
var changes = getMovementChange(e, false);
animatePlayer(changes);
});
});
Further search on Stack Overflow (using the right keywords) showed me that the issue I am seeing is not actually a bug in my code. Rather, this is expected behavior for the operating system.
However, I found a workaround which I believe will resolve the issue.