When trying to edit colors in Google Data Studio, the color picker dialog box is always cut off. As if it's running off the edges of the screen.
Scrolling up/down doesn't make the picker move. Refreshing the page doesn't do anything. And you can't just click and drag it to move it.
This shows what I'm talking about.
I've reported it on Google's Issue Tracker, but I can't seem to post anything on the Data Studio community forums. Which is why I'm here. I'll also post about it on Reddit to see if anyone else is running into this glitch.
I was able to reproduce the problem, so it is not "just you".
However, to reproduce I had to reduce the size of the browser window (with the window maximized it does not happen). This is clearly a responsive web design problem and I guess you're using a small screen.
Although it is indeed a bug, it may not be a priority for Google to solve. You're probably one of the few users that designs dashboards with small screens. So you may want to find a bigger screen.
Related
I created a PeerComponent, that is a port in Codename One of the Horizon Camera SDKs. At the moment, it simply shows a live-preview of the camera.
I tried to add a Label over the PeerComponent: the Label is on top only in Android. On iOS, the Label is on bottom (that means invisible).
I've done a lot of trials to get a correct z-ording on iOS, without success.
My question is which tips, suggestions or checks can I do to make z-ordering working properly on iOS also. Thanks.
Normally it should "just work", there is no special treatment. I think horizon paints in an area we rely on and doesn't paint when we expect it to. Looking at their sample code I see that they reference top and bottom elements which might allow working around this.
So I'm not really sure how to explain this but I will try my best.
I created a jsfiddle: https://jsfiddle.net/xghar755/2/
As you quickly hover over each text, you can see that the background color changes. This is just a simple div with a css hover property. Here is the kicker though, go to your address bar and type in any letter and you get a drop down of items, like so.
Now, quickly hover your mouse over the items in the dropdown. And then go back to the jsfiddle and hover your mouse over its items. You can tell that the chrome versions` background color feels more responsive. It's rarely noticable, but I can tell. Why is that?
Is this because Chrome's a Native application that doesn't rely on CSS or the DOM? If so, does this mean that native apps are generally more responsive in user interface applications? Thanks ~
Chrome is a software program running on your device. jsfiddle is, in part, a program that communicates with Chrome via the internet. Each transaction between the browser and jsfiddle takes tens of milliseconds, perhaps hundreds, and there can be a multitude of back and forth operations to serve one page and its in-betweens. In addition, Chrome is written in a language that runs in your machines native processing language while communication with jsfiddle is all interpreted by Chrome first, not to mention some processing is done on the jsfiddle server before being sent to your browser.
tl,dr; Programs running on your computer can do things a lot faster if they don't have to communicate with other programs over the internet.
I had my app working just fine a few days ago and then I noticed the first problem. I had to tap twice in order to make a button go to the next screen. Also happened to the checkBoxes. Had to tap twice to make them change.
But now it got serious. Since yesterday when I tap on a TextField the app freezes and then crashes.
The only significant changes I remember I did were 2: I uploaded an image for the App Icon and I edited the TitleArea UIID. I removed the TOP and BOTTOM margins. It also affected some of my label and button UIID, because now they don't show on the device
When I run the simulator, the doble tap also occurs, but the TextFields work fine and the Button and Label UIID look the way they should.
Any ideas why this happens?
I am right now working with old versions to try to determine the reason, but no luck so far. Thanks
Use a solid color rather than a gradient with the same colors. Gradients are slow and problematic across platforms so you are paying a lot for something that you aren't even using.
We'll need a better test case to reproduce crashing, I think that what you initially saw when you submitted the issue was a regression in the text input that we since resolved in the build servers.
A few of my users are experiencing a strange bug. I have a simple WPF window that contains a few textblocks and buttons. After a short time using my application successfully the users that experience the problem report that the window's content becomes empty and only the border of the window is visible.
After remoting onto their machines I have confirmed that it looks like the content of the window is frozen. When the window first opens it appears like its see through and displays whatever is behind it. If I move the window around the same frozen image of what was behind the window when it opened stays there. If I bring something in front of the Windows (such as a browser) the "frozen image" in the contents will change to a frozen image of whatever was in front of it. I have discovered that the buttons are still active and clickable in the window, so it's not completely frozen it just seems not to be drawing the content properly.
The issue only seems to affect a small percentage of my users and I cannot recreate this issue on any of my test machines. Any ideas about what is happening would be greatly appreciated.
If you have a user that's willing to experiment to find a solution, have them Disable Hardware Acceleration in WPF. If this fixes the issue, then it's most likely a graphics driver problem.
I have a Silverlight control that tries to have the same background as the underlaying div, but I'm facing color difference problems in IE7/8:
That doesn't seems to be a problem for Firefox.
Does anyone has a tip how to solve this problem? I try to avoid using the windowless mode in Silverlight and alpha transparency as 1st) it's slower and 2nd) shows a bounding select box when you click in the control in Firefox.
Fortunately I managed to solve the problem. Seems that it's a gamma correction problem. The PNG file allows you to set gamma correction information and Silverlight and IE seems to handle it differently.
This page explains the problem and saved the day. This tool as also necessary to remove the gamma information from the PNG.
Hopefully this information will be useful for someone.