Preserving code in ui_events.c

What do you want to achieve?

During application development, user code is going to have to be added to ui_event.c but the next time the UI files are exported, the ui_events.c file is re-created loosing all the users changes.

It is going to take a fair bit of work but I think you will need to parse this file and preserve any existing code in there and only add new handler functions.

Perhaps using tags in comments to identify where users should place their code:

// SquareLine LVGL GENERATED FILE
// EDITOR VERSION: SquareLine Studio 1.0.3
// LVGL VERSION: 8.2
// PROJECT: OvenController

#include “ui.h”

// USER_CODE_BEGIN
#include “main.h”
#include “led_control.h”
// USER_CODE_END

void ExitApplication(lv_event_t * e)
{
// USER_CODE_BEGIN
TerminateApplication();
// USER_CODE_END
}

void TurnOnLED(lv_event_t * e)
{
// USER_CODE_BEGIN
TurnONLED();
// USER_CODE_END
}

void TurnOffLED(lv_event_t * e)
{
// USER_CODE_BEGIN
TurnOFFLED();
// USER_CODE_END
}

Do you see alternative options and workaround to achieve it?

No.

Mention some use cases

All use cases will suffer from the fact that this file is re-generated on export.

1 Like

Actually, thinking about it, you should drop the ui_events.c file totally.
If the user chooses to attach to widget events and not provide the appropriate handler then they will get compiler errors. You could perhaps generate a ui_events.h with the prototypes for the functions that need to be coded by the user?

Andy

I don’t think there is any harm in having ui_events.c for a template to use as a starting point. The user just needs to understand to not copy it as their SLS project progresses, and to add functions as needed. This could be done via documentation and in ui_events.c.

The function prototypes could be moved from ui.h to ui_events.h for clarity. Another approach here would be to add more comments by the prototypes so users know these functions have to be in ui_events.c.

I think these issues come down to the question of who the target audience is. The answers will be different between experienced and entry level C programmers. At any case, more comments in the code and documentation improvements will help.

1 Like

Jeremiah,

I think it depends on how you have your source code setup.
For me, I have the project export going into my source folder so if I put a lot of code into ui_events.c and then accidentally hit Export from SLS then I will have lost all my code :frowning:

I personally would prefer that the function prototypes be moved into ui_events.h.

The other option (though perhaps not portable) is to define the functions in ui_events.c as weak then they can be over-ridden by the user.

Andy

I could see how that would be a problem then. Source control would help, but you could still loose uncommitted work.

SLS could add the option in Project Settings to not export ui_events.c which would solve that for anyone who exports directly to their IDE project. Another option could be to only export the file if it doesn’t exist in the destination path.

It’ really not working as it should.

The goal was to always keep the content of ui_events.c and add the new events at the bottom.

It’s already fixed on our side and will be added to v1.0.4.