Mapping Touchscreen Events to Mouse Events
-
Do any of you have experience with something like this? I spent most of yesterday experimenting. I originally designed my project to run on a laptop, or desktop computer with a keyboard and mouse. I omitted touchscreen functionality on the website up until recently. I became curious about an idea, and I had to see if it was possible and practical for implementation. Is it possible to convert touchscreen interaction events (e.g. 'touchstart', 'touchend', 'touchmove', 'touchcancel') to automatically dispatch the corresponding synthetic mouse events? For example, would it be possible to touch the screen, move your finger, and make it behave as a mousemove event? It might be. So, I had to find out. You'd think there would be a standardized way to accomplish this sort of thing. As more websites are accessed through touchscreen tablets, developers who didn't have a need for touchscreen functionality before must now implement it, or risk being left behind in the stone age. I spent a few hours digging around to see how it could be done. I didn't find much at all, and neither did I see any sort of standardized way to map touch events to mouse events. I did find a simple set of methods that are claimed to work, so I tried them out. It was crude and inadequate, but I found proof of concept that it's possible. Below are the two sample methods that I used for reference. The source URL is also included. JavaScript mapping touch events to mouse events[^]
function touchHandler(event)
{
var touches = event.changedTouches,
first = touches[0],
type = "";
switch(event.type)
{
case "touchstart": type = "mousedown"; break;
case "touchmove": type = "mousemove"; break;
case "touchend": type = "mouseup"; break;
default: return;
}// initMouseEvent(type, canBubble, cancelable, view, clickCount, // screenX, screenY, clientX, clientY, ctrlKey, // altKey, shiftKey, metaKey, button, relatedTarget); var simulatedEvent = document.createEvent("MouseEvent"); simulatedEvent.initMouseEvent(type, true, true, window, 1, first.screenX, first.I'm not answering crap until you start recognizing my replies with at least a like. So here's the short answer, you're going about this the wrong way and over complicating it. Those events should be a proxy for the real handler that it's a user defined routine. Why? Two reasons: 1) You don't have to do this. 2) You can manually call the user defined handlers if you need to automate functionality. Say, you're trying to replay a user's interaction with the website. You're welcome.
Jeremy Falcon
-
I'm not answering crap until you start recognizing my replies with at least a like. So here's the short answer, you're going about this the wrong way and over complicating it. Those events should be a proxy for the real handler that it's a user defined routine. Why? Two reasons: 1) You don't have to do this. 2) You can manually call the user defined handlers if you need to automate functionality. Say, you're trying to replay a user's interaction with the website. You're welcome.
Jeremy Falcon
Jeremy Falcon wrote:
I'm not answering crap until you start recognizing my replies with at least a like.
When did this site turn in to StackOverflow? :wtf: If you don't want to answer the question, then don't answer. Don't reply just to berate the user for not "liking" your previous replies.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Do any of you have experience with something like this? I spent most of yesterday experimenting. I originally designed my project to run on a laptop, or desktop computer with a keyboard and mouse. I omitted touchscreen functionality on the website up until recently. I became curious about an idea, and I had to see if it was possible and practical for implementation. Is it possible to convert touchscreen interaction events (e.g. 'touchstart', 'touchend', 'touchmove', 'touchcancel') to automatically dispatch the corresponding synthetic mouse events? For example, would it be possible to touch the screen, move your finger, and make it behave as a mousemove event? It might be. So, I had to find out. You'd think there would be a standardized way to accomplish this sort of thing. As more websites are accessed through touchscreen tablets, developers who didn't have a need for touchscreen functionality before must now implement it, or risk being left behind in the stone age. I spent a few hours digging around to see how it could be done. I didn't find much at all, and neither did I see any sort of standardized way to map touch events to mouse events. I did find a simple set of methods that are claimed to work, so I tried them out. It was crude and inadequate, but I found proof of concept that it's possible. Below are the two sample methods that I used for reference. The source URL is also included. JavaScript mapping touch events to mouse events[^]
function touchHandler(event)
{
var touches = event.changedTouches,
first = touches[0],
type = "";
switch(event.type)
{
case "touchstart": type = "mousedown"; break;
case "touchmove": type = "mousemove"; break;
case "touchend": type = "mouseup"; break;
default: return;
}// initMouseEvent(type, canBubble, cancelable, view, clickCount, // screenX, screenY, clientX, clientY, ctrlKey, // altKey, shiftKey, metaKey, button, relatedTarget); var simulatedEvent = document.createEvent("MouseEvent"); simulatedEvent.initMouseEvent(type, true, true, window, 1, first.screenX, first.You may find it easier to rewrite the code to use pointer events instead of mouse / touch events.
Pointer events - Web APIs | MDN[^]:
Pointer events ... are designed to create a single DOM event model to handle pointing input devices such as a mouse, pen/stylus or touch (such as one or more fingers).
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I'm not answering crap until you start recognizing my replies with at least a like. So here's the short answer, you're going about this the wrong way and over complicating it. Those events should be a proxy for the real handler that it's a user defined routine. Why? Two reasons: 1) You don't have to do this. 2) You can manually call the user defined handlers if you need to automate functionality. Say, you're trying to replay a user's interaction with the website. You're welcome.
Jeremy Falcon
Jeremy Falcon wrote:
I'm not answering crap until you start recognizing my replies with at least a like.
LOL. I'm sorry about that.
Jeremy Falcon wrote:
You can manually call the user defined handlers
I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy. Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work. Except for one.
Jeremy Falcon wrote:
- You don't have to do this.
It's actually done! I finished it almost an hour ago. It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined. :thumbsup: I told you it was going to take a lot of code. Here it is as of now: https://chromosphere.com/chromosphere/scripts/js/ui/events/ui_touch_functions_d_f.js[^]
-
You may find it easier to rewrite the code to use pointer events instead of mouse / touch events.
Pointer events - Web APIs | MDN[^]:
Pointer events ... are designed to create a single DOM event model to handle pointing input devices such as a mouse, pen/stylus or touch (such as one or more fingers).
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Richard Deeming wrote:
You may find it easier to rewrite the code to use pointer events instead of mouse / touch events.
I checked out the link. It looks like it could be a viable option, but what took several hours for me to fix today was related to performance issues that would exist regardless of the events I used. It's not only a performance issue that's related to disallowing all passive events from being canceled by the browser, it's also the errors that are thrown when you attempt to cancel a passive event using the 'event.preventDefault' method. Viewing the console log was cringeworthy for a while there. I'm glad I can say that's all fixed now. :)
-
Jeremy Falcon wrote:
I'm not answering crap until you start recognizing my replies with at least a like.
When did this site turn in to StackOverflow? :wtf: If you don't want to answer the question, then don't answer. Don't reply just to berate the user for not "liking" your previous replies.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Leave me the hell alone, Richard. Nobody has time for your childish nonsense. Go be hateful to someone else.
Jeremy Falcon
-
Jeremy Falcon wrote:
I'm not answering crap until you start recognizing my replies with at least a like.
LOL. I'm sorry about that.
Jeremy Falcon wrote:
You can manually call the user defined handlers
I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy. Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work. Except for one.
Jeremy Falcon wrote:
- You don't have to do this.
It's actually done! I finished it almost an hour ago. It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined. :thumbsup: I told you it was going to take a lot of code. Here it is as of now: https://chromosphere.com/chromosphere/scripts/js/ui/events/ui_touch_functions_d_f.js[^]
Steve Raw wrote:
I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy.
By proxy I don't mean necessarily adding new events. But, for the events you do handle have them call another function that's the real handler. That way, more than one event can be used for the same handler. It's a lot less messy than trying to map event A to event B.
Steve Raw wrote:
Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work.
Well, first things first... you need to remove those thousands of event handlers. Bubbling and capturing (trickling) are plenty enough to not need 90% of those I bet. Not sure if you read into bubbling and capturing, but here's a [quick summary](https://www.quirksmode.org/js/events\_order.html). In short, bubbling goes up and capturing goes down. Check out the docs on [addEventListener](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener). There's a `useCapture` parameter. The default bubbles but you can change it to capturing mode via that parameter. Suffice it to say though, events will always propagate (unless canceled in the handler), and that's a good thing as you'll need less of them. Assuming it's a top level event, bubbling is preferred. If it's a very specific element then capturing may be preferred. But, either way you go, the important thing to do remember is you don't need events on every element. As you discovered it's gonna bring your site to a crawl.
Steve Raw wrote:
It's actually done! I finished it almost an hour ago.
Nice
Steve Raw wrote:
It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined. :thumbsup:
Nice. Isn't web development fun? :laugh:
Jeremy Falcon
-
Jeremy Falcon wrote:
I'm not answering crap until you start recognizing my replies with at least a like.
LOL. I'm sorry about that.
Jeremy Falcon wrote:
You can manually call the user defined handlers
I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy. Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work. Except for one.
Jeremy Falcon wrote:
- You don't have to do this.
It's actually done! I finished it almost an hour ago. It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined. :thumbsup: I told you it was going to take a lot of code. Here it is as of now: https://chromosphere.com/chromosphere/scripts/js/ui/events/ui_touch_functions_d_f.js[^]
Btw, if it makes you feel better, I just asked a very n00bish question (different site) for a different programming language I'm new at. So, we all go through this phase. It's a rite of passage. :laugh:
Jeremy Falcon
-
Jeremy Falcon wrote:
I'm not answering crap until you start recognizing my replies with at least a like.
LOL. I'm sorry about that.
Jeremy Falcon wrote:
You can manually call the user defined handlers
I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy. Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work. Except for one.
Jeremy Falcon wrote:
- You don't have to do this.
It's actually done! I finished it almost an hour ago. It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined. :thumbsup: I told you it was going to take a lot of code. Here it is as of now: https://chromosphere.com/chromosphere/scripts/js/ui/events/ui_touch_functions_d_f.js[^]
Btw, Richard's idea of using a pointer event is a good one. Just look past the stupid immature little whine fest he's got going on with me. He insulted me in another thread and is surprised I didn't stand for it. So, now he's just being childish. But, pointer events are useful.
Jeremy Falcon
-
Steve Raw wrote:
I tried adding touchstart, touchmove, and touchstart at the window level, the document level, body element level, web-window level, and it's too messy.
By proxy I don't mean necessarily adding new events. But, for the events you do handle have them call another function that's the real handler. That way, more than one event can be used for the same handler. It's a lot less messy than trying to map event A to event B.
Steve Raw wrote:
Performance was poor. I have thousands of event handlers, both inline event listeners and added event listeners using the "element.addEventListener" method. Going through each one and adding their corresponding touch event handlers would create a trainwreck of a hackjob; a complete dumpster fire of code. Every idea I have tried, or considered trying doesn't work.
Well, first things first... you need to remove those thousands of event handlers. Bubbling and capturing (trickling) are plenty enough to not need 90% of those I bet. Not sure if you read into bubbling and capturing, but here's a [quick summary](https://www.quirksmode.org/js/events\_order.html). In short, bubbling goes up and capturing goes down. Check out the docs on [addEventListener](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener). There's a `useCapture` parameter. The default bubbles but you can change it to capturing mode via that parameter. Suffice it to say though, events will always propagate (unless canceled in the handler), and that's a good thing as you'll need less of them. Assuming it's a top level event, bubbling is preferred. If it's a very specific element then capturing may be preferred. But, either way you go, the important thing to do remember is you don't need events on every element. As you discovered it's gonna bring your site to a crawl.
Steve Raw wrote:
It's actually done! I finished it almost an hour ago.
Nice
Steve Raw wrote:
It was as difficult as I had thought. It took 3+ days and about 25 hours in total. 33% was studying, another 33% was experimenting, and I spent 33% of the time testing. It works better than I had ever imagined. :thumbsup:
Nice. Isn't web development fun? :laugh:
Jeremy Falcon
Jeremy Falcon wrote:
By proxy I don't mean necessarily adding new events. But, for the events you do handle have them call another function that's the real handler. That way, more than one event can be used for the same handler.
It's so difficult to have a discussion that is so technical. To clarify what you're saying here is that for all mouse-related event listeners, whether inline, or assigned by 'element.addEventListener', I include a function call to the event handler function that handles a touch event? I have a few mouse-related event listeners assigned to the window element. I attempted to modify those window event listeners to include a corresponding touch event hander function call. I gave that a try several times in various ways. I quickly realized that using such an approach couldn't work. So, I tried using separate event listeners that handle touch events corresponding to the element's mouse event handler. In theory, that could work, but attempting to implement that would be a huge undertaking, it would be very difficult to maintain and modify. I realized that using such an approach would be like throwing rocks at a hornets nest. I feel very confident using the approach I eventually decided upon after a lot of experimentation and testing. It adheres to standards, it's efficient and uses few resources, it's no more complex than it needs to be. The code is all located in a single location which makes it easy to modify and maintain. I think it's about as ideal as it can possibly be. I'm planning on adding documentation and comments to the script today. It'll be much easier for others to understand what I'm doing once I have that completed. If you're interested, I can send you a link to view the documented code.
Jeremy Falcon wrote:
Not sure if you read into bubbling and capturing, but here's a quick summary. In short, bubbling goes up and capturing goes down.
Yep, I sure did. I studied for hours and gained a wealth of knowledge and understanding far beyond what I had before.
Jeremy Falcon wrote:
Assuming it's a top level event, bubbling is preferred. If it's a very specific element then capturing may be preferred.
Yes, I very much agree with that.
Jeremy Falcon wrote:
Nice. Isn't web development fun? :laugh:
Yes, it certainly can be. :thumbsup:
-
Btw, if it makes you feel better, I just asked a very n00bish question (different site) for a different programming language I'm new at. So, we all go through this phase. It's a rite of passage. :laugh:
Jeremy Falcon
Jeremy Falcon wrote:
Btw, if it makes you feel better, I just asked a very n00bish question (different site) for a different programming language I'm new at. So, we all go through this phase. It's a rite of passage. :laugh:
I'm pretty sure that I don't know what I'm doing. As long as I develop this stuff, I will always feel this way. It's an ongoing effort to learn and keep up with the fast pace of advancing technology. I'll soon start studying AI. I'm a complete n00b in that area. I remember the first time I saw the HTML markup used to place a hyperlinked image into an HTML page. I remember thinking to myself, "WTF is that??". :laugh:
-
Leave me the hell alone, Richard. Nobody has time for your childish nonsense. Go be hateful to someone else.
Jeremy Falcon
Mate, this seems an odd response, as does the demand for "likes". Everything OK?
cheers Chris Maunder
-
Jeremy Falcon wrote:
By proxy I don't mean necessarily adding new events. But, for the events you do handle have them call another function that's the real handler. That way, more than one event can be used for the same handler.
It's so difficult to have a discussion that is so technical. To clarify what you're saying here is that for all mouse-related event listeners, whether inline, or assigned by 'element.addEventListener', I include a function call to the event handler function that handles a touch event? I have a few mouse-related event listeners assigned to the window element. I attempted to modify those window event listeners to include a corresponding touch event hander function call. I gave that a try several times in various ways. I quickly realized that using such an approach couldn't work. So, I tried using separate event listeners that handle touch events corresponding to the element's mouse event handler. In theory, that could work, but attempting to implement that would be a huge undertaking, it would be very difficult to maintain and modify. I realized that using such an approach would be like throwing rocks at a hornets nest. I feel very confident using the approach I eventually decided upon after a lot of experimentation and testing. It adheres to standards, it's efficient and uses few resources, it's no more complex than it needs to be. The code is all located in a single location which makes it easy to modify and maintain. I think it's about as ideal as it can possibly be. I'm planning on adding documentation and comments to the script today. It'll be much easier for others to understand what I'm doing once I have that completed. If you're interested, I can send you a link to view the documented code.
Jeremy Falcon wrote:
Not sure if you read into bubbling and capturing, but here's a quick summary. In short, bubbling goes up and capturing goes down.
Yep, I sure did. I studied for hours and gained a wealth of knowledge and understanding far beyond what I had before.
Jeremy Falcon wrote:
Assuming it's a top level event, bubbling is preferred. If it's a very specific element then capturing may be preferred.
Yes, I very much agree with that.
Jeremy Falcon wrote:
Nice. Isn't web development fun? :laugh:
Yes, it certainly can be. :thumbsup:
Steve Raw wrote:
It's so difficult to have a discussion that is so technical. To clarify what you're saying here is that for all mouse-related event listeners, whether inline, or assigned by 'element.addEventListener', I include a function call to the event handler function that handles a touch event?
Maybe some code will help. A fiddle... [Using events as a proxy.](https://jsfiddle.net/jfalcon/f5c0xz9s/28/) Regardless of whether it's a touch event, click event, pointer event, etc. they can all call `dude()`. There's no need to add an extra layer of mapping to any of it. This has the benefit of allow the programmer to automate events without having to worry about going through the event cycle, but your real function is all that needs to be called. And it's waaaaay less mentally confusing.
Steve Raw wrote:
I have a few mouse-related event listeners assigned to the window element. I attempted to modify those window event listeners to include a corresponding touch event hander function call. I gave that a try several times in various ways. I quickly realized that using such an approach couldn't work. So, I tried using separate event listeners that handle touch events corresponding to the element's mouse event handler. In theory, that could work, but attempting to implement that would be a huge undertaking, it would be very difficult to maintain and modify. I realized that using such an approach would be like throwing rocks at a hornets nest.
Guess it's my turn not to follow what's being said. :laugh: Just gonna assume we're talking about a click event on window... which should be discouraged. Unless that's like the only event you have and you plan on doing the mapping accordingly. But, if there's one on window plus 1,000 others then that's a different story. But, the mapping touch basically between the same between mouse, touch, and pointer. The above fiddle also has a touch example. You can use Chrome Dev Tools to simulate the touch for testing it out. Hope I'm on the right track with understanding the ask.
Jeremy Falcon
-
Mate, this seems an odd response, as does the demand for "likes". Everything OK?
cheers Chris Maunder
The jest should've been obvious Chris. I provided an answer while saying I wasn't gonna answer. And the only reason Richard did what he did was from a carry over from something the other day. Oddly enough, it seems Steve (the person it was directed towards) was the only one that got it.
Jeremy Falcon
-
The jest should've been obvious Chris. I provided an answer while saying I wasn't gonna answer. And the only reason Richard did what he did was from a carry over from something the other day. Oddly enough, it seems Steve (the person it was directed towards) was the only one that got it.
Jeremy Falcon
That wooshing sound is the sound of this all going over my head. I'm going to grab another beer and see if that helps ;)
cheers Chris Maunder
-
That wooshing sound is the sound of this all going over my head. I'm going to grab another beer and see if that helps ;)
cheers Chris Maunder
:laugh: Cheers buddy. :beer:
Jeremy Falcon
-
Steve Raw wrote:
It's so difficult to have a discussion that is so technical. To clarify what you're saying here is that for all mouse-related event listeners, whether inline, or assigned by 'element.addEventListener', I include a function call to the event handler function that handles a touch event?
Maybe some code will help. A fiddle... [Using events as a proxy.](https://jsfiddle.net/jfalcon/f5c0xz9s/28/) Regardless of whether it's a touch event, click event, pointer event, etc. they can all call `dude()`. There's no need to add an extra layer of mapping to any of it. This has the benefit of allow the programmer to automate events without having to worry about going through the event cycle, but your real function is all that needs to be called. And it's waaaaay less mentally confusing.
Steve Raw wrote:
I have a few mouse-related event listeners assigned to the window element. I attempted to modify those window event listeners to include a corresponding touch event hander function call. I gave that a try several times in various ways. I quickly realized that using such an approach couldn't work. So, I tried using separate event listeners that handle touch events corresponding to the element's mouse event handler. In theory, that could work, but attempting to implement that would be a huge undertaking, it would be very difficult to maintain and modify. I realized that using such an approach would be like throwing rocks at a hornets nest.
Guess it's my turn not to follow what's being said. :laugh: Just gonna assume we're talking about a click event on window... which should be discouraged. Unless that's like the only event you have and you plan on doing the mapping accordingly. But, if there's one on window plus 1,000 others then that's a different story. But, the mapping touch basically between the same between mouse, touch, and pointer. The above fiddle also has a touch example. You can use Chrome Dev Tools to simulate the touch for testing it out. Hope I'm on the right track with understanding the ask.
Jeremy Falcon
Jeremy Falcon wrote:
Maybe some code will help. A fiddle... Using events as a proxy.
That's interesting. I've never used the bind method, let alone inside an addEventListener method. If I were to use that approach, then how would I set the event parameters if that bind method is located inside a click event listener? Let's say that I needed to run a passive event, such as mousemove within a click event listener. Click events are non-passive, yet mousemove events are passive. Passive events can't be canceled (without some effort, anyway), yet click events are cancelable. What if the click event is set to bubble, and the mousemove event needs to propagate as capture? I don't know how that could be done. Without being able to set those custom parameters for events, and event listeners, nothing would work. Perhaps if I added the parameters into the method as arguments, that might be possible. The solution I have now works great. It's as simple as it could possibly be. It's efficient, and every element in the DOM is automatically enabled for use with touch interaction. To make that possible, I only had to write a single subroutine. I'd say it only took a couple of minutes to write up and I'm all done. It seems to be an ideal solution in every way. If there's a better way to go about it, then I'm open to ideas.
-
Jeremy Falcon wrote:
Maybe some code will help. A fiddle... Using events as a proxy.
That's interesting. I've never used the bind method, let alone inside an addEventListener method. If I were to use that approach, then how would I set the event parameters if that bind method is located inside a click event listener? Let's say that I needed to run a passive event, such as mousemove within a click event listener. Click events are non-passive, yet mousemove events are passive. Passive events can't be canceled (without some effort, anyway), yet click events are cancelable. What if the click event is set to bubble, and the mousemove event needs to propagate as capture? I don't know how that could be done. Without being able to set those custom parameters for events, and event listeners, nothing would work. Perhaps if I added the parameters into the method as arguments, that might be possible. The solution I have now works great. It's as simple as it could possibly be. It's efficient, and every element in the DOM is automatically enabled for use with touch interaction. To make that possible, I only had to write a single subroutine. I'd say it only took a couple of minutes to write up and I'm all done. It seems to be an ideal solution in every way. If there's a better way to go about it, then I'm open to ideas.
Let me tackle this in the morning. I must retire for my beauty sleep. I will say though, that `bind`, `call`, and `apply` are totally worth reading up on. Especially if you need a pass around a new `this` or in the case of that code example pass params where none were expected to be passed.
Jeremy Falcon
-
Let me tackle this in the morning. I must retire for my beauty sleep. I will say though, that `bind`, `call`, and `apply` are totally worth reading up on. Especially if you need a pass around a new `this` or in the case of that code example pass params where none were expected to be passed.
Jeremy Falcon
Yes, I will read up on them right now. I just finished writing all the comments in my event mapping script, and I'm glad to be done with all that. No more dev work for me today. Although I don't think it's possible to be so bored that you'd go through and read it all, I'll post a link to the script anyway. https://chromosphere.com/chromosphere/scripts/js/ui/events/ui_touch_functions_d_f.js[^]
-
Yes, I will read up on them right now. I just finished writing all the comments in my event mapping script, and I'm glad to be done with all that. No more dev work for me today. Although I don't think it's possible to be so bored that you'd go through and read it all, I'll post a link to the script anyway. https://chromosphere.com/chromosphere/scripts/js/ui/events/ui_touch_functions_d_f.js[^]
You're right, I'd have to be really bored. :laugh:
Jeremy Falcon
