Mit Qt::WaitCursor alle Eingaben blocke

[darkshine]

Guten Morgen Forum,

wenn ich den Cursor in eine Eieruhr ändere, sollen in dieser Zeit auch keine Eingaben mehr möglich sein.
Wenn der Nutzer weiter alle Knöpfe drücken kann, dann macht dieser Zeiger doch keinen Sinn, oder?

[Christian81]

Ein Cursor ist nur ein Cursor und keine weitere Funktionalität wie Blocken oder was auch immer (wie auch).

[Exasperation]

Meinst du die Sanduhr? Für die gibt es zwei Shapes, einmal Qt::WaitCursor und einmal Qt::BusyCursor.
Bei Qt::WaitCursor sollte keine Interaktion mit der Maus möglich sein, beim Qt::BusyCursor kann man weiterhin fröhlich durch die Gegend klicken.

Wenn du den Qt::CursorShape mit setShape auf Qt::WaitCursor setzt, sollte es eigentlich so funktionieren, wie du dir das vorstellst.

Wenn du nen eigenen Shape benutzt (eine Eieruhr?), musst du eben im mousePressEvent abfragen, ob dieser Shape im Moment gesetzt ist und wenn ja, dann das empfangene QMouseEvent ignorieren.

[Exasperation]

Habs mal getestet mit

Code: Alles auswählen

QApplication::setOverrideCursor(QCursor(Qt::WaitCursor));

Die Buttons lassen sich noch klicken, also musst du einfach im mousePressEvent den Shape abfragen und gut ist.

Code: Alles auswählen

void my_class::mousePressEvent( QMouseEvent* p_event )
{
	if( QCursor::shape() == Qt::WaitCursor )
	{
		p_event->ignore();
	}

	// ...

	base_class::mousePressEvent( p_event );
}

[RHBaum]

Der "cursor" bezieht sich doch auf ein "fenster" ....
Im Normalfall sollte das irgend ein Widget sein, wenn Glueck hasst eines Ohne Rahmen ...
Wenn du für das Fenster, wo du den cursor setzt, das auch auf disabled setzt ... werden alle fenster(widgets) in dem widget auch disabled, und zeigen das dem user sogar an (Buttons werden ausgegraut etc ...)

Aus der Doku zu QWidget:

Disabling a widget implicitly disables all its children. Enabling respectively enables all child widgets unless they have been explicitly disabled.

Einziges "Problem" ist das richtige Fenster(Widget) zu treffen
Nimmst du nen Main-Fenster, also alles was nen rahmen hat, schaltest auch alle rahmenfenster funktionen ab, wie verschieben groesse aendern etc ab .... der Eieruhr cursor kommt dann auch ueber dem Rahmen.

Zum glueck haengen aber Controls(widgets) meist nie direkt an so nem Rahmenfenster (QMainWindow, QDialog, QMidiChild ... etc) sondern haben nen Widget zwischen fuers layout, wo sowas dann gut machen kannst ....

Ciao ...

[franzf]

Nimmst du nen Main-Fenster, also alles was nen rahmen hat, schaltest auch alle rahmenfenster funktionen ab, wie verschieben groesse aendern etc ab .... der Eieruhr cursor kommt dann auch ueber dem Rahmen.

Du solltest von Windows nicht auf die Allgemeinheit schließen
In Windows übernimmt jedes Programm selber die WM-Funktionalität, also Border zeichnen, Events, usw. Unter Linux ist ein WindowManager für ALLE Fenster verantwortlich (ok, Wayland plant das jetzt wie Windows, oder hat es evtl. schon so umgesetzt...), hier ist es KWin. Bei folgendem Code kann ich problemlos das Fenster verschieben, resizen, usw.

Code: Alles auswählen

$ python
Python 2.6.6 (r266:84292, Dec 28 2010, 20:50:13) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from PyQt4.Qt import *
>>> app = QApplication([])
>>> win = QMainWindow()
>>> widget = QWidget()
>>> layout = QVBoxLayout(widget)
>>> layout.addWidget(QPushButton("Hallo"))
>>> layout.addWidget(QPushButton("Peter"))
>>> layout.addWidget(QLabel("Noch mehr und ich fall um..."))
>>> win.setCentralWidget(widget)
>>> QApplication.setOverrideCursor(Qt.WaitCursor)
>>> win.show()
>>> win.setDisabled(True)

[RHBaum]

Du solltest von Windows nicht auf die Allgemeinheit schließen

Ich bin mir unter windows noch ned mal sicher wie es sich da genau verhaelt ^^ weil unter qt stellt sich die Frage eigentlich gar ned, man hat ja immer ein widget drunter, was man dafuer verwenden kann ...
Bin mir echt ned sicher ob die Qt ein DISABLE an das Handle des Toplevel-windows schickt, wenn man QMainWindows::setEnabled(false) aufruft. Die QT koennt und wird das schon intelligent filtern ...
Denk schon die BS werden unterschiede machen, ob sich der enabled Status an die untergeordneten fenster "vererbt" ...

Und logisch korrekter isses auch ...
der allgemeine aufbau ist ja meist ....
Mainfenster
- Menuleiste
- Toolbar
- MainWidget / Clientwidget / Workspace ...
- Statusleiste
und wollen wird man meistens das nur der Client/Mainwidget bereich inaktiv(disabled) wird. Menu und statusbereich will man meist ned komplett disablen .. zumindest unter windows saehe das doof aus.

Aber normal kann es fuer das BS schon nen unterschied machen, ob man das toplevel Fenster inaktiv schaltet oder das erste rahmenlose fenster da drunter.

Denk mal richtig unterschiede machts nur, wenn man keinen vollwertigen eigenstaendigen WindowManager drunter hat, sondern die QT selber die fenster malt, auf nen Framebuffer z.b. (embedded ... )

wie verhalt sich linux eigentlich in deinem Fall in bezug auf Menu / Statusleisten etc ... werden die auch disabled ?

Ciao ...

[franzf]

wie verhalt sich linux eigentlich in deinem Fall in bezug auf Menu / Statusleisten etc ... werden die auch disabled ?

Dann ist ALLES disabled, also auch menu und statusBar.