gx_window_event_process in GUIX event handlers

Can someone please explain to me the usage of 'gx_window_event_process()' in GUIX event handlers.

In example projects, its use does not seem to follow a pattern.

Some handlers call the routine on entry to the handler, others only in certain events.

I can't find the source code for the routine (hidden for GUIX i assume), and as usual i struggle to find detailed documentation for GUIX.

Thanks

Alex

  • Hello Alex,

    The only documentation which I found is:
    X-Ware™ Component Documents for Renesas Synergy™ > GUIX
    which does not explain what this function does in details.

    The gx_window_event_process() function is used to handle essential GUIX events such as: GX_EVENT_SHOW, GX_EVENT_FOCUS_GAINED, GX_EVENT_PEN_UP, GX_EVENT_PEN_DOWN etc. Thanks to this function a window can be displayed, a pressed widget can gain a focus, a pressed button can be displayed as pressed down. If you would like to achieve a different bahaviour of the GUI in case of such basic events you could skip the gx_window_event_process() function call and implement event handling by yourself.

    Usually gx_window_event_process() function is called at the beginning of a window handler function. This guarantees that it will be called for every event.

    To view this function source code you would need the development and production license which you can generate on Synergy Gallery ("Create a Development/Production License" button). Set this license in e2 studio. Then add to your project the GUIX source:
    Synergy Configuration window > Components tab > Express Logic > all > gx_src (selected)
    Press Generate Project Content button and you will see the file:
    <project_dir>\synergy\ssp\src\framework\el\gx\gx_src\gx_window_event_process.c

    Best regards,
    anper

  • I think it's pretty clear that this function does the default processing for an event - I say this based on my experience with these types of event handling architectures. So normally you call it at the start and then have some logic that does additional stuff for specific events, like drawing extra stuff when the window is shown:

    gx_window_event_process() // do the usual stuff for everything
    switch (event)
    SHOW: do_more_stuff()

    Or less commonly you do some pre-processing before letting the event be handled:

    switch (event)
    SHOW: do_stuff_first()
    gx_window_event_process() // do the usual stuff for everything

    Or you could call it in a "default" clause. This would stop the default behavior for the events you handle. So maybe you don't want it to display a window when it gets a SHOW event; maybe you want to handle the SHOW event your own way. Thus you write something like this:

    switch (event)
    SHOW: do_only_my_stuff()
    default: gx_window_event_process() // do the usual stuff for everything but SHOW

    What you cannot do is both of these because it makes no sense at all. Why process the event and then process it again if your code doesn't handle it?

    gx_window_event_process() // do the usual stuff for everything
    switch (event)
    SHOW: do_more_stuff()
    default: gx_window_event_process() // do the usual stuff for everything but SHOW

    Unfortunately this is exactly what the Hello World example program does, with any comments to indicate why they would do something so incomprehensible. I don't know what processing an event twice does but it can't be good.
  • In reply to MCP:

    Hi,

    I can confirm that calling gx_window_event_process (or another xyz_event_process function for other widgets) does effectively let user retain default widget behavior while adding its own on the top.

    Each widget has its own event handler and draw functions - if user chooses to override either one or both, it is recommended that the new function calls the original handler so that necessary housekeeping is still performed. For example, defining your own draw function that is empty will result in widget being invisible (its children won't be drawn either).

    As for before/after/inside - it depends and what user is trying to achieve. Typically my projects call default draw function before everything else and default event function at the end. Standard drawing needs to performed first (for obvious reasons) but doing standard event processing last will allow to intercept certain events and prevent their default behavior from being implemented (by returning GX_SUCCESS immediately). Calling event processing at the start will take this opportunity away as default function has already completed by time user executes code.

    Calling event processing inside the event case is similar to doing it at the end but it optimizes certain cases that are known to do nothing inside the default event process function (all GX_SIGNAL cases fall-through). Typically compiler/linker would optimize these anyway, unless optimizations are disabled. I personally avoid this approach as multiple points of exit are considered a bad coding practice and violate MISRA C rule 14.7.

    Regards