I am using QSystemTrayIcon for the first time, and it was trivial to implement. My code looks like this:
if(!connect(mTrayIcon, &QSystemTrayIcon::activated, this, &MiniStudio::onTrayActivated)) {
qWarning()<<"ERROR: could not connect QSystemTrayIcon";
}
mTrayIcon->setIcon(QIcon(":/icons/record.svg"));
mTrayIcon->setToolTip("Show MiniStudio controls");
mTrayIcon->setContextMenu(nullptr);
mTrayIcon->show();
As you probably understand from my code I don't want to display a context menu, I simply want a button in the tray that when clicked shows my application window.
The code sort of works, however, even if I specify a "nullptr" context menu, there still is a strange-looking box appearing under my tray icon whenever I click it, as if there is a context menu without any items in it (please see screenshot below).
So my questions are:
Am I doing something wrong?
How can I make the strange box go away?
Is this a bug, or maybe a feature of Qt on my platform?
PS: I am developing this code for Ubuntu 16.04 amd64 but I think the answer to this question should be relevant to any platform.
NOTE: I have also tried just omitting the setContextMenu() call instead of calling it with nullptr, and that didn't work either. The result was exactly the same.
Any input welcome,
Thank you!
Related
This is my first question in this community. I always search a lot when having problems and I always find an answer. But not in this one. Maybe I am not asking Google correctly.
Anyways this looks like a bug to me but I might get it wrong.
Using VS2012 (or 2013) I create the default Multiple documents MFC application. I do not write a single line of code. I compile and run. Then as a user I dock the properties window which by default is at the right to the output window as shown below .
Then I close the application and restart. The window is where it should be but with different width as shown below
If you dock the window to the right (in the view and not in another window) then there is no problem. The position and width are restored just fine. Also this only happens if the main window is maximized. The behaviour, if the main window is not, is as expected.
Do you think it is actually how Microsoft wanted to make this work or they missed that? Is there a workaround for this?
Again forgive me if this question has been asked before but really...
I couldn't find anything.
Appreciate any kind of help.
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();.
I am a little rusty with QT but I've had to use it for projects before.
I was wondering if I could make a pop-up window, a small window with it's height/width disabled so the user can't expand it. It should also lock the screen until they press a button on this window.
I could do all of this in a separate class, but I was wondering. Are there any built-in QT classes that have a little popup like this that I could just modify? I mean making a class just for an error message seems to me a little wasteful. I'm trying to keep the project small.
But if a class is required to be made in order to accomplish this, that is fine. The only problem is I have no clue how to lock the application windows so that you have to do something one window before you can go back to the main application.
I'm not asking for someone to type out all this code for me, just give me a link or something. I've looked for it but I couldn't find it. Cheers.
QMessageBox messageBox;
messageBox.critical(0,"Error","An error has occured !");
messageBox.setFixedSize(500,200);
The above code snippet will provide the required message box.
For a simple error message, I would suggest you look into the QMessageBox (the documentation contains little example that should show you how to easily achieve what you need), which is modal too. Using a QDialog for displaying a simple error message is possible too, but maybe too much for such a simple task.
I believe what you are looking for is something along the lines of QDialog. Dialogs can be modal or nonmodal. Modal dialogue "block" interaction with the calling window until the Dialog window has been handled.
You can either subclass QDialog or check to see if one of the default dialog classes will be enough for what you need.
As the context menu for the desktop and explorer windows is disabled, I wanted to make a little something to bring back some functionality. My idea was to just list out things in a context menu (copy, paste, new, open with, etc) whenever a user right-clicks one of these windows, and then just simulate the appropriate event in the actual menu (file->new, edit->copy, etc). It wouldn't look perfectly pretty, but it would hopefully allow for the use of right-clicking.
The problem is that I cannot seem to get the actual menu. I opened My Documents and tried going down the child list towards SysListView32, calling GetMenuItemCount each time. Most returned -1, and the only other return value than that was 0.
How am I supposed to get a handle to the (file, edit, view...) menu?
If this isn't possible, is there a way I could simulate the user clicking something on the normal context menu, even if it's disabled?
Also, is there a way of making this work for the desktop? You can get the same type of thing if you view it in the explorer window, so I figured there might be a way.
I'm running Windows XP and any help is appreciated.
As per David Heffernan's comment,
As for your question, you are on the wrong track.
GetMenuItemCount needs an HMENU but you've been feeding it HWND.
That won't work. It also won't work from a different process.
You could possibly write a program that use the shell COM APIs
to show a context menu for a shell item. But your basic problem
is the bone-headed group policy. You really need to get that fixed.
Tell the IT guy that takes the decision that I said he was a fool
and was stopping you doing any useful work. ;-)
This led me onto the path of using the correct alternative method to achieve my goal.
I always been interested on how we can accomplish this (hide/show the main menu using the alt key), and now some applications do this very often. One that really please me is the visual studio 2010 with this plugin:
http://visualstudiogallery.msdn.microsoft.com/bdbcffca-32a6-4034-8e89-c31b86ad4813?SRC=VSIDE
(firefox also do this, but i think that is in a different way)
Can anyone explain me how this can be achieved or if you known of any sample project that demonstrate this please tell me.
(what i can see in some replies here in stack is that we have to destroy the menu when is to hide and create it when is to show?! but this seems a bit bad solution...)
Thanks
The SetMenu function lets you add/remove the menu from the window. It does not destroy the menu.
Note that most applications which have the dynamic menu hide/show behavior are not really showing a menu. They're showing a custom control that looks like a menu.
You might also take a look at MFC support for auto hiding menus. I used this technique and it worked really well.
in CMainFrame::OnCreate I did
m_wndMenuBar.ShowWindow(SW_HIDE);
which actually works fine in our project
I stumbled across a related pit fall that will show a hidden main frame without your consent:
Whenever the focus for a child window in an MDI application changes (e.g. due to right clicking in it), the function CMDIChildWnd::OnMDIActivate will be called, which in turn shows the main menu (even if it was removed or destroyed previously) of the MDI application.
This works basically by adding the saved main manu from the underlying's CMDIChildWnd m_hMenuShared variable.
A quick&dirty hack to prevent this, is setting m_hMenuShared to NULL (it's protected in CMDIChildWnd so this needs a custom derived child class of CMDIChildWnd) for all child frames.