bool DispatcherPlugin::onWindowAttached(FB::AttachedEvent *evt, FB::PluginWindow* window)
when this will be called i am starting one thread in the function to dram the frames with open Gl
FB::PluginWindowWin* pluginWindowWin = dynamic_cast<FB::PluginWindowWin*>(window);
by type casting window to FB::PluginWindowWin
How To Create FB::PluginWindow* window object so that i will start my thread by calling one function passing argument as FB::PluginWindow object
if you are using a modern version of Chrome then you can't get a plugin window -- you can only use it through nativemessaging which doesn't allow direct access to the browser window.
Your best bet would be to send the data to the page and draw in a canvas with javascript.
PluginWindow is legacy and only works on NPAPI and ActiveX; NPAPI is basically not supported by anything and ActiveX only works in IE these days.
Related
I am developing a Chrome extension on windows. It also has a native messaging host. The argument passed to the host named --parent-window is in my case always 0.
According to the Native Messaging Protocol it says
On Windows, the native messaging host is also passed a command line
argument with a handle to the calling chrome native window:
--parent-window=. This lets the native messaging host create native UI windows that are correctly focused.
I open my port for native messaging in the background JS. My understanding is that you cannot use this API in content.
This Chromium Bug appears to be my issue but it was closed as a won't fix.
So when or in what circumstances does Chrome send something useful with the --parent-window?
Further on May 7 the writer who I assume knows a bit about chromium says
Haven't tried it, but could you open your native messaging port in a
content script instead? Sounds like the --parent-window arg might be
useful in that case.
What does he mean and how do I do this?
Answering my own question. In short it does not work as you would expect if you are a windows developer. Possibly comment 2 helps from the "Wont Fix" issue on Chromium.
Comment 2 seems to explain when it might work.
If you are using Native Messaging
(https://developer.chrome.com/extensions/messaging#native-messaging),
it would seem like the --parent-window command line parameter would
provide a solution. Unfortunately, zero is passed for the parent
window if the native messaging connection is made from a background
page and (apparently) the HWND of a transient popup window is passed
if the native messaging connection is made from a browser action
popup. And I am not allowed to call chrome.runtime.connectNative()
from a content script. Therefore, in my extension at least,
--parent-window is not helpful.
My solution is immediately after
port = chrome.runtime.connectNative('myspecial.host.application');
I then use the following;
chrome.tabs.query({ active: true, currentWindow: true }, function (tab) {
console.log(tab[0].title);
port.postMessage({ MessageType: 'chromeTitle', Message: tab[0].title });
});
In your host if you add to this titel " - Google Chrome" then you can call FindWindowEX with the class "Chrome_WidgetWin_1" and the title to get the main handle of Google.
I have a simple setup for Desktop Capturing using html5 libraries.
This includes a simple webpage and a chrome-extension. I am using
Extension to get the sourceId
Using the sourceId I call navigator.mediaDevices.getUserMedia to get the MediaStream
This MediaStream is then fed into an instance of MediaRecorder for recording.
This setup works most of the times, but a few times I see that requestData() on MediaRecorder instance returns blob with empty data consistently. I am clueless as to what can cause a running setup to start misbehaving sometimes.
Some weird behaviour that I noticed in the bad state:
When I try to close/refresh the window it doesn't respond.
The MediaStreamTrack object in Step 2) above is 'live' but as soon as I go to Step 3) it becomes 'muted'.
There's no pattern to it, sometimes it even happens when I request for the MediaStreams the very first time(which rules out the possibility that there could be some dangling resources eating up the contexts)
Is there anything that I am doing wrong and am unaware of? Any help/pointers would be highly appreciated!
I am trying to write a chrome.app that is able to open and close chrome.app windows on both displays of a system that is configured with two monitors. When launched, the chrome application establishes a socket connection with a native application running on the same computer, I also open a hidden window via chrome.app.window.create to keep the chrome application up and running. The native application then reads a configuration file and then sends a series of ‘openBrowser’ commands to the chrome application via the socket.
When the chrome application receives an ‘openBrowser’ command, the chrome application makes a call to the chrome API method chrome.app.window.create, passing the create parameters AND a callback function. A code snippet is below:
NPMBrowserManager.prototype.openBrowser = function (browserId,htmlFile,browserBounds,hidden,grabFocus)
{
var browserManager = this;
var createParameters = {};
createParameters.bounds = browserBounds;
createParameters.hidden = hidden;
chrome.app.window.create(htmlFile,createParameters,function(appWindow)
{
// Check to see if I got a non-undefined appWindow.
if(appWindow !== null)
{
browserManager.browsers.push({"browserId":browserId,"window":appWindow});
console.info("NPMBrowserManager.openBrowser: Added browser, id =" + browserId + ", count =" + browserManager.browsers.length);
}
});
}
Unfortunately, the ‘appWindow’, parameter passed in the create callback is always undefined. I suspect it has something to do with the fact that the method openBrowser is itself being called by another method that processes commands received from the native application. However, the window opens exactly here and when I want to to, I just can’t seem to cache away any information about the new window that can be used later to close or move the window.
I want to be able to cache away the appWindow so that I can close or modify the created window later on in the workflow.
As a side note, I’ve noticed that appWindow is NOT undefined if I call the openBrowser method from within the callback that is associated with the chrome.app.runtime.onLaunched event. I suspect it has something to do with the current script context. I was not able to find any chrome.app documentation that goes into any detail about the chrome app architecture.
I would GREATLY appreciate it if anyone out there can explain to me how I can get the appWindow of the window that is created in the chrome.app.window.create method. By the way, I have also tried calling chrome.app.window.current to no avail… Very frustrating!!!
I’d also be interested in any documentation that might exist. I am aware of developer.chrome.com, but could not find much documentation other than reference documentation.
Thanks for the help!
Jim
I have a plugin which has a content stream pushed to it from an external service which I then draw into a PluginWindowlessWin.
I maintain a reference to the PluginWindowlessWin object so that I can call Invalidate() when new content arrives. However, in certain circumstances (e.g., plugin object removed from the page), the PluginWindowlessWin object is deleted without notifying my plugin. Thus, I end up calling Invalidate() on a bad pointer and crashing.
How can I continue to notify the browser of updates so it will continue to send refresh events - through Invalidate() calls or otherwise - without relying on objects that may be silently deleted?
When using a windowless plugin, you can't draw except when the browser requests it. Sounds like you have that part. You can ask the browser to request a draw by calling InvalidateWindow on the PluginWindowlessWin.
Once AttachedEvent is called on your plugin, PluginWindowlessWin will be available; you can even save the reference if you want. However, you need to release it when DetachedEvent is called.
I have created a safari plugin using NPAPI and I want to add a NSView in my plug-in.
When I try to get NPWindow throw function NPP_SetWindow(NPP instance, NPWindow* window), the second parameter is nil.
I think my plug-in is windowless, but i don't know how to create a windowed.
NPAPI on Mac does not support NSView as a windowing mode. There are two supported modes:
CoreAnimation (or InvalidatingCoreAnimation on Chrome and Firefox)
CoreGraphics
There used to be a QuickDraw mode, but that's deprecated.
For more information, see Stuart Morgan's excellent blog post on the subject.
It is possible to make a NSView render to a CoreGraphics context but you'd have to proxy all of the events and it is far from perfect.
EDIT: To further explain the answer to your question, the reason that the window parameter is NULL (it's a C api, not Obj C, so it's NULL, not nil... despite them being the same thing =]) is because in the Cocoa Event Model you get a CGContextRef as part of the draw event which is only valid during the context of that event.