Re: std:: exception and qt
Hello, _hum _, you wrote: __> if you the expert why so it is difficult to you to answer the elementary questions, which that you not to trouble with subject review, anew: Well, I will answer. Though I very much do not love all these attempts "to take on ". Especially when people specially ignore good form rules. We once here already about it communicated. I recommend all the same to re-read and start to use: http://rsdn.org/Info/Howtoask.xml http://stackoverflow.com/help/how-to-ask __> 1) what for then they write in docks about that all events transit through magnifiers: __> wiki.qt.io/, Events and QObjects Indeed. Only to showWindow it has no relation. __> as event in Qt is called the object representing something interesting from event; principal difference of events from signals is that events are intended for specific object in our application (which decides that with this event to do), and signals "walk in itself". From the point of view of the code all events are objects of any subclass QEvent, and all derivative from Object classes can redefine the virtual method QObject:: event () for operation with the events intended for given object. __> events can be generated as inside, and outside of application __> [...] __> the Important point is that events come not as soon as they have been generated; instead they get to event queue and come later. The manager cyclicalally processes event queue and sends events at destination, therefore it is called as an operation cycle of events Too all truly. __> 2) what for generally to speak about event sending if there is the synchronous method call (what sense to use this term, instead of for example, simply to write "by a call show there is a method call showEvent"); the Method call does not concern when event will be taken out from queue and is processed. When there is a method call is accurately told in the documentation. I already cited: Non-spontaneous show events are sent to widgets immediately before they are shown. The spontaneous show events of windows are delivered afterwards. Underlined about your case. Pulled show - received a call showEvent. I can not understand that here can be not clear. As I can not understand, in what consequences can result this knowledge if to use development model? Is - wrote for it the handler. There are signals/SLOTS - similarly. It is not necessary to try to control a control flow. __> 3) how further to learn, what mechanism is meant words "events" - through magnifiers or with its involvement are sent, without rummaging in source codes; In any way. Simply not . Or to try on everyone. __> 4) unless from source codes it is possible to rely on the information - after all, in upcoming version they can change these source codes easily. It is possible. For essential changes of behavior the powerful reasons are necessary. So simply source codes do not change. On I can recall only 2 cases when I ran into the changed behavior: 1) At passage with Qt4 on Qt5 was many problems with enclosed native windows. 2) Was a bug (like, in Qt4.6) when the format of result QMainWindow and old geometry changed was very crookedly recovered. It was necessary to fence crutches in the installer which checked prior version Qt and if needed cleaned application adjustments. Till now with horror I recall the fast-growing monster with a title class CompatibilityManager. In the first case all fell off and at once. So problems in ultimate users did not cause, all corrected (truth weeks 2, that normally gl a context pottered). In the second case a problem practically at once revealed QA. But me carried, for someone already got such bug or gave the explanation.