I am updating the webkit embeded to my program however I come across a new problem about popup windows (MessageBox or File/Folder chooser dialogs).
For instance, if I invoke a javascript alert() clicking on a link, the MessageBox is rendered in front of the webkit window and looks like it is clickable, however when it is clicked the webkit window gain the focus and the MessageBox goes back of the webkit window. After that everything works as usual.
This problem does not happens if I invoke the alert() with keyboard.
So given the clues, what could be the solution, any tips ?
OS: Win7
In win/webview.cpp WM_CANCELMODE message invokes a function. Comment out, problem is solved.
Related
I'm writing a plugin for a big x64 application in C++. I want the plugin to open a dialog and show a web view of my site.
I'm been able to use WKWebView in macOS and it works well. On Windows I'm evaluating CEF https://bitbucket.org/chromiumembedded/cef (please let me know of any alternative, ideally I would like it to be Webkit-based).
Let's say the application framework that is hosting my plugin has already created a window for my plugin and has it's own message loop, so I can only receive events in a sort of WindowProc. I can also get the HWND of the window.
My implementation is inspired by cefsimple example, because cefclient is way too complicated. I've implemented the subprocess architecture with the external executable and everything works fine until it's rendering the client area of the window. Then I have problems with closing the window (it crashes) and resizing the window interactively (the window frame is resized but the web view in the client area does not resize).
I've tried all possible combinations, but I've run out of ideas. Namely:
If I use CefRunMessageLoop() the web view is rendered correctly but the main application does not process the UI events like close window button. Resize does not work.
If I call CefDoMessageLoopWork() myself once in a while (from WindowProc) the web view is rendered correctly and it processes the close button, but it crashes. Resize does not work.
If I use settings.multi_threaded_message_loop = true the web view is rendered correctly and I can close the window without crash. The destructor of the window calls CefShutdown(). But if I try to reopen the window it crashes! Are CefInitialize and CefShutdown allowed to be called only once?
And resizing still does not work. I don't understand why in the cefsimple example resizing works and in my window it does not work.
Besides message processing issues, probably I'm not closing the browser correctly, any advice? Why is so complicated? WKWebView is so straighforward!
There is no error message, no stack trace, no source code, no OS/CEF version - I doubt this question can be answered.
I can only tell you how to close browser cleanly: call CefShutdown at the right time (see cefclient/cefsimple examples) and do not keep any references to CEF objects when calling shutdown.
I'm seeing non-standard behavior (as compared to tools like Word and Visual Studio 2013) in my C++ Windows Forms application. We use Application::Run and then ShowDialog to show various modal dialogs. When one of the modal dialogs is up and I place another application window partially in front of the modal dialog, I can click on part of the modal dialog and it brings it back into the foreground as I expect.
However, if I instead click on part of the main window (shown with Application::Run) the modal dialog isn't brought to the foreground. This makes it hard to bring my application back so I can work on it. Ideas?
A simple MFC app created in VS2013 works as it should too. You can witness this with the About box which is shown with DoModal. I would have expected ShowDialog and DoModal to be equivalents. A simple C++/CLI or C# winforms application acts fine.
And this only happens in out application when our main window is maximized.
It turns out that is caused by our use of the Syncfusion UI libraries. They will be fixing the bug.
I am new to qt and I have an issue I cannot understand.
I have created my own QDialog and now I want to add it to an existing application.
In QT creator, everything works fine but when I add either my custom dialogue or even a
message box to the existing code, something odd happens.
The dialogue works just fine but when I hover over the main area of the dialogue
the icon changes to a Qt::BusyCursor the busy wait icon.
At first I assumed this must be a threading issue but then isn't .exec() suppose to block?
Also when I hover over the title bar or the message box / dialogue, it seems fine i.e it shows a Qt::ArrowCursor, in both cases the dialogue functionally works fine also.
I have tried to set the .setCursor() on both and it did not work still a busy icon.
can anyone give me some hints as to what I might look at to investigate this more.
Thanks a lot!!!
I can suggest you to use
QApplication::setOverrideCursor(QCursor(Qt::ArrowCursor));
and reset it with
QApplication::restoreOverrideCursor();.
My application has a dialog that asks the user via a QMessageBox whether he wants to discard all changes he made or wants to keep editing. I want this dialog to be modal to the whole application.
I read somewhere that this is the standard behavior for a QMessageBox, so I dont have to set it explicitly with something like:
mbox.setWindowModality(Qt::ApplicationModal);
I wonder why it behaves differently from other modal dialogs in the OS (Windows 7 in my case). On the one hand it functions like it should, i.e. all other input methods in the application are blocked until the user answeres the dialog. However, it doesn't 'blink'* if the user clicks any other window of the application. Is there any way to get Qt to behave like a native Windows dialog?
Thanks in advance!
*If you don't know what I mean with this 'blinking': Just open notepad on a Windows OS, type some text and try to close it. A dialog pops up that asks to save, discard or keep editing. Now click somewhere on the editor window -> the border and titlebar of the dialog flashes/blinks a few times.
The problem arises when the message box has no parent. This works fine for me:
QMessageBox box(this);
box.setStandardButtons(QMessageBox::Close);
box.exec();
But this does not:
QMessageBox box;
box.setStandardButtons(QMessageBox::Close);
box.exec();
This makes sense... the message box can't blink unless it knows that its parent was clicked on.
A simple solution that comes into my mind and if you want to deploy your application only on windows you should #include <windows.h> and use the MessageBoxA API.
Besides that this works great for me in Windows and ubuntu
if (QMessageBox::question(this,"Close?","Close this dialog?",QMessageBox::Yes,QMessageBox::No) == QMessageBox::Yes)
{
this->close();
}
I have this XP app (win32 C++) that I am just now testing under Windows7 (vista actually, but it does the same thing in windows 7).
I'm surprised that virtually the only issue I'm encountering is the following:
None of the scroll bars in a complex modelless dialog are functioning correctly. The main problem is the scroll thumb is not responding - just stays locked in position if you try and move it. Have had no issues going all the way back to win98, win2000, and winxp. Only in windows 7/Vista just now
But there is no commonality in the scrollbars in this dialog to explain it: One is in a plain richtext control created through a resource file. Another is in a richtext created through CreateWindow. And yet a third scrollbar is in a custom window class. None of them are working correctly (although you can make them scroll by right clicking and selected "Scroll Here".)
So I'm presuming maybe most encountered this a few years ago when porting to Window7/Vista for the first time, but I'm not finding anything in google now.
For modeless dialogs, you have to run IsDialogMessage in the main application GetMessage Loop, so messages for modeless dialogs are not subject to TranslateMessage and DispatchMessage. So I was doing that previously. However, Vista/Win7 doesn't like WM_MOUSEMOVE, and WM_LBUTTONDOWN and WM_LBUTTONUP to be bypassed like that for the dialog (i.e. they need to stay in the main App message loop). At least this was the problem in my case. I check for those message types now in the main message loop and that solved my problem. Can't explain it necessarily. Also couldn't explain why no one's encountered this previously (could be some idiosyncracy of my set up I guess). THanks for those who looked into this.