views:

5071

answers:

2
+1  A: 

I am thinking the shadow that you see is related to the Windows theme that you are using. I am using the Windows Classic Theme here and i don't see any shadows :)

Anyways, what if you connect the textChanged() SIGNAL of the QLineEdit into a custom action that restores the focus of the Main Window? Something like:

void PopupTest::handleClick()
{
   QFrame* popup1 = new QFrame(this, Qt::Tool | Qt::Window | Qt::FramelessWindowHint);
   popup1->resize(150,100);
   QLineEdit *tmpE = new QLineEdit( popup1 );
   connect( tmpE, SIGNAL( returnPressed() ), popup1, SLOT( hide() ) );
   connect( tmpE, SIGNAL( textChanged(const QString&)), this, SLOT( setActive() ) );
   tmpE->setGeometry(10,10, 130, 30);
   tmpE->setFocus();
   popup1->show();
}

void MainWindow::setActive()
{
   this->activateWindow();
}

You will have to create a slot called setActive() and you should also put the QLineEdit into your class header so that from the setActive() function you can do something like:

tmpE->setFocus();

to restore the focus on the QLineEdit as well.

nmuntz
The problem with this is the text box then looses focus, so the user can't enter more text without re-activating the popup again.. I think you are right about the shadow being part of the windows theme.
+1  A: 

I worked out a solution to the question I posted earlier.

First, a popup widget can be created by deriving from QWidget with flags Qt::Window | Qt::FramelessWindowHint. I actually hacked qwidget_win.cpp to ensure my window has the same style and extended style as the Popup control provided by WPF (0x96000000 and 0x08000088 respectively), as determined using Spy++, however I don't think that should matter.

Setting the window style doesn't solve the Window activation problem. The key to doing this to intercept the windows messages that inform the main window that it's non-client area should be updated (WM_NCACTIVATE message). This can be done by providing a custom implementation of QApplication::winEventFilter(MSG* msg, long * result).

Unfortunately, simply eating inactivate WM_ NCACTIVATE messages isn't enough, because it seems to prevent WM_ ACTIVATE and other messages that otherwise get generated from being sent to the popup window. To solve this, I have a proof of concept working where I generate the required windows messages in winEventFilter after having caught an appropriate WM_NCACTIVATE message.

From here, there are some details to work through to make sure it's robust (intercept WM_ACTIVATEAPP comes to mind), and then wrap it up into something nice and reusable.

All this is windows specific of course, be interesting to see if there are issues under Linux.

All this is a bit of a pain. Hope I didn't miss something obvious...

Matt Howlett