Most of the events to which an application with a graphical user interface responds occur when a user interacts with this program .

What other events exist?

update

  • Windows operating system
  • Java programming Java
  • Windows API

    5 answers 5

    He began to write comments, but went beyond and decided to publish as an answer.

    The event is a very common OOP template.

    An event in object-oriented programming is a message that occurs at various points in executable code when certain conditions are met. Events are designed to be able to predict the reaction of the software.

    Accordingly, developers can define event classes at their own discretion in all situations when it is necessary to react to changes in the state of objects from the outside.

    The list of events in any OO language (at least) will be infinite.

    The question, however, may make sense for standard events in a particular library of graphic components. The problem is that for both Windows and Java, there are many popular interface development platforms, each with its own set of events.

    For example (and this is only for the desktop):

    • for Windows: Win32, Winforms, WPF;
    • for Java: AWT, Swing, Java FX.

    As a general approach, I can offer:

    • determine the platform / library;
    • find the base event class for the platform / library ( Event , Listener );
    • or find a specific event and check from which class it is inherited.

    For example:

    • Good answer. If you add a brief definition of the event, then I think it will become even better. ) - Nick Volynkin ♦
    • @NickVolynkin added, thanks) - default locale
    • @TimurVi is very grateful for the reward. Glad if it came out to help. - default locale

    The question is too general. Events can be divided into many categories, many of which overlap in many ways.

    For example:

    • External, generated "outside" of the workstation (usually a network).
    • Internal, generated "at the workstation" (various input devices).
    • Internal generated inside the workstation (timers, other applications)

    For your application, events can be:

    • caused by the regular work of your program (you create and send events inside yourself)
    • provided / wrapped by the framework (user input, standard OS events)
    • events you subscribe to (bypassing the framework)

      I will express a slightly paradoxical thought.

      Your observation:

      Most of the events to which an application with a graphical user interface responds occur when a user interacts with this program.

      It is a bit false, because it is just events within the framework of the Event-Driven-Programming concept — event-oriented programming . It was for the GUI that this concept was developed in due time (the 70s probably), although it is easy to imagine another GUI implementation where it can be implemented without events .

      As part of an extended interpretation of Event-Driven-Programming , almost anything can be done with an event. There are various frameworks in terms of which almost anything can generate events.

      For example: the completion of a method can easily generate an event that is embedded in the general event processing scheme in the form of MyMessage - a message about its completion:

       public void myMethod(int myParameter) { //blah-blah MyEventManager.triggerEvent(this, new MyMessage("bye!")); }

      Where there is a certain event listener MyEventManager , further processing the sent message and redirecting the program flow to where it should be.

      Well, etc. In general, it all depends on the wishes of the programmer.

      Naturally, there are drawbacks of such a system, one of the main drawbacks is the low portability of the code and the inconsistency with the paradigm: write once, use everywhere

        A source

        Events can occur not only as a result of direct interaction with the user interface. For example, an event may occur after the timer expires, as well as as a result of the counter exceeding a certain value, software or hardware failure, or the completion of some operation. You can also define your own events that correspond to the nature of the application program.

        • 2
          But what about external events from equipment, network? - Kromster

        Relatively well systematized events model DOM . You can see both the interface events and the environment. Such a scheme can be taken as a basis for "understanding events".

        Events are an element of the object-oriented paradigm (OOP). This is a layer of “something special”, which is difficult to explain in words of another paradigm. I would try to classify events like this:

        a) external / internal - by the channel of entry into the object (such as the release of the exception-error can be considered a purely internal event, and the user's actions - external)

        b) active / passive - by the action expected from the event (the timer ticks - well, okay, but the event of creating or deleting elements cannot be ignored)

        c) standard / self-made - according to the level of standardization. When building your OOP projects, you have to develop your message system (events).

        d) processed / not - by the presence of an event handler (response tables, RESPONSE TABLE). Some events can go "in the sand", some - on the default handler, some - on a given functionality.

        e) parametric / none - by the presence of additional parameters. The refresh event may contain no parameters, and pause may contain a time interval.

        The issue of events is really not an easy one. If you still remember the interruption ... There is enough scribbling on a quite decent book. In the framework of the mini-quest I will confine myself to the above fragmentary thoughts. As previous authors, I note that this is only a small part of what I want to say ...