I have a QMainWindow which instantiate a QWidget subclass. I want to fill my subclass with remote data, so I want to prevent the QWidget::show() slot, ignore it and make the request, then really show the subclass widget.
I've reimplemented showEvent(QShowEvent *) and made it ignore the event, a qDebug() show me it worked and is ignored, but still showing the widget.
What did I miss ?
Thank you for your help.
Subclass:
void Groups_Materials::showEvent(QShowEvent *event)
{
event->ignore();
qDebug() << "Event accepted: " << event->isAccepted(); // Return: false
}
How it is called:
this->m_groupsMaterialsWidget = new Groups_Materials(this->m_parent);
this->m_groupsMaterialsWidget->setWindowModality(Qt::ApplicationModal);
this->m_groupsMaterialsWidget->setAttribute(Qt::WA_DeleteOnClose);
this->m_groupsMaterialsWidget->show();
What is written in the console when calling these methods:
Event accepted: false
Add « event->spontaneous() », if it returns « true », you just can't
The spontaneous show events of windows are delivered afterwards.
Just call « hide() » on your QWidget subclass so it won't be shown unless you call « show() » yourself.
I got an anwser alone... I was using the "Qt::Sheet" flag, which seems to make it fail.
I'm on Mac, maybe it would work on Win/Linux: Qt-Forum
Related
I've implemented undo/redo the standard way (NSUndoManager) but can't figure out how I disable undo/redos when my app is in a specific state.
Users draw things in my app and when what they've drawn is uploading I disable the UI and of course don't want the user to be able to undo/redo.
I use a NSView's Undo Manager so I guess one way could be to just make that view resign first responder. Is there another way?
If the view is the first responder, you can implement the validateMenuItem: protocol to disable or enable the menu items according to your current state.
- (BOOL)validateMenuItem:(NSMenuItem *)menuItem {
SEL action = menuItem.action;
if (action == #selector(undo:) ||
action == #selector(redo:)) {
return !uploadingImage;
}
return YES;
}
You can finalize undo and redo with
- (void) removeAllActions;
or remove actions for a specific target with
- (void) removeAllActionsWithTarget: (id) target;
If you simply want to disable any actions for a time, leaving the undo stack unchanged, simply disable the Undo/Redo menu items using NSMenuValidationProtocol's
- (BOOL)validateMenuItem:(NSMenuItem *)menuItem;
The best approach I can think of is making the view's -undoManager method return nil during uploads, which will remove it from the responder chain and cause undo/redo options to be disabled for that view.
(I haven't tested this, but I'm 99% sure that the menus will ask your view for the undo manager whenever it validates the menu options.)
I had a similar situation where I wanted to conditionally disable certain undo/redo operations when the app is in a specific state (while still allowing undo/redo for other operations).
The method of implementing - (BOOL)validateMenuItem:(NSMenuItem *)item on a view doesn't work for me (I have a document-based app on 10.12). Per the docs at https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/MenuList/Articles/EnablingMenuItems.html:
If there is an object in the responder chain that implements the item’s action, NSMenu then checks to see if that object implements the validateMenuItem: or validateUserInterfaceItem: method. If it does not, then the menu item is enabled. If it does, then the enabled status of the menu item is determined by the return value of the method.
The view would have to add an undo method the does the right thing as well.
When I probed the responder chain, I found that my NSWindow was the object that responded to undo: (though it's not part of the documented interface), so my current plan is to use a custom NSWindow subclass with the imeplementation of validateMenuItem, along the lines of:
#import "Window.h"
#implementation SBXWindow
- (instancetype)initWithContentRect:(NSRect)contentRect styleMask:(NSWindowStyleMask)style backing:(NSBackingStoreType)bufferingType defer:(BOOL)flag screen:(NSScreen *)screen
{
self = [super initWithContentRect:contentRect styleMask:style backing:bufferingType defer:flag screen:screen];
return self;
}
- (BOOL)validateMenuItem:(NSMenuItem *)item
{
// Call super imeplementation as it appears to update the menu item title (and potentially other stuff)
BOOL result = [super validateMenuItem:item];
if (result == NO) {
return NO;
}
if (item.action == #selector(undo:) || item.action == #selector(redo:)) {
// Add custom logic here
}
return result;
}
#end
However there are warnings that the undo: redo: methods aren't implemented. These can be eliminated by creating a category on NSWindow, such as:
#interface NSWindow (SBXUndoable)
- (void)undo:(id)sender;
- (void)redo:(id)sender;
#end
Not sure if there are any issues with doing that (I didn't notice any), but it does eliminate the warnings. I've since changed the class to a Swift class, which didn't have any warnings to deal with.
The documentation is your friend. The disableUndoRegistration method of NSUndoManager has "disable" in its name. It's up to your app's controllers to decide when it's appropriate to disable and re-enable undo registration.
I have a CEdit box where a user can enter relevant information. As soon as he\she starts writing in the box, I need a notification so that I can call doSomething() to perform some other task. Does Windows provide a callback, and if so, how do I use it?
With MFC there's no callback as such, rather you do this by implementing a handler for the appropriate event. You need to handle one of two events: WM_CHAR or EN_CHANGE
Handle the dialog's EN_CHANGE for example duplicating in realtime the entered text elsewhere on the dialog. You need to firstly add an entry in the dialog's message map, and secondly override the appropriate handler:
BEGIN_MESSAGE_MAP(CstackmfcDlg, CDialog)
ON_EN_CHANGE(IDC_EDIT1, &CstackmfcDlg::OnEnChangeEdit1)
END_MESSAGE_MAP()
void CstackmfcDlg::OnEnChangeEdit1()
{
CString text;
m_edit.GetWindowText(text);
m_label.SetWindowText(text); // update a label control to match typed text
}
Or, handle the editbox class's WM_CHAR for example preventing input of certain characters, e.g. ignore anything other than a digit for numerical entry. Derive a class from CEdit, handle the WM_CHAR event of that class (not the dialog) and make your edit control an instance of that class.
BEGIN_MESSAGE_MAP(CCtrlEdit, CEdit)
ON_WM_CHAR()
END_MESSAGE_MAP()
void CCtrlEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)
{
// Do nothing if not numeric chars entered, otherwise pass to base CEdit class
if ((nChar >= '0' && nChar <= '9') || VK_BACK == nChar)
CEdit::OnChar(nChar, nRepCnt, nFlags);
}
Note that you can use the VS IDE to put in stubs for the handler overrides by using the Properties bar with the mouse selection in the message map block.
EDIT: Added example code, and corrected explanation of WM_CHAR which I had wrong.
If you double click on the edit box in the resource editor it automatically creates the OnEnChanged event for you.
The following assumes that you have an MFC dialog application.
The class wizard can be started with a right-click:
Double-click the Control ID (has an icon with a small green plus) of the new edit control to add the corresponding member variable to the class.
The class and event wizards will update the class definition and add a CEdit member:
afx_msg void OnEnChangeEdit1(); // Added by event wizard
CEdit m_edit1; // member added by class wizard
The class wizard will update the function:
void CMFCApplication5Dlg::DoDataExchange(CDataExchange* pDX)
{
CDialogEx::DoDataExchange(pDX);
DDX_Control(pDX, IDC_EDIT1, m_edit1); // new variable added with class wizard
}
Double-clicking the control or right-clicking and selecting the add event wizard will update the message map and create the function declaration and definition:
BEGIN_MESSAGE_MAP(CMFCApplication5Dlg, CDialogEx)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_EN_CHANGE(IDC_EDIT1, &CMFCApplication5Dlg::OnEnChangeEdit1) // new event handler added with wizard
END_MESSAGE_MAP()
Finally the code may be updated to interact with the edit control:
void CMFCApplication5Dlg::OnEnChangeEdit1()
{
// TODO: Add your control notification handler code here
CString text;
m_edit1.GetWindowText(text);
//m_edit1.SetWindowText(text);
}
I have made a custom NSView and have implemented the keyDown: method. However, when I press keys the method is never called. Do I have to register to receive those events? fyi, I am making a document based application and can handle this code anywhere (doesn't have to be in this view). What is the best place to do this in a document based application such that the event will occur throughout the entire application?
You need to override -acceptsFirstResponder to return YES.
In Swift:
class MDView: NSView {
override var acceptsFirstResponder: Bool { return true }
}
I know you can assign a custom view that overrides mouseDown: method. I'm looking for a standard solution since I don't want to re-implement drawing.
Try doing this wherever you need it in your code:
if ([NSEvent modifierFlags] & NSAlternateKeyMask)
{
//whatever you need to do
}
I am trying to make a Qt application which has an auto hiding menu bar. How can i do that?
That's an interesting task ! Ok, lets see... I'd suggest you putting a code that keeps track of mouse cursor movement in QMainWindow::centralWidget(). You need to call QWidget::setMouseTracking(true) first to be able to keep track of your mouse movement (they are turned off by default). The code can look like this:
QMainWindow *mainWindow = new QMainWindow;
MyWidget * myWidget = new MyWidget(mainWindow);
myWidget->setMouseTracking(true);
mainWindow->setCentralWidget(myWidget);
And then in your widget QWidget::mouseMove() event you need to detect whether you are in the correct area. The code can look like this:
void MyWidget::mouseMoveEvent(QMouseEvent * event) {
bool menuVisible = inCorrectArea(event->pos());
mainWindow->menuBar()->setVisible(menuVisible);
...
}
There are several ways to get access to "mainWindow" in your MyWidget. One of them is to store a pointer in MyWidget private variable when you pass MainWindow in its MyWidget constructor. You can also issue a signal from your MyWidget and handle it in MainWindow.
Hope this helps.