Tableau box plot issues - tableau-desktop

Not sure what is going on but boxplots are not always created for some of the drugs even though there is more than one date point displayed! Please see example. It works just fine for the middle drug but not for the top or bottom one.

Related

google sheets - how reset data labels that have been changed manually?

I'm trying to reset data labels that have been changed manually in google sheets bars chart, and I can't find it in any of the options of the "chart editor". I always get back the last numbers that was inserted manually, and not the original data from the table at question.
I tried to edit it in the "Setup" section, under the "Series" and pick the data range again, but couldn't find a way that works. maybe I'm missing something.
the only way I can think of, of course, is building the same graph again, but this is not smart when I have so many graphs to update
help pls
select the given single data label you want to reset, then right click it and choose "Format data point" > "Revert to default"
haven't found a way to revert multiple at the same time, might need to recreate the chart for that

how to know grouping values in pivot chart in Hyperion designer

I have a chart which has query,result and pivot. pivot has 3 part side labels,top labels and facts.
Some user selected few data in side label and make them a group, I dont know what those values are.
Can somebody let me know how to find grouping values in Hyperion Designer 8.5.
Thanks
Deepak
I'm going to guess that what you have is a pivot table where someone created a drilldown by right-clicking and selecting hide. And you want to know what they hid. Unfortunately, even if you're the one that hid the values, you can't get that information back without showing everything. This is just one of those Hyperion quirks: it assumes that people using Designer are individual developers who aren't going to be hiding and renaming things without remembering the original values. The only way to get it back is to do some detective work by showing everything and trying to replicate the table.

Changing the color of one label changes also the color of the other label in neo4j

This is a quite silly question but I can not find a way to make it work. Its related with the visualisation of my nodes and their labels in the neo4j server.
I have created a small number of nodes with two labels. The first one is called: PseudoNode and the second one: RealNode.
When I try to change the color of one label the visualisation rule applies also to the nodes which belong to the second label. Here is an image:
Why this happens?
I've run into this before. I think it's a bug in the web console. If you click on View stylesheet you can download the stylesheet and edit it locally and then upload it again by dragging it to the place where it says to drag it. Often I just clear out the stylesheet except for the first few about node/relationship.

Why are some location cells highlighted yellow

I created a table with columns for latitude and longitude. I manually entered a few values in them. Some of these cells are highlighted yellow even though the map can plot the location. Is there a reason why they are yellow?
It's a bug I'm working on fixing :-) Normally the yellow highlight in location columns means the value hasn't been geocoded, but for lat/long columns that obviously makes no sense. During updates the point loses track of the fact that it's a lat/long not in need of geocoding, so it's displayed in yellow. If you reload the page, or even leave the tab and come back, it should go back to normal.

Add gui components from bottom up instead of top down

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.

Resources