In my GWT application, I have an iFrame embedding a PDF object. The PDF itself is retrieved from a servlet returning it with application/pdf as content type. In Chrome, my Popup, which is a GXT Window, shows in front of the embedded pdf just fine.
In IE however, the popup hides behind the embedded PDF, even if I make its z-index the max value for IE.
I have also tried to call the Window's focus method after loading it, and looked into alternatives for iFrame, but it led to nothing.
How do I make sure the popup Window will show in front of the PDF? What's causing the fact that the PDF brutally forces itself to the front in the current situation?
Internet Explorer has Windowed and Windowless elements - How the Z-index Attribute Works for HTML Elements. Embedded PDF is displayed using plug-in, so it cannot be behind plain DIV.
You should use the technique when an additional IFRAME is put in front of PDF plug-in, but behind the popup. This effectively will make the popup cover displayed PDF. It seems that GXT itself does not provide such a facility (or it does not work properly). You should probably implement your own popup window by extending the one being used. There you would override show() method to create and size additional IFRAME.
A good starting example is the implementation of PopupImplIE6 in GWT.
Related
I've been searching around (both on SO and around the web) to try to figure out how I can get the current height of the editor after the user has resized it. The TinyMCE 4.x docs don't show any kind of resizing event. When searching around I did come across the ResizeEditor event but that seems to apply only when objects within the editor are resized (which makes it seem like a poorly named event). Despite that, I tried to listen to the ResizeEditor event just to see and it does appear to fire whenever I resize the editor (though, I'm unsure if that's because the actual editor is resizing or because elements within the editor are getting resized, too. In any case, only the event object is passed in as an argument to the listener and I don't see any way to get the editor's current height (after the resize) from that event.
So, is there a way I can do this? To listen to the editor being resized and get its height?
thnx,
Christoph
You should be able to get the entire height of the editor (Menus, Toolbars, StatusBar, content area, etc) with code like this:
tinyMCE.activeEditor.getContainer().clientHeight
tinyMCE.activeEditor.getContainer().clientWidth
When you call tinyMCE.activeEditor.getContainer() you are getting the outermost div that contains all that makes up TinyMCE. From there it is just standard JavaScript to get the relevant dimensions of that element.
Here is an example: http://fiddle.tinymce.com/qigaab/18
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...
When I use Hflex property in a included page in a MVVM approach, it doesn't work.
The problem happens when I include some page inside another, and this page has components whose sizes are controlled by hflex property. I already tried to force the rendering of the components using invalidate on parent window load, or Clients.resize(component) when it is created inside the viewmodel class, but with no success. It just happens in this case: pages included in a MVVM scenario.
Here is a way to see the error: http://zkfiddle.org/sample/3bj6e5j/9-Hflex-not-working-with-include-pages-inside-div#source-1.To see the problem, click in the "Open" label, then a combobox is shown. You can see that the size of the combobox is only updated after resizing the browser window or after clicking in the dropdown button
If I explicitly resize the browser window, then the components are correctly sized.
Could anyone give any idea on how to solve it?
It's actually the javascript who does the fault,
Let me explain more. First you set the src of the include correct.
This is before the javascript is called, and your div don't really have a width at that moment.
So it takes that size, what you see.
Then the javascript is called and and actually he show's the div, but with the rendered with of the include at that moment.
How can you fix it : use zUtl.fireSized.
Here is your working fiddle.
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.
Suppose I have a html opened in a Browser. Now in that HTML file , I've a hyperlink and On clicking on that hyperlink, I want to open the Eclipse Help Window.
Same as Like
Eclipse>Welcome>What's New>Plug-in
Development Environment
I know the above is using an intro extension, but I am using a view to display the html. Now please show me a way to achieve the target.
The welcome screen and a lot of other places where hyperlinks appear in Eclipse UI aren't implemented using Browser widget, but rather using the FormText widget. The FormText widget supports limited markup, including hyperlink rendering. You control behavior of the hyperlink.
This article covers the use of FormText control:
http://www.eclipse.org/articles/Article-Forms/article.html
It may be possible to achieve what you are after using an actual Browser control, but if your scenario doesn't call for tricky formats, it will definitely be easier using FormText.