I have an application where in the mainWindow(inherited from QMainWindow) creates a childWindow(also inherited from QMainWindow) and when run, both windows are launched with the childWindow masking the mainWindow.
In the mainWindow() constructor I have
setCentralWidget(this);
On Linux when the mainWindow->titleBar is clicked, the mainWindow is brought to the front whereas on Windows this doesn't seem to work.
To get a consistent behavior across platforms, I added a installEventFilter() and mouseEventHandler to account for left-button mouse events, but again none of methods I used within the mouse event handler helped me achieve the behavior I needed.
void mainWindow::mouseReleaseEvent(QMouseEvent* mevent)
{
if (Qt::LeftButton == mevent->button())
{
//this->raise();
//this->show();
//setCentralWidget(this);
}
}
How can I switch to the mainWindow() when I press(mouse-event) the Title bar?
Is there a reason why the behavior is different on Windows and Linux and how I do I make it consistent? I'm using the opensource versions of Qt-4.8.4 for Windows and Linux.
Have you tried using this function yet?
http://doc.qt.io/qt-4.8/qwidget.html#stackUnder
and I would use this in tandem with QFocusEvent
http://doc.qt.io/qt-4.8/qwidget.html#focusInEvent
http://doc.qt.io/qt-4.8/qfocusevent.html#details
Related
I have an Mfc application where I want to open a Qt modal window, while the Mfc application is still running behind.
To start a Qt application from an Mfc, I got the how to there. This page creates a Dll but my solution creates a static library instead.
As for creating a Qt modal window with main application running behind, it looks easy.
My problem is that it looks like that I cannot combined both solution.
The following code starts the Qt window, but I strongly suspect that I am blocking my main thread and main thread is not able to receive events.
void QtMfcFacade::startDevicesConfigurationWizard(HWND hWnd)
{
QWinWidget win( hWnd );
win.showCentered();
DevicesConfigurationWizard devicesConfigurationWizardUI(&win);
devicesConfigurationWizardUI.exec();
}
exec function is probably blocking main thread
Following solution should not block main thread, but the Qt windows appears only for few miliseconds and disappeared
void QtMfcFacade::startDevicesConfigurationWizard(HWND hWnd)
{
QWinWidget win( hWnd );
win.showCentered();
DevicesConfigurationWizard devicesConfigurationWizardUI(&win);
devicesConfigurationWizardUI.show();
}
So, the question is, is it possible to use show function instead of exec function?
(This works if I am creating a Dll and calling the Dll in a worker thread from my Mfc application, but I do prefer using static library)
I did not read enough the walkthough.
It is said : "Since we want the dialog to be modeless we cannot create the QWinWidget on the stack, since it would be deleted when it leaves the scope, and all its children, including the dialog, would be deleted as well. Instead we create QWinWidget on the heap, using operator new"
So, to make my window non modal while giving control back to main thread, I should do this :
void QtMfcFacade::startDevicesConfigurationWizard(HWND hWnd)
{
QWinWidget *win = new QWinWidget( hWnd );
win->showCentered();
DevicesConfigurationWizard devicesConfigurationWizardUI = new DevicesConfigurationWizard (win);
devicesConfigurationWizardUI->show();
}
Good day!
Have a problem: main window (MyApp for example) works in background (behind all other windows or in tray), not necessary to show it without need. After some period of time some reminding StayOnTop dialog appears (having parent = 0, to be not tied to main window) and asks for some user interactions. After dialog closes I’d like to keep an application window user currently working with active, and user continue do his job not switching to MyApp. However, instead of above behaviour, main MyApp window appears and user forces to switch back to his window (job) – inconvenient.
How to prevent MyApp main window appearing after closing the dialog? Need to install some event filter or access OS API? Problem exists in Mac, Windows, Linux.
You could try to re-implement the main window's showEvent and ignore that event, in case other windows are visible.
void main_window::showEvent( QShowEvent* e )
{
if( /*one or more of its children are visible */ )
{
// nothing to do
}
else
{
QMainWindow::showEvent( e );
}
}
Maybe just try invoking hide method after dialog call? Other possibility - try setting this:
http://doc.qt.io/qt-4.8/qwidget.html#windowFlags-prop to Qt::Popup.
I have a Qt app which, like Skype, is usually minimized to the tray. When the user clicks the tray icon, the app window is shown.
This works fine on Linux and WinXP. On Win7 however, the app window is shown but stays below the other windows - unless the currently active window is Qt Creator, or was my app (before I minimized it to tray). So it must have something to do with focus stealing prevention.
I know Skype is written in Qt, and they don't have that problem, so it must be fixable.
Here's my code:
void MainWindow::toggleVisible(QSystemTrayIcon::ActivationReason reason)
{
if (QSystemTrayIcon::Trigger == reason)
setVisible(!isVisible());
}
[Edit]
It turns out I had to call activateWindow. I changed my code to:
void MainWindow::toggleVisible(QSystemTrayIcon::ActivationReason reason)
{
if (QSystemTrayIcon::Trigger == reason)
{
if (isVisible())
{
hide();
}
else
{
show();
raise();
activateWindow();
}
}
}
It works on Win7 now.
I use the following code to make my application visible when clicked from tray;
setWindowState(windowState() & ~Qt::WindowMinimized | Qt::WindowActive);
this will handle the case its in minimized and you click the tray icon.
we have a C++ application that hosts a flex application in a MFC dialog. Everything works fine, all button pushes etc are passed directly on to flex with no problem at all, except the enter and escape keys, which immediately closes the dialog.
We can trap the enter key, by implementing PreTranslateMessage() or OnOK()
and impede the window closing behavior, but we still have the problem of passing these enter key pushes on to the hosted flex app further.
There is no "default" button on the form or anything like that, perhaps MFC is linking the enter key to the close button in the title bar behind the scenes or something.
Does anyone have any ideas how we can stop MFC from treating the enter key from being a special case.
Thanks a lot for any hints.
Edit: Here is PreTranslateMessage() that mmonem requested.
BOOL CFlexDialog::PreTranslateMessage(MSG* pMsg)
{
if ((pMsg->message == WM_KEYDOWN))
{
if (pMsg->wParam == VK_RETURN)
{
m_ctrlFlex->OnReturnKeyPressed();
return TRUE;
}
}
return __super::PreTranslateMessage(pMsg);
}
But it is not a suitable solution, calling a method in the flex app like that, as it makes life too difficult for the flex developer, it means he must write a special version implementing the return key behavior for every control.
We just want MFC to treat the return and escape keys like every other key.
Remove OnOK() and OnCancel(); PreTransateMessage is enough after considering VK_ESCAPE.
Why don't you use:
m_ctrlFlex->SendMessage(WM_KEYDOWN, VK_RETURN, 0)
instead of
m_ctrlFlex->OnReturnKeyPressed();
in your implementation of PreTranslateMessage ?
MFC command buttons can respond to events even if they do not have the focus.
Have you tried trapping the OnClicked event and OnOk to return nothing?
Example: trap OnClick...
void CMyDialog::OnClickedMyOK()
{
CDialog::OnOK();
}
Then do a no-op in the OnOk()
void CMyDialog::OnOK()
{
}
This should stop the enter key from being processed.
Another approach is "Windows Subclassing." That is, sending messages from one Window Procedure, that is a WindProc() to another WndProc(). This may provide a way without direct intervention. (This is not C++ subclassing.)
Here's a way with MFC Subclassing Edit: Provided a better link.
Search for "Windows / MFC Subclassing" if more info needed.
The flex control/window has a WndProc and your window certainly has a WndProc, Windows Subclassing should work.
New Edit: Here is perhaps a better link for subclassing an ActiveX control.
ActiveX Controls: Subclassing a Windows Control
Subclassing Windows Forms Controls - More .Net-centric.
Notice: In MFC you should see these functions.
CWnd::SubclassDlgItem
CWnd::SubclassWindow
CDialog inherits from CWnd so you will see those two functions as "dialog" functions as well. They are key to making this work. If the flash window is a true window, use SubclassWindow. If it's a control use SubclassDlgItem.
And finally, if nothing else works. A product/library that will hopefully make it easy. EasyHook looks like a product here. EasyHook at CodeProject, you can get all the source code.
If you are having issues handling tabs & enter keys I would recommend you look into using a window instead of a dialog. The dialog adds modal ( if you are using modal ), tabbing & default button handling. If you don't need/want those features, or if they are getting in your way, then don't use a dialog.
If I understand what you are doing, then you want flex to handle tabbing, enter key, and all sorts of other messages. Get the dialog code out of the way. If you still want modal style, then you may have to handle the enable/disabling of parent windows - thats all that windows does when you open a modal dialog.
My application consists of a WebView widget. A mouse click on the widget is not handled by the mousePressEvent() of my application, but by the WebView widget. So, I installed an event filter to receive the events. Now, I get notified of all events, except the mouseReleaseEvent for the right click (Everything works fine for left clicks and mousePressEvent for the right click is also getting registered). I guess it has got something to do with context events getting generated by right clicks (a pop-up menu gets generated). But since I am using a filter, the event should first be sent to me. The following is the code for the event filter
in Jambi, but I hope I can modify an answer given in Qt for Jambi.
public boolean eventFilter(QObject o,QEvent event)
{
if (event.type()==QEvent.Type.MouseButtonPress) // One can call the mousePressEvent() functions from here,which can do this work but speed
{
if (((QMouseEvent)event).button()==Qt.MouseButton.LeftButton)
{
mousebuttontype=1;
clickedorpressed=1;
}
else
if (((QMouseEvent)event).button()==Qt.MouseButton.RightButton)
{
mousebuttontype=2;
System.out.println("right");
}
t1=QTime.currentTime();
t1.start();
}
else
if (event.type()==QEvent.Type.MouseButtonRelease)
{
if (t1.elapsed()>900)
{
switch(mousebuttontype)
{
case 1: browser.back();
break;
case 2: browser.forward();
break;
}
}System.out.println("choda");
}
return false;
}
MY BASIC AIM IS GETTING THE TIME INTERVAL FOR WHICH THE RIGHT CLICK WAS PRESSED. ANY WORKAROUND ?
Some digging around certainly seems to suggest that there may be no right-mouse release event being generated if that is the trigger for a context menu on your particular system. These are conveyed as a QContextMenuEvent.
This Qt Labs post hints about this too.
A work around may be tricky if it is system dependent. Have you tried overriding event() in the QApplication class to see if the event comes through there? Some events don't necessarily get to the children but everything goes through QApplication::event().
Another option for you is, subclass Qwebview and override mouseReleaseEvent event
I've found a fix for this that I dont think will be system dependent.
My particular case was using mouseReleaseEvent in order to catch the events, and use them myself. I didn't get these events.
On all child widgets of the widget that I want to handle the event, I added to the class definition:
protected:
void mouseReleaseEvent(QMouseEvent *event) {event->ignore();}
This overrides the default implementation for context menu's, and sends the mouseReleaseEvent back up the parent chain like it would for other mousebuttons.
http://doc.qt.io/qt-5/qevent.html#ignore
This shows that it will probably propagate to the parent widget. As the link indicates, this fixed it for me at Qt 5.9, but I think it should work for virtually all version.
(I am aware this question is literally 7 years old, but it doesn't contain the fix that I think would be the best fix, and shows up as result 2 on google(qt not getting mouse release event on rightclick). So I think it deserves an up to date answer.)
Without going in to broader implementation explanations, the core problem I needed to solve related to this issue was that I needed to know if a context menu swallowed the right-click so I could ensure some custom state was handled properly. The simplest workaround I was able to find was to implement contextMenuEvent, which gets called after mousePressEvent, to detect if the event was accepted (a context menu was opened somewhere in my QGraphicsScene/Items). Here is a minimal example in Python to demonstrate how the event state might be used:
def contextMenuEvent(self, event):
event.setAccepted(False)
super(MyGraphicsView, self).contextMenuEvent(event)
self.__context_menu_used = event.isAccepted()
Note you can also skip running the the base class contextMenuEvent entirely to block the scene/items from opening a context menu. This is handy if you want to do 3D-DCC-like alt-RMB-zooming without accidentally opening a context menu, e.g.:
def contextMenuEvent(self, event):
# Block context menus if alt is held down
if event.modifiers() & QtCore.Qt.AltModifier:
return
event.setAccepted(False)
super(MyGraphicsView, self).contextMenuEvent(event)
self.__context_menu_used = event.isAccepted()