how can I get the handle for the browser window what hosts a plugin window? I would like to inquire its size so I can properly resize my plugin window.
Hope that makes sense,
Christian
You should never be resizing your plugin HWND; the browser does that. If you're resizing it without the browser's intervention you're breaking the contract and will likely end up in conflict with future changes of the browser which is assuming that you're allowing it to size you according to the DOM, not according to the root document window.
Just FYI.
For Windows user the solution is to call GetAncestor:
FB::PluginWindowWin* w = (FB::PluginWindowWin*)(fb_win);
HWND hWndBrowser = GetAncestor( w->getHWND(), GA_ROOTOWNER );
A thread on google groups explains a bit more:
https://groups.google.com/forum/?fromgroups=#!topic/firebreath-dev/4aMXWI94RzY
Christian
Related
I want to set a homepage to a specific URL, and have it fullscreen, without requiring any help from the user.
Is this possible? I know i can set the default homepage to this specific URL, so thats easy. But automatically full screen?
You can't, but here are some alternatives. They might or might not work depending on your ultimate goal.
If you are launching the browser, start it with the --start-maximized flag.
If you control the web page at that URL, you can use the fullscreen API.
I am looking for an equivalent of AdjustWindowRect function that allows to get widths/heights of window caption and borders.
Do we have this functionality in GTK 3 at all? Seems like not.
I've looked through all gtk_window_xxx, gtk_widget_xxx and gdk_window_xxx* functions...
Update:
In principle I am able to determine window-chrome/decoration dimensions as a delta of gdk_window_get_frame_extents() and gtk_widget_get_allocation() / gdk_window_get_origin() but
it works only after window appeared on the screen. I need it before that - to calculate initial window position.
it is really a hack.
It's up to Window Manager to decide.
You can request it by sending a message _NET_REQUEST_FRAME_EXTENTS as explained in the specification of EWMH (Extended Window Manager Hints):
_NET_REQUEST_FRAME_EXTENTS
window = window for which to set _NET_FRAME_EXTENTS
message_type = _NET_REQUEST_FRAME_EXTENTS
A Client whose window has not yet been mapped can request of the
Window Manager an estimate of the frame extents it will be given upon
mapping. To retrieve such an estimate, the Client MUST send a
_NET_REQUEST_FRAME_EXTENTS message to the root window. The Window Manager MUST respond by estimating the prospective frame extents and
setting the window's _NET_FRAME_EXTENTS property accordingly. The
Client MUST handle the resulting _NET_FRAME_EXTENTS PropertyNotify
event. So that the Window Manager has a good basis for estimation, the
Client MUST set any window properties it intends to set before sending
this message. The Client MUST be able to cope with imperfect
estimates.
Rationale: A client cannot calculate the dimensions of its window's
frame before the window is mapped, but some toolkits need this
information. Asking the window manager for an estimate of the extents
is a workable solution. The estimate may depend on the current theme,
font sizes or other window properties. The client can track changes to
the frame's dimensions by listening for _NET_FRAME_EXTENTS
PropertyNotify events.
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472648576
So, in two words, you send a _NET_REQUEST_FRAME_EXTENTS msg to WM (to the root window - it's gdk_get_default_root_window() in case of gdk), then wait for the reply (_NET_FRAME_EXTENTS PropertyNotify), and get the desired data from your window's _NET_FRAME_EXTENTS property.
Unfortunately situation with GTK is even worse than just problem of getting decorations.
The first:
gtk_window_move(window, x, y) sets border frame position of the window.
And gtk_window_resize(window, w, h) sets client dimensions of the window.
And there is absolutely no way in GTK API to set border frame size programmatically and explicitly. And so there is no way to set window frame position/size of decorated windows.
On Windows and MacOS, using their APIs, that is easy to do, and reliably. But on GTK they only have this:
gtk_window_move(): Begs the window manager to move window to the
given position. Window managers are free to ignore this; most window
managers ignore requests for initial window positions (instead using a
user-defined placement algorithm) and honor requests after the window
has already been shown.
You are correct that the functionality is not there. GTK is agnostic of the decorations that the window manager places on the window; for all that your application is aware of, there may be giant decorations, or there may be none.
What you can do, is use gtk_window_set_titlebar() to tell the window manager to let you use your own decorations; then you have full control over their size.
For what it's worth, AdjustWindowRect() and AdjustWindowRectEx() assume that you are working purely with the default Windows window decorations and, optionally, one row of default Windows menus. It's not suitable for custom window decoration or multiple rows of menus; in these cases, you use the WM_NCCALCSIZE message, which has to be sent to a specific window. DefWindowProc() does all the work for you if you just want the defaults. (Example for multi-row menus. And if you aren't using default Windows menus, then just tell Windows that you aren't; you'll be responsible for positioning everything yourself in this case. GtkMenuBar works on this principle too.)
Since you want the default decorations, though, you merely luck out in that Windows provides an AdjustWindowRect() function in the first place, and that it will work for the default window decoration because it's provided by Windows.
(It is entirely possible for a program to lie in its WM_NCCALCSIZE, but it'd be lying to Windows as well, and Windows does not like a liar. I imagine the same would hold for _NET_REQUEST_FRAME_EXTENTS, though I'm not sure how bad the damage would be in that case.)
So the fact that X11 doesn't have this guarantee that all window managers must follow means you're out of luck in that department. (In fact, I don't think Wayland has such a thing either; does it?) Hell, nothing prevents a window manager from not having window decorations at all. Or you can even not run a window manager in the first place!
In theory, you could compare the size and position of a window (either the geometry of the GdkWindow or the allocation of the GtkWindow) with and without CSD to see what space you lost. But I don't know if this is reliable. A GTK+ developer will need to confirm.
I have a website which is only rendered in Webkit enabled browser (Google Chrome, Safari). I am using Google Chrome since I am on Windows 7.
I am using Watir-WebDriver to automate the same.
Issue: When I click on a button on the browser window, is launches another window and post click content is rendered in the new browser window. I need a way to be able to Identify this new browser window, in-order to be able to proceed with my testing. I have been reading on various forums, but not getting any certain answer/solution.
Q: Is there an alternative to watir::ie.attach for watir-webdriver since attach is not supported on Watir-Webdriver
Sample code:
require "rubygems"
require "watir-webdriver"
require "selenium-webdriver"
b = Watir::Browser.new(:chrome)
website = "http://xyz.com"
#a new browser is launched and the website is opened
b.goto(website)
#this opens a new browser window
b.link(:xpath,"/html/body/div/ul/li/a").click
#there is a button called "MAP" on the new browser window
b.link(:id,"btn_MAP")
#this gives an error, unknown link
"window" method is the alternative for ie.attach. Webdriver can handle the window opened by itself with window method.
b.link(:href,/server\/getPage/).click
b.window(:url,/server\/getPage/i).use do
b.link(:id,"btn_MAP").click
end
you can handle popped up windows in the window method block. If you want to keep handling popped up window, use it without block, like window(:url,/foobar/).use
see also:
http://groups.google.com/group/watir-general/browse_thread/thread/232df221602d4cfb
#Yutaka: Thanks a lot for all your help it lead me to use something like the following and it worked!
b.link(:xpath,"/html/body/div/ul/li/a").click
c = b.window(:url,"http:\/\/server\/getPage\/67\/1354")
c.use
b.link(:id,"btn_MAP").click
have you tried making the website the default homepage for the browser?
that might prevent you from having to do an attach.
I want to call a popup window where i lock the window size to maximum size possible and don't allow size/ aspect ratio to be changed subsequently. This saves overhead of doing relative sizing and positioning multiple times.
When I do use jscript, i find code that works for IE but not chrome and vice versa (haven't checked on any other browser). Is it possible to have single common solution for all browsers
function newPopup(url) { popupWindow= window.open( url,'popUpWindow','height=700,width=1200,left=1,top=1,resizable=no,scrollbars=no,toolbar=no,menubar=no,location=no,directories=no,status=yes')
}
popup open
The script line is getting truncated from message...
No, because other browsers are designed to be user-friendly, which, for example, means that the user can resize a window whenever he wants to.
I am facing trouble enabling "High Resolution" mode in WM6
Professional. I am using a HTMLView.dll to embed an HTMLControl in our
application. By default the "HTML" Shown is not in "High Resolution"
Mode - The App is appearing all zoomed up and as how it is displayed
in lesser resolution Emulators/devices.(QVGA)
I have already referred to a few links suggested from folks. Most of
the links point to https://learn.microsoft.com/en-us/previous-versions/aa454895(v=msdn.10)
which offers a solution to turn off the Emulation layer in WM6 by
adding a line to the resource file.
HI_RES_AWARE CEUX {1} // To turn off the emulation layer
This is because of an accepted bug - discussed at -
https://social.msdn.microsoft.com/Forums/en-US/4d3c837d-16f4-4ae4-acc2-96bb8d573111/htmlview-too-large-on-wm6-vga
Doing the HI_RES_AWARE didn't help as the view on the HTMLControl was
the same. I want to imitate the same functionality that IE Mobile does
when I select Menu->View->High Resolution, which does show the HTML
the way it's supposed to be shown (Smaller - so that more HTML View
screen is achieved).
I have already tried to modify the DTM_ZOOMLEVEL which I normally set
when an HTML is written to the HTMLControl - But even the least zoom
setting doesn't zoom out sufficiently. The view on the IE mobile's high
resolution mode is much better.
I have also tried getting the width and height of the screen by using
the GetDeviceCaps() method, but this only returns me the screen size,
which will at the max help me to modify my created window's size.
The issue that I am facing is how to enable the high resolution mode
automatically on my html pages (here I am not creating the UI for
mobile device, it's only the html page).
Any pointers?
I've researched a lot and from the resources and my experience. You're stuck with a QVGA resolution for the HTML Control on WM 6.1 - it's like hardcoded from Microsoft.
No point in dragging your quest forward. End it and re-design your UI to look good on QVGA resolution.