There is no definitive answer to your question, because creating useful diagrams largely depends on what information you want to convey to the reader. My advice: you can never show all the functionality of your program on just one diagram; event processing is often too complex and ugly - try to split it into smaller parts and decide individually which diagram is useful for the aspects that you want to show.
For each of them, your attention should always be on the reader: what do you want him or her to understand?
For starters, it’s usually best to write user stories and show case studies if you don’t already have them. They convey the functionality of your program and help identify processes and organize the way you think about your program. For each of these processes, a sequence diagram is probably most useful to show how everything works. For example, if one of your program functions loads an image, you should draw a sequence diagram showing the main components, objects, and sequences of events involved only in the loading procedure.
The next step is to classify the remaining events and objects that are finer-grained or do not interact directly with the user: which events are internal (i.e. are sent and processed inside the same object), which are external (between some objects) or even global (affecting the entire application). This will help you identify groups of objects that interact with each other.
Depending on how complex the object is, I often display internal sequences of events in a state diagram or block diagram.
If you have several smaller groups of objects where interactions are not too complicated and more interesting from the point of view of who does why, not when, you can use slightly modified class diagrams - this may not be very formal, but for of some concepts, they are often more useful than flow charts, state diagrams, or sequences.
It should also be noted that in some cases, the chart does not really help. Sometimes it is much more convenient to write a short text representing an example, or to collect information in tables. The documentation is complete when the reader understands the concept of what your program does and how it does it. For everything else, there is always source code.