Question asked because I spent a while trying to solve this and the answer isn't easily Google-able:
If I've manually set the size of a chart how do I make it go back to how it was before I did so?
(Question left deliberately ambiguous as I have found two distinct answers).
You might want to do one of 2 things:
Go back to the previous fixed size.
Go back to the size being variable according the size of the containing element.
For #1, you can collect (and thus store for later resetting) the current size of the chart BEFORE you call the setSize() by calling chart.chartHeight or chart.chartWidth (where var chart = $('#chart-container').highcharts();), then just call setSize() again with the original values.
For #2, after you've called setSize() post-print, the chart will no-longer auto-size itself if the window changes. You can fix that by using the 'hack' detailed here: Is modifying chart.hasUserSize a bad idea after calling Chart.setSize()?
Which consists of setting chart.hasUserSize = false;
Related
I have a highstock graph with flags that initially is correctly set.
See on Figure 1:
The graph's data is loaded dynamically when the vertical scroll bar is changed. The only thing that changes is the series data with the function
function afterSetExtremes(e) {
var new_data_to_be_loaded = getNewDataToBeLoaded();
chart.series[0].setData(new_data_to_be_loaded);
}
The new series data is loaded correctly but the flags is incorreclty re-arranged, se the Figure 2:
So what's wrong on the setting, since the chart.series[0].setData just set the series not the previous flags added?
Almost a solution:
I found that setdata(data, false), setting the animation/redraw to false solve the problem of wrong flag positioning.
Take a look at that: http://jsfiddle.net/b6b63nwy/10/
But this did raise another problem: the series tooltip does not appear anymore. Is this a highstocks bug?
The answer:
http://forum.highcharts.com/highstock-usage/bug-series-tooltip-doesn-t-render-when-use-series-setdata-t37593/
=====================================================================
If you take a look at the Series.setData section in the official API, you will find that the second argument is a Boolean property which tells if redraw the chart. Instead of setData, try to use Series.update() function.
API Reference:
http://api.highcharts.com/highcharts/Series.setData
http://api.highcharts.com/highstock/Series.update
I have this tool tip that is created every so often. What is the appropriate actionscript etiquite?
A. To Create and remove the tooltip moveclip when needed?
or
B. To hide and show the tooltip movieclip when needed?
With these A and B, the answer is B, because creating and then removing an object a lot of times creates a lot of garbage in the memory, which eventually leads to garbage collector calls, that slow your SWF's performance. You can easily go with a single tooltip MC, just fill it with information that corresponds to the new mouse coordinates before you show it.
There is another question, not so straightforward as yours, about how to hide and show a movie clip, either via visible property or via addChild() and removeChild() (AS3 only). If you are using AS2 or AS1, use visible property to hide and show your tooltip.
There are three ways to hide something in Actionscript : Alpha, visible and remove child.
Apha: If you turn the alpha zero the renderer always comes to this displayObject and renders it at alpha zero. So the object is always rendered you just cannot see it.
Visible == false In this case the object still exists in your displaylist. So the renderer comes to the object. Sees it's property is false and leaves it but it still exists in the display list.
removeChild This means that you're removing the object from the display list. This means that the renderer never had to even check for it. Which makes it the fastest option.
addChild doesn't take that much computing power as visible check. I'm sure you can find benchmarks on this.
If you don't have a lot of objects on yours screen and the tooltip is there every second I'd go with visible is false. In all other cases go with the third option.
On a side note, I've found it always easier to manage them with a toolTipManager. A class that makes sure that you have one tooltip on the screen because usually users only use one tooltip. So that makes things easier for me. I just always create the necessary tooltips and add them to the displaylist when required and remove them. (Not recreate them) At the same time have only one tooltip on stage.
I have a highchart displaying multiple series, each contains 100+ data points
I have a UI containing a checkbox for each series that when clicked calls the series.hide() or series.show() to toggle the hide/show of each line
My problem is that the hide and show are extremely slow such that I cant check one checkbox whilst processing from a previous is taking place
Does anyone know how to handle this?
Thanks
Rather than calling hide() for each series, call setVisible(false, false);. This second parameter is the redraw parameter, and you can avoid causing a redraw (which is slow) for each series.
Then, after you're done changing visibilities, call chart.redraw() once.
http://api.highcharts.com/highcharts#Series.setVisible
as answered in:
Hiding _groups_ of series in Highcharts and jQuery: how to get acceptable performance?
highcharts draw each time a show or hide is called;
disabling and enabling the redraw function worked for me;
var _redraw = this.chart.redraw;
this.chart.redraw = function(){};
//do work
this.chart.redraw = _redraw;
this.chart.redraw();
How about adding visible: false for the series that are hidden before calling Highcharts.chart()?
Please see references: 1. Highcharts API and 2. Demo
In my case, above approach showed the best performance comparing to the followings:
series.hide()
setVisible(false, false)
setVisible(false, true) or setVisible(false, false); redraw();
I originally asked this question on the Highcharts forum a few days ago but received no answer so let me ask it here:
I want to have a chart where I can toggle the 'reversed' property of the Y-axis after the chart has been initialized and then see the chart redrawn. My first thought was to put something like the following code inside of an event handler (say in response to a button click), but it doesn't seem to do anything.
chart.yAxis[0].reversed = !chart.yAxis[0].reversed;
chart.redraw();
I don't think it's possible (see this forum post).
In particular, the last response on that post concludes with this:
I would suggest a workflow for your gui that updates a structure that keeps the options and then creates a new chart based on the options. The api we have has more of a focus on changing the data that is displayed than changing how the data is displayed.
So you might have to create two charts (one for each axis direction), only display one of them at a time, and toggle between them at runtime.
Update:
The accepted answer on this duplicate question suggests it is possible by doing this:
chart.yAxis[0].update({
reversed: !reversed
});
Is it possible to add gui components to blackberry screen beginning from the bottom instead of the top ?
Thanks
A quick response would be no but let me explain why and suggest afew work arounds;
Screens don't actually handle the laying out of fields onto themselves, to do this they delcare a delegate manager which can be any type of manager, vertical, horizontal etc. The problem is all managers begin painting themselves from the top left. For a manager to paint fields starting from the bottom it would have to know exaclty where the bottom is located and add components up rather than down which goes against all the low level code inside the manager class. You can read more on managers in the BlackBerry API documentation.
You could still achieve an effect similar to this though by tweaking how you add fields and playing with field styles. For example consider this code:
add(new LabelField("field 1"));
add(new LabelField("field 2"));
This would give us the results;
field 1
field 2
because field 1 is drawn then field 2 below it. However if we were always to insert fields at the begining of our manager e.g. position 0 like so:
insert(new LabelField("field 1", FIELD_BOTTOM), 0);
insert(new LabelField("field 2", FIELD_BOTTOM), 0);
We would get the results;
field 2
field 1
Which is the results you'd expect from a screen described in your question.
I'm not really sure how you'd get the fields to paint to the bottom of a screen though, you could try researching the "position relative bottom" styles but I'm honestly unsure.
You are probably using a VerticalFieldManager, and the documentation on that says:
A vertical field manager lays out
fields top to bottom in a single
column.
So if you
manager.add(field1);
manager.add(field2);
manager.add(field3);
The order of the fields on the screen will be just that.
But you could do something like this:
Vector v = new Vector();
v.add(field1);
v.add(field2);
v.add(field3);
for(int i=v.size()-1;i>=0;i--) {
manager.add((Field)v.elementAt(i));
}
Sort of. You can use the Manager#insert(Field, int) method and always insert at the zero index. If you do this with a VerticalFieldManager, it would simulate a bottom-up adding of Fields to the Manager.
Some of the answers so far are to use Manager.insert(Field, int), and keep inserting at position 0. This will work, but the running time of the insert is linear in the number of elements already added to the manager. Meaning this solution will have an overall quadratic running time. Not a big deal if you're adding under 10 fields, but if you're planning on adding more than that, the insert overhead will be substantial.
If you can do the inserts top to bottom, by reordering the fields as Muger's solution suggests, the running time will be much improved.
Finally, you can write your own BottomUpVerticalFieldManager that does the layout the way you want. When you write your own manager, you can layout the fields in whatever way pleases you. In this case, it would be bottom to top. Writing your own manager may seem daunting, but it will give you considerable freedom in the future when trying to solve layout issues.