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...
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
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.
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.
We are trying to write a training manual application for the iPhone. On the top half of the screen is a diagram of a car engine, on the bottom half is some text. At the user repeatedly hits a "next" button, we highlight different parts of the engine, and in concert we highlight different parts of the descriptive text below.
We basically want "living text" in the text half, with the illustration following along on top to where the reader is in the text. What we'd like from the text is 1. user can scroll it using their thumb so possibly a UIScrollView 2. the software can explicitly drive a scroll to any part of the text (when they hit the "next" button). 3. the words in the text are interspersed with hotlinks e.g. "this is the camshaft... this is the piston..." and the user should be able to click on any of the keywords like camshaft, piston, and have the diagram highlight that. (The problem is not highlighting the diagram, its capturing the click). The text would have 300~400 buttons/links/keywords and about 600 words of text.
Since this is fairly similar to using a web browser, we tried using Apple's version of webkit using a UIWebView and handleOpenURL to register a service back to the app itself. But Webkit for internal links a popup comes up asking permission to access that link. Every single the user wants to go to a link (in our case just an internal event that we'd intercept so that we can highlight e.g. the camshaft). Tried to intercept the event from the HTML view, but that didn't work.
It seems like the best we can do is to abandon scrolling text, and make the text part more like flash cards or a power point presentation, breaking the text into custom UIViewCells with buttons inside a UIScrollView. However, this would impose an annoying constraint on the author that they would have to write everything to fit in the UIViewCells, sort of chunky.
Any ideas would be appreciated.
This is definitely something you can use a UIWebView for. Don't use handleOpenURL, rather, set your viewController as the webview's delegate, and override -webView:shouldStartLoadWithRequest:navigationType:. When this gets called, check the request, and pull out your link data from there.
It would probably be easier to implement that completely in JavaScript in the document you load in a UIWebView. You would have to use JavaScript (i.e. [UIWebView stringbyevaluatingjavascriptfromstring:]) anyway to achieve things like scrolling to a certain position.