Got it working:
https://github.com/lpapp/examples/blob/main/qt-native-event-filter/main.cpp
Thanks.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
I actually also tried this to no avail. Is it a Windows plugin or native
event filter bug that I cannot intercept alt+key presses? Or am I doing
something wrong?
#include
#include
#include
#include
#ifdef Q_OS_WIN
#include
#endif
class MyMSGEventFilter : public QAbstractNativeEventFilter
Hi again,
I wrote this simple test bed, but it does not seem to work. It seems that
the windows plugin does not let me process the alt key after all? I can
process the space fine, but not the alt. Am I doing something wrong or the
windows plugin does not allow the api user to intercept the native
Thanks - it has helped!
I need to return true when I want Qt to stop processing the events further.
But I would not like to do so for everything unconditionally. Do you know
how I can extend this example code to handle e.g. alt+space to return true
for it? I assume this would mean writing Windows
On 2022-08-02 00:07, Laszlo Papp wrote:
#include
#include
#include
class MyMSGEventFilter : public QAbstractNativeEventFilter
{
public:
bool nativeEventFilter(const QByteArray &eventType,
[[maybe_unused]] void *message, long *) override
{
std::cout << eventType.toStdString
Hi again,
I wrote this example program, but it does not seem to work. The filter is
never hit on Windows even though I copied the qwindow.dll to the platforms
directory of my build tree. Do you know this would not work on Windows? The
filter is hit on Mac and Linux. Thanks.
Kind regards,
László
It would be better if the Qt application using Qt would not need to write
platform specific code, like intercepting WM_APPCOMMAND or
using DefWindowProc.
So, I wonder if we can either:
1. Change the default behaviour to pass the event to the application and if
it is not handled by the application
On Sat, Jul 30, 2022 at 5:38 PM Tor Arne Vestbø
wrote:
> I guess that depends on what your goal is. The default implementation
> calls showSystemMenu(), so it doesn’t seem to pass through the app AFAICT.
>
I was wondering if the default implementation ought to give a chance to the
app to handle
On 30 Jul 2022, at 18:29, Laszlo Papp mailto:lp...@kde.org>>
wrote:
Thanks.
Should the event first be sent to the application and only if not handled,
passed to Windows?
I guess that depends on what your goal is. The default implementation calls
showSystemMenu(), so it doesn’t seem to pass
Thanks.
Should the event first be sent to the application and only if not handled,
passed to Windows?
On Sat, Jul 30, 2022 at 5:15 PM Tor Arne Vestbø
wrote:
> Actually, you might be able to filter out the event via
>
> https://doc.qt.io/qt-6/qcoreapplication.html#installNativeEventFilter
>
> An
Actually, you might be able to filter out the event via
https://doc.qt.io/qt-6/qcoreapplication.html#installNativeEventFilter
And pass it on manually to windows via DefWindowProc
Tor Arne
On 30 Jul 2022, at 18:12, Tor Arne Vestbø
mailto:tor.arne.ves...@qt.io>> wrote:
Hi,
I don’t think there’
Hi,
I don’t think there’s any way to customize that behavior today, apart from
maintaining a customized version of the Windows platform plugin.
You could perhaps have some luck intercepting WM_APPCOMMAND before it reaches
the Qt message proc?
Tor Arne
On 30 Jul 2022, at 14:12, Laszlo Papp mai
Hi,
What is the recommended way to customise the behaviour of built-in plugins,
like a windows plugin , QWindowsKeyMapper in particular?
To be specific, if we wanted to pass this alt+space to the application
rather than Qt forwarding it to Windows, the operating system? Like a
potential break her
13 matches
Mail list logo
