I wonder what is difference between CefBrowserView base and CefBrowserHost base application.
When I research others Cef base application by spyxx , So many application don't have CefBrowserHost Window. But They have CefBrowserView.
Which one is recommended, CefBrowserView or CefBrowserHost?
CefBrowserView base application is composed as follows.
CefWindow - CefBrowserView. ...
But CefBrowserHost base application is
Windows Native Window - CefBrowserHost (as child)..
CefBrowserHost uses a window that you give it.
CefBrowserView creates a window.
If you embed CEF in an existing window in your app, use CefBrowserHost.
If you create a new top level window, use CefBrowserView.
Related
Is there a way to detect when the user makes focus on the Project Explorer window in a RCP application? Is there an event I could use?
I researched and found that Project Explorer's id is org.eclipse.ui.navigator.ProjectExplorer but I still didn't find any solution to my problem.
You can use org.eclipse.ui.IPartListener to listen for changes to which part is active (and several other events).
You call the IPartService addPartListener method to set this up. You can get the part service in several ways depending on where you code is running. One of these is:
IPartService partService = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getPartService();
partService.addPartListener(listener);
Im trying to make a simple OSX-like dock application using Haxe 3.1.3. I cant seem to work out how to make the main application window transparent (no titlebars, borders etc), as well as ignoring mouse events except on the icons themselves. Ideally no taskbar item either, just a system tray item.
I believe Haxe Windows target uses SDL, and am pretty sure that SDL can support this kind of behaviour? Im not sure how Neko target is compiled, or handles this... Is there some flags I can set in the Haxe application.xml or something like that? Or is this just not possible with the Haxe Windows or Neko targets?
EDIT
I Discovered that the Waxe haxelib, which can be compiled with Neko, has a bunch of flags in the Window.hx file - https://github.com/nmehost/waxe/blob/cd9739e007ed10918166588faf2339d623b22fc4/wx/Window.hx
These include such options as FRAME_NO_TASKBAR and BORDER_DOUBLE, which both work when passed as arguments to the wx.Frame.create() function in the Simple.hx Waxe sample project.
It also includes the flag TRANSPARENT_WINDOW, but this appears to do nothing. No idea why the other flags are working, but the TRANSPARENT_WINDOW flag doesnt.
In Openfl (it's openfl which uses sdl and a xml project), you can remove the window border with this in your application.xml:
<window borderless="true"/>
But I don't know a way to move the window without borders.
relevant discussion:
http://www.openfl.org/forums/#!/general:moving-borderless-windows
When we register a window, we must create it before we register another window.
I read it on this page(Next Line after Figure:Windows)
http://zetcode.com/gui/winapi/firststeps/
and was wondering why ????
or is it only a good programming practise????
I am a newbie trying to learn win32 programming.Help will be greatly appreciated
When we register a window, we must create it before we register
another window.
This is just not true. The only important thing is that you cannot create a window of some class unless that class is already registered.
It is also common to do it otherwise in practice, and I cannot see any reason why it should be considered best practice. Many real programs register all window classes they might need in runtime during their initialization, and then arbitrarily just create the windows ad-hoc during application's lifetime.
That page says that "To create a window, we must first register it".
That doesn't mean you have to create it after it's been registered, only that you can't create it until it's registered.
You can register as many window classes as you like without having to create any of them.
We have an application built against MFC9 (VC2008).
The application is an SDI application, and shows a file open dialog during InitInstance(). Showing that dialog causes comdlg32.dll to be loaded. Some minutes later, the comdlg32.dll is unloaded automatically. After this, the next function depending on the DLL will crash.
How can this be avoided? What governs the automatic unloading/loading of the DLL?
Further info:
We don't see this problem on WinXP with the same application.
On Win7, this behavior only occurred since the beginning of this year - maybe some MFC update is related to this?
A small test application does not exhibit the problematic behavior - the comdlg32.dll is re-loaded when needed.
We’ve found a statement by Microsoft that it isn’t recommended to use modal dialogs in InitInstance() of MDI applications (http://support.microsoft.com/kb/173261) - we have an SDI application, though.
We don't directly use comdlg32.dll in any way, only indirectly through the MFC.
You have to call InitCommonControlsEx in your application on startup.
This will initialize the comdlg32.dll and also increase the reference count of the dll, so it won't get unloaded after closing a file-open/save dialog.
You don't say whether you customize your dialog or it is just a straight up file dialog. I think starting with Vista, the common file dialog was changed some. I know if you compare older MFC code with newer, you will see that the MFC code has been changed to take advantage of those changes. For instance, the IFileDialogEvents and IFileDialogControlEvents were implemented in MFC to support the way Vista and later versions of the OS customize file dialogs.
I don't know if I have an answer, but just for grins I would probably make sure I call AfxOleInitialize() sometime in InitInstance() before I tried to call the file dialog.
The other thing I would try for sure (since it works under XP) would be in the constructor of your CFileDialog would be to make sure to set bVistaStyle to FALSE. This ensures m_bVistaStyle is set to FALSE which it is set at when running under XP.
I am learning Cocoa and my understanding from reading the documentation is that when an application starts the following happens:
A shared application instance is created.
The main nib file is looked up from the applications property list so that the application knows which nib to load.
the run loop is started.
This is fine and makes sense for s single windowed application however I am confused by what xcode does when a document based application is created.
In this case there are two nib files; the first contains the application menu and the second contains the window which represents the NSDocument subclass. when I run the application a new document window is opened automatically.
Based on my understanding of how the application works outlined above I don't understand how my application knows to open the document window once the menu nib has been looked up from the property list. There is no code generated to do this as far as I can see (except for the windowNibName method but where is this called from?)
Can anyone tell me what xcode does differently so that the application knows that it is document based and therefore needs to open a document window?
Update:
What I am trying to understand is how Xcode knows how to do something different if my application is set up as a document based application rather than a single window application. As far as I am aware there is no setting to specify this and Xcode doesn't appear to generate any code to give this different behaviour.
From reading the documents over the last couple of days I think I know how this works but am not sure:
_NSApplication_has a delegate method applicationOpensUntitledFile which is called by the applications delegate.
NSDocumentController is set as the applications delegate by default and the default implementation looks for the presence of the CFBundledTypeInfo to determine if the document is document based or not and responds as is appropriate for the application (I.E. YES for document based application and NO for single window applications).
The majority of the time when a single window application is created the application delegate is replaced by a custom AppController anyway which usually wont contain a definition for the applicationOpenUntitledFile method as it is not appropriate for the type of application.
Hopefully any Cocoa experts can confirm if my understanding is correct or if I am barking up the wrong tree.
When you create a document-based application, you get a few things:
A subclass of NSDocument
A new xib file for this document, in addition to MainMenu.xib
A CFBundleDocumentTypes entry in Info.plist, which tells the app about your NSDocument subclass
When your app opens, the shared NSDocumentController will create a new untitled document using the CFBundleDocumentTypes information.
For more information, read The Document-Based Application Project Template and the rest of the document-based applications guide.
I assume your right. If you create a non based document application, add the document types informations in the -Info.plist and set the delegate of NSApplication in the main.m as following
int main(int argc, const char * argv[])
{
[[NSApplication sharedApplication] setDelegate:[NSDocumentController sharedDocumentController]];
[[NSBundle mainBundle] loadNibNamed:#"MainMenu" owner:NSApp topLevelObjects:nil];
[NSApp run];
}
The behaviour seems to be the same as the the default Document-Based Application template.
No, your assumption is not right, look at the implementation of GNUstep version, in the NSApplication's finishLaunching method:
NSDocumentController *sdc;
sdc = [NSDocumentController sharedDocumentController];
if ([[sdc documentClassNames] count] > 0)
{
didAutoreopen = [sdc _reopenAutosavedDocuments];
}
So it create a instance of NSDocumentController automatically.