Row header locking issue for a Dashboard designing for Chrome and IE.
Dashboard is designed for Chrome but users are interested to see in IE also. Everything looks fine but the right border of the Metrics are moving to right side in IE. Locking the row header fixes the alignment but row height is changing. I'm unable to put the row height that is suitable for both IE and Chrome.
Please check the Attached word.[enter link description here][1]
This is a common problem with web pages design, of course with a tool like MicroStrategy you have more limitation that designing your webpage with HTML and CSS (on the other hand MicroStrategy does much more that just creating web pages).
Possible solutions:
- Go for a design without elements that can cause problems, i.e. avoid those borders
- Create a custom CSS plugin to fix the problem in IE
For the CSS customization you can start from here.
Related
This is perhaps a more general question as I'm looking for ideas on how to approach a problem working with PDFView/PDFKit. I have a small sample application that allows you to display a page, select a range of text and then associate a comment with that text. Once the comment is saved the comment is displayed on the PDFView page in the margin via an overridden draw() function for PDFView.
Problem is that with very small margins the comments can be very squished. I've been looking for a straight-forward solution and would very much appreciate ideas on how to address it.
The obvious (ie, easy) solution is to change the actual "page size" in the PDFView and have wider margins, but of course PDFKit has no support for that (I don't think). Another thought was to go to a custom PDFView library but the only ones I found when I last looked were iOS (not Cocoa) based.
Last idea was to instead of drawing directly on the page have some sort of pop-up window (like a sticky-note) contain the note but then it would need to be moved dynamically with the scrolling of the page. And of course one other was to recreate the PDF dynamically for viewing and make all the pages larger... but I've not dug into how much of a performance hit / effort that would entail.
Maybe there's a simple/obvious solution that I've missed?
I created a simple sample app in gitHub which shows the basic functionality for people to play with if that's of help. https://github.com/jcnolan/PDFMarginTextView
I know I can get the whole body of a document with context.document.body.getOoxml() and the current selection with context.document.getSelection(), however I can't find a way to establish what is currently on screen and what is not...
Is there a method in the Word Office JS api to retrieve only the content currently displayed on the screen?
There isn't a solution for this. The way some of the JavaScript libraries in web pages are able figure out this problem is through the view port.
Example here: https://www.customd.com/articles/13/checking-if-an-element-is-visible-on-screen-using-jquery
See another helpful SO answer here: Get the browser viewport dimensions with JavaScript
Now - Word however uses HTML as a way of formatting - and not as a way of directly displaying things. So even if you could run the same library on the HTML - it wouldn't have the same context.
The best you could do is to get the height of the visible space (which should be the same height as your add-in frame) and attempt to do some mapping. You would have some weird edge cases though, like if the font-size is different, or you have a page-break in the view etc...
I also have this issue. I am using Ubuntu and just completed the Hello world tutorial. I wrote some more text and I am unable to scroll. I can see where the words keep going but nothing I have tried lets it scroll. I have not made any HTML/CSS edits. I have only added more text to the <p> tag.
There is some default CSS applied for chrome packaged apps. Putting the following in your CSS should re-enable scrolling:
html {
overflow-y:scroll;
}
Someone is putting together a cool guide which might have some more tips. See https://gist.github.com/maicki/7622137#scrolling
Chrome apps have a default stylesheet applied to them, to help the web "page" be more of an "app" by default.
For Chrome Apps on Mobile, we also include this (well, a nearly identical) default stylesheet.
So that is the reason for that behavior. Scrolling is absolutely useful in very many contexts, and is absolutely supported in any DOM element by adding overflow-y: auto;.
It was simply deemed to be the wrong default for packaged apps which live inside a dedicated window of set bounds and where we encourage not having full page content overflow (very much the opposite of the web). Most apps usually surround a main scrolling element with fixed navigational elements (but not always).
FYI, there is also another open issue for Chrome Apps on Mobile to replicate yet more of the Chrome for Desktop default styles.
I am currently trying to replicate the functionality of the Sticky application (fourth example under "samples") in my GWT application, specifically NoteView (see the class NoteView in SurfaceView.java in my personal repo or download Google App Engine's SDK, where you'll find it in appengine-java-sdk-1.5.1/demos/sticky).
However, as hard as I try, I just cannot find the place where Google put in the gripper bars on the bottom right hand corner of every note, and where their code allowed the user to resize the note. grepping for "resize" and "resizable" in their sticky dir was not fruitful, and the CSS "resize" functionality was not used either. Also, GWT Textareas are not automatically resizable in the way that these notes in GWT are, and I don't know how to enable this or set it up.
I'm sorry but it really just is a textarea, and your browser does the rest (most browsers make textareas resizable nowadays).
Using Firebug or a similar developer tool, can you tell which differences are there between the Sticky sample and what your code does?
I figured it out -- it was old crud css left over from a gxt implementation. As soon as I removed the css file, the textarea automatically had gripper bars.
When a <select> tag is used in a HTML page, is there a way to style the text size in
the scroll wheel that shows on the iPhone?
There is this alternative.
http://cubiq.org/spinning-wheel-on-webkit-for-iphone-ipod-touch
It uses javascript to put the elements on the page.. I used it for a web/ iphone app and it worked really well. There would be custom styling if you wanted to change the default text sizes and you could also load in custom images..
I don't believe you can style the wheel that shows up on the iPhone directly. In fact, even modifying it in browsers has weird support. For example, http://jsbin.com/obake3 doesn't work at all in Chrome, only modifies the actual drop down in Safari and stretches the graphic in a very ugly way in Firefox.
We investigated and couldn't find any reliable way of altering the display so we looked into different libraries. We're having good luck with the Mobiscroll library for jQuery. It is a more up to date project than the cubiq project referred to in other responses.
The control is themable. You can easily change the appearance of if in CSS. It also comes with pre-defined, nice looking color schemes.
We chose it because it works across devices allowing for a more consistent look & feel.
Taken from Sitepoint Ref
The select renders slightly differently depending on the browser and operating system in use, and is well known as a troublesome HTML element to style with CSS (because the display is inherited from the operating system, rather than provided by the browser)