I searched through the docs but could not find a post discussing this.
I'm currently working on a project which's both available for mobile and pc browsers. Since the screen on iPhone is very small, I'd like to disable highcharts interaction on it (the interaction would fail me even scroll down the page).
I would like to ask whether there's any parameter like "hasInteraction:false".
Thanks for any kind of tips!
update:
I tried this code from Ricardo Lohmann and it's working to disable the mouse tracking:
plotOptions: {
series: {
enableMouseTracking: false
}
}
But on mobile device it's still blocking my finger scrolling down. I searched on Google and found a post: http://blog.rafael.jp/post/2958719820/div-mouseenabled-false but still not working (to allow the chart not blocking my finger scroll)
I'm looking for a solution to this as well.
More precisely, I'd like to enable page scrolling even when finger starts dragging on the chart. I'd still like that a touch on a data point opens up a tooltip.
You might be interested in this commit from v3.0.4 "Added new option, tooltip.followTouchMove ...". I still have to try that. I tried that on iPhone simulator and it works:
Somewhere in your HTML page:
<script type="text/javascript" src="//code.highcharts.com/3.0.1/highcharts.js"></script>
Later on, when you create the chart in your JavaScript code:
$('#chartdiv').highcharts({
chart : {
type : 'line', // e.g. for a line chart
zoomType: null, // this is already the default, it's just to stress what's said in commit comments and make code "speak"
},
tooltip: {
followPointer: false, // this is already the default, it's just to stress what's said in commit comments and make code "speak"
followTouchMove: false, // this is already the default, it's just to stress what's said in commit comments and make code "speak"
},
// other options...
});
plotOptions: {
series: {
enableMouseTracking: false
}
}
demo
plotOptions: {
<your type of chart, for example "spline">: {
enableMouseTracking: false
}
},
May fix your problem
Related
When you open the chart in full screen mode it works as expected: chart is being displayed on the whole screen, but when you exit full screen the original chart stretches to a much bigger height. You can test it here:
https://jsfiddle.net/9b6m438y/
responsive: {
rules: [{
condition: {
maxWidth: 500
},
chartOptions: {
legend: {
layout: 'horizontal',
align: 'center',
verticalAlign: 'bottom'
}
}
}]
}
How to reproduce: Open context menu in upper right corner of chart, select "View in full screen", then exit the full screen mode and pay attention to the height of the original chart.
How to avoid this?
It is a controversial thing if it is a bug or not because different browsers different works in the current full-screen module implementation - you can see the whole discussion here: https://github.com/highcharts/highcharts/issues/13222
As a workaround (suggested under the above link) you can set the container height in the CSS.
Demo: https://jsfiddle.net/9b6m438y/
#container {
height: 400px;
}
If you have your own opinion about it - feel free to take part in the discussion on the GitHub issue ticket.
I had the same problem in higharts#8.2.2.
Reading the comment below the question, I decided to upgrade highcharts to 9.1.0.
the problem is completely solved in this version.
because of the major update (8 to 9) my code confronted with few problems that can easily be handled. Hope it works for others too.
If you see this fiddle you will notice that in order to spawn the Tooltip the mouse has to leave and reenter the div foo after the Tooltip has been initialized.
I thought that maybe I could manually trigger the Tooltip using tooltip("open"). Unfortunately, the mouse tracking doesn't work when I do that. See this fiddle.
Does anyone have an idea how I could get the Tooltip to open with mouse tracking enabled without having to leave and reenter the div? In case you are wondering why I need to do this, I am working with WebGL in a canvas element that takes up the entire screen.
I am using the track: true option and I faced to the same problem in a different context. I am working with richfaces and have some ajax calls which rerender parts of a page.
After each rerender, i needed to rebuild tooltips present in the rerendered part so i decided to attach an event handler to the document and to rebuild thoses tooltips on mouseenter, and then manually open them by calling $(...).tooltip('open')... tooltips are displayed correctly but the mouse tracking doesn't work anymore.
So instead of using $(...).tooltip('open'), i trigger a mouseenter event and work with css class to init only once :
jQuery(document).on('mouseenter', '.tt', function() {
jQuery(this).tooltip({
content: function() { ... },
items: ".tt, .ttped",
track: true
})
.toggleClass('tt ttped')
.trigger('mouseenter');
});
I edited your jsFiddle, which rebuild tooltip each time you enter on #foo and another one which init tooltip only once (static content)
I'm using jQuery UI Tabs for showing several graphs, using Flot. This works perfectly fine in every browser but IE8. It looks like IE8 doesn't support several Flot graphs next to each other.
Anyone experienced this before?
I'm rendering the graphs when the specific tab is selected, see code below.
$( "#tabs" ).tabs({
select: function(event, ui) {
var tab = ui.index+1;
if(tab == 1)
rendergraph1();
else if(tab == 2)
rendergraph2();
else if(tab == 3)
rendergraph3();
}
});
The renderGraph1/2 functions just render the graphs with some options, like this:
function rendergraph1()
{
$.plot($("#graph1"), data, {
.....
Again, the code is working fine in Firefox. This is why I won't bother you with the full rendergraph code :)
Anyone experienced this before?
I assume your other tabs are hidden until after you draw the plot. There are several issues with hidden divs under older versions of IE.
Try showing the tab/div before you call plot, rather than after. If you have other stuff to do, or are using some kind of transition, you can always hide the tab/div immediately afterwards and then show it later; it just needs to be visible and attached to the DOM when you call plot.
This is more of a proof of concept for myself, to fool around and learn what I can and can't do with jQuery, and I have had partial success.
I created an accordion that contains two spans, which serve as name and description, as well as a button that is independently click-able (ie, it does not open or close the accordion.)
Taking that concept, I decided to try and make the name and description editable by turning the name and description spans into text inputs / text areas, which worked fairly well.
The problem however is that when I take the same technique I used on the button and use it on the input and textarea, clicking it does not allow you to move the cursor to different positions. There does not seem to be a way for me to get around this behavior.
I tried event.preventDefault(), which does not work at all.
I tried event.stopPropagation(), which gives the partially working behavior.
and I tried return false, which worked the same way as stopPropagation.
I was wondering if anyone could provide any insight on this issue.
I included the jQuery javascript below, but for a much more concise example I will provide a jsfiddle link here (http://jsfiddle.net/Rakshasas/xFhN3/) which gives you a much more clear example of what I am doing. Note that when you click the accordion to expand it, the spans are hidden and inputs are shown. Clicking the inputs does not close the accordion, but it also does not allow you to position the cursor.
Also, if you do attempt to change the text in the inputs, closing the accordion does indeed update the spans which is the intended result. This is why I am saying my concept partially works.
Thank you.
$(function() {
$(".accordion").accordion({
header: 'h3',
collapsible: true,
active: false,
change: function(event, ui) {
var id = ui.newHeader.find('input:last').val();
$("#status").text(id);
ui.newHeader.find('div.headerContainer input.name').val(ui.newHeader.find('div.headerContainer span.name').text());
ui.newHeader.find('div.headerContainer textarea.desc').val(ui.newHeader.find('div.headerContainer span.desc').text());
ui.oldHeader.find('div.headerContainer span.name').text(ui.oldHeader.find('div.headerContainer input.name').val());
ui.oldHeader.find('div.headerContainer span.desc').text(ui.oldHeader.find('div.headerContainer textarea.desc').val());
ui.newHeader.find('div.headerContainer span').hide();
ui.newHeader.find('div.headerContainer input, div.headerContainer textarea').show();
ui.oldHeader.find('div.headerContainer span').show();
ui.oldHeader.find('div.headerContainer input, div.headerContainer textarea').hide();
}
});
$('input.name, textarea.desc').click(function(event){
event.stopPropagation();
});
$(".delButton").button({
icons: {primary: 'ui-icon-trash'},
text: false
}).click(function(event) {
//Display user friendly text
return false;
});
});
If someone is facing this issue, this is a little trick that worked for me.
PROBLEM: nested jquery accordions with input/textareas elements, cannot gain focus with normal click in Firefox (if you use jquery accordions with NO nested accordions on it, everything works fine). Confirmed by above users.
The sympton relates only to normal click (left click). If you try optional click (right click), the element (input/textarea) WILL gain focus. Weird.
SOLUTION: Just declare this in your document ready function
$(function() {
//some code ...
$("input, textarea").click( function(){
$("input, textarea").blur();
$(this).focus();
});
//more code ...
});
Confirmed (by me) working on IExplorer, Firefox and Chrome.
Seems to work fine in Chrome. This might be browser dependent.
"Clicking the inputs does not close the accordion, but it also does not allow you to position the cursor"
Also fine in Chrome.
I'm using the jquery ui dialog for a modal popup dialog. It's working great in Firefox/Chrome but terrible in ie6.
Problem:
When I show the dialog in ie6, the browser window grows and automatically scrolls down to the bottom. The height increase and automatic scroll-down is equal to the height of the jquery dialog.
I can scroll up and then use the dialog as normal, but the behavior where it grows the window and drops is maddeningly unacceptable.
Here is how I'm launching the window:
<div id="dialogWindow"></div>
...
$(document).ready(function() {
var $dialog = $("#dialogWindow").dialog({
autoOpen: false,
modal: true,
minWidth: 560,
width: 560,
resizable: "true",
position: "top"
});
$('.addButton').click(function(e) {
e.preventDefault();
$('#dialogWindow').load('http://myurl');
$dialog.dialog('open');
});
});
I am already using the bgiframe plugin for jquery which is key for ie6 overlay issues. But this seems unrelated to that. Has anyone seen this before and found a work around?
I've seen this behavior before and it is usually caused by the overlay. When you use the {modal: true} option an overlay is created and rendered with bgiframe support if the plug-in is loaded.
First off, try turning {modal: false} and see if you aren't getting page blow-out then we know it's the overlay.
there are a few things to check if that is the culprit;
check that the styles for the overlay are loading correctly, you'll need to include the jquery-ui dialog.css
try experimenting with position: and float: styles
try moving your dialog markup just above the < / body> tag, allowing the modal overlay to escape correctly.
I had a similar problem at one point.
$('.addButton').click(function(e) {
e.preventDefault();
$('#dialogWindow').load('http://myurl');
var y = window.pageYOffset;
var x = window.pageXOffset
$dialog.dialog('open');
window.scrollTo(x, y); // horizontal and vertical scroll targets
});
What the above should do is grab your current scroll coordinates and saves them. Once the dialog opens you then scroll back to the prior position in memory. Should be near instant and unseen by the user.