I've been trying to get a two image slider working with a mouseOver event in react.js. I've seen a similar component linked here: codepen.io/bradtraversy/pen/NaKxdP
The problem seems to be a huge delay with refreshing the image as well as onMouseOver events that occasionally fire with an offsetX coordinate that is way off from what it should be. Thanks for any help. A demonstration of the problem I'm experiencing is linked in the codesandbox below.
https://codesandbox.io/s/romantic-perlman-tzze4?file=/src/App.js
I can't exactly contest as to why the offsetX is acting the way it does and am unable to verify what exactly you mean by refreshing the image being slow but using your codesandbox code I replaced:
if (Math.abs(xCoor - e.nativeEvent.offsetX) >= 2)
setXCoor(e.nativeEvent.offsetX);
console.log(e.nativeEvent.offsetX);
With:
if (Math.abs(xCoor - e.nativeEvent.clientX) >= 2)
setXCoor(e.nativeEvent.clientX -5);
console.log(e.nativeEvent.clientX);
And I am at least able to fix the flashing when the offsetX sets back to the odd numbers.
Based on some other things I was reading while researching this, offsetX seems to provide inconsistent values randomly (as you have noticed). This answer delves into it more and may be able to help you along further setting something up that is more consistent.
I've attached an updated answer here:
https://codesandbox.io/s/zealous-johnson-73myy?file=/src/App.js
This uses a ref to the underlying DOM node to access the bounding rectangle and then use the clientX method as suggested by JFoxx64 to get offset within the element itself. I think his method is also just as valid, we just discovered them at the same time. Thanks!
Related
I am having troubles trying to update the context.listener's position (each requestAnimationFrame) in an application using Web Audio. I have made a test environment here with some variations but none of them seems to really work.
This is what i assume the correct approach is:
listener.positionX.value = pos.x;
listener.positionY.value = pos.y;
listener.positionZ.value = pos.z;
The issue i am having is that the sound is being completely distorted, and turning the source volume down does not help. (this may very well be a bug in Chrome OSX, since i don't remember having any issues when i made something similar before, which i ran on Chrome Windows)
I also tried doing this (these 2 lines should be exactly the same btw), but that didn't help either:
listener.positionX.setValueAtTime(pos.x, 0);
listener.positionX.setValueAtTime(pos.x, context.currentTime);
Then i tried the old and deprecated command to do this, and that sounds way better but still has slight distortion:
listener.setPosition(pos.x, pos.y, pos.z);
The one that seems to work best is to do a linear ramp:
listener.positionX.linearRampToValueAtTime(pos.x, context.currentTime + 0.1);
But doing a new ramp on every frame is not really the correct approach, since ongoing ramps are cancelled and i think it takes the value before the cancelled ramp as the starting value for the new ramp. Also: when i then NOT update the value (i added that as an option in that codepen), it seems to jump back to a previous value, which leads me to think that that is maybe also the cause for the major distortion i hear when doing the ver first approach (setting the value by positionX.value = pos.x)
Am i doing something wrong, or am i overlooking something? How should i correctly set the listener's position on every frame?
Using the .value setter and setPosition is supposed to instantly move the listener to that position. This will cause glitches. (Not all browsers have implemented this behavior so some will smoothly move somehow from the old to the new position.)
A linear ramp (or other automation) is the correct way to move from one location to the next.
I didn't hear any artifacts with Chrome 71 on a macbook using the built-in speakers. Perhaps I would if I used headphones?
I'm trying to do a menu of sorts with a d3.js treemap. It mostly works, but I'm having a few glitches that I can't pinpoint.
Basically, sometimes my chart doesn't zoom correctly and instead of seeing the children take the whole SVG area, they show up "unzoomed".
I suspect it must have something to do with the animation's timing vs. some data manipulation for hiding/showing the different nodes, but can't actually figure it out. Other thing I thought might be borking up the behavior relates to the click events being registered by both "parent" and "children" nodes.
I have a similar example setup in JSBIN.
So, I was wondering how I could register/unregister click events in the parent/child nodes on zoom - if that's even the problem - and also if there was a simpler or less-error prone way to change the nodes' visibility.
Any help is welcome!
Well, this might be a bit unorthodox, but I found a way to overcome this.
Basically, instead of trying to mess around with event registering/unregistering, I simply ran the zoom only if the click wasn't from the node at the current zoom level.
So, in my zoom function, I wrapped the zoom handling in an if check:
function zoom(d) {
if(node!=d){
// the rest remains the same
}
}
Either way, I still think that this was happening due to the source elements where the click events were coming from being overlapped in the SVG area - simply put, the click event was being triggered by several overlapping elements, being the first (topmost) in the SVG tree order triggered inadvertently.
Here's a working version.
Hope this helps someone else!
EDIT: This solution isn't perfect, though. Now sometimes the click just doesn't do anything - But it's better than borking the UI. If anyone has other ideas, they're welcome.
I have a small problem, i need to get mouse co-ordinates when user clicks on page..
Here I need to get position relative to document(page) nor relative to found..
After browsing a day , i found one solution i.e., window.event.pageY.
but its working only for Chrome.. not in IE, not Firefox.
Can any one help me on this...If solution is in javascript, then usefull for me..
An example given will be appreciated..
thanks.
Rajesh
You could used jQuery's normalized event object with pageX/pageY. See the example code in their SDK.
EDIT: For a pure js solution, try this post - Mouse position - Cross browser compatibility - Javascript
QuirksMode is always helpful too.
I do have a Paper.path() in Raphael that is filled with a simple texture:
var fill = screen.path(Iso.topFacePath(top)).attr({
fill: 'url(http://www.example.com/mytexture.jpg)',
});
The path can be altered by the user via drag and drop. For this I use Element.drag() to bind the handlers.
The problem that I encouter now is that while the onmove-handler function is called the element in question will be recalculated and has to be drawn again. Apparently this is "too much" for raphael and the fill pattern will disappear randomly (flicker) and appear again some time later (at latest onend).
The actual code I use is a little too much to post here but I built a fiddle where you can see what's going on (you can drag the upper sides of the quadrangle).
Is there a simple fix to this?
I am used to canvas much more than raphael (actually this is the first time I really use raphael) so maybe my approach of redrawing everything everytime sth changes is plain wrong?
EDIT: I just found out that seems to be somehow browser-related as well. Chrome and Firefox will produce the flicker where Safari seems to do everything just fine.
This seems to be caching issue (raphael.js does not cache the bitmap fill and will reload it on every change) and is fixed (for me) by this pull request on GitHub that is (as of 08/14/2012) still pending.
Raphael is pretty hard / impossible to build oneself as the make file points to local and/or inexistent files, but you can either concatenate everything by hand, modify the build script or use the modified build that is used in the example to get hold of the fix.
Let's hope it will find its way into a future release of Raphael.
I need to implement drag and drop functionalities in a web application between elements present in a web page, and elements inside an iframe (before you start complaining about iframes, I NEED it for technical reasons, it's not an option).
I have elements in the page that can be dragged into target droppable elements inside an iframe.
I've managed to do it with both jQuery UI and YUI, though both libraries present the same problem: the target element (droppable target) coordinates are misinterpreted, the drop area considered by both libraries is wrong and does not represent the actual droppable object, hence the collisions between the dragged object and the dropped element are messed up entirely. It's like the library sees the droppable element positioned in another place from where it effectively is.
I think this is due to the iframe not being positioned on top-left of page, but in the middle. I think this because I've read many people complaining about this issue and the problem went off if the iframe was top-left positioned. Someone suggest that the coordinates of the droppable element may be calculated based on screenX and screenY, instead of clientX and clientY, and this may be the cause of the issue, not taking into consideration the elements are inside an iframe, and so the coordinates differ between other elements outside the iframe.
So, since it seems there's no way to fix this directly using the library functionalities, and I really don't have time to try every library avaiable out there, I'm thinking about fixing the issue by modifying (patching) the internal functions of the library in question.
The questions are:
1) Did someone experience this behavior before, and managed to fix the issue? Or, is there a library which is able to do this flawlessly?
2) Is there some way to fix this issue using the methods and functionalities of the library itself? And if not,
3) Does somebody know which part of the library calculates the droppable area coordinates, so that I can fix it as a last extreme option?
Thanks in advance, even the smallest help will be appreciated!
EDIT
This fiddle demonstrate the problem. Try to move the green square inside the red square (which is inside an iframe). You will notice the collision between the two squares is wrong.
http://jsfiddle.net/DQdZ9/23/
This is not a "silver bullet" , but I'll go ahead and post this as an answer, but I'm not sure how much value it will have for you. I tracked down a key function in jQuery UI that might be what you're looking for. It's in $.ui.ddmanager (the drag and drop manager), and the function is prepareOffsets. This line:
m[i].offset = m[i].element.offset();
seems to be the one that is setting up the offset for use when the element is actually dropped. This might be a place to fiddle with to adjust the resulting offset based on whether the droppable element is a child of the iframe.
There is another function above it $.ui.intersect that performs the logic to see if the draggable and droppable are intersecting each other.
I'm in the latest release of jQuery UI, and the file is jquery-ui-1.8.14.custom.js on line 2012-2029. If you get the single droppable file itself, jquery.ui.droppable.js, it's on lines 203-220. And these are the dev files, not the min files.