Small but serious problem with STM32CubeIDE and STM32CubeMX

[msch]

When using STM32CubeIDE, it is easy to inadvertantly make changes to source files that are up on the screen, often as a result of the focus being on the wrong window when one types. (This can easily happen when debugging, e.g. I have the focus on a terminal window, and the code hits a breakpoint, which shifts the focus to a source code window--sometimes when I'm in the middle of typing into the terminal window).

That is not the problem though (although it might be nice to address it, perhaps by offering a code "read-only" mode controlled by a button in the toolbar).

The big problem is that if there are unsaved changes to source files, and one launches the integrated MX, makes changes to the configuration and saves, one is asked whether to generate source code. If one selects "yes", *then* one gets a dialog saying that there are unsaved source code changes, do you want to save them or discard them. I don't want to do either!!!! I want to cancel code generation and go back to the IDE and see what the changes are. I can't stress enough how frustrating this situation is.

When MX presents the dialog about unsaved files, it should offer a third option to cancel code generation and return to the IDE. As it happens, one can simply "X" out the dialog to achieve that effect. But that is not at all obvious. Also, I think that probably the IDE should not allow the launching of MX when there are unsaved source files, period. I don't see a situation where that is desirable to start with. At the least, I think that the IDE should present a warning dialog: "there are unsaved source files, do you still want to start MX?"

[TDK]

> Also, I think that probably the IDE should not allow the launching of MX when there are unsaved source files, period.

How would that be enforced exactly? What if you have CubeMX open and you modify a file, should it shut down? That seems unproductive.

Unintended changes to source code can happen, but almost always result in a syntax error that is easy to find. At some point the programmer needs to take responsibility.

A version control software solves all of these issues and should be standard practice when working on code that matters.

[Pavel A.]

A valid point, yes. Version control does not help here because the user either cannot save the files to inspect differences, or cannot check in before Cube overwrites them.

[TDK]

Okay, I can see that. But it does let you recover the file should you want to. So half-help.

[msch]

@TDK​ That is kind of like saying that cars shouldn't have seat belts, instead the driver should have insurance so that they can go to the hospital if they are injured. It would be better to prevent the injury in the first place.

Of course source control is useful. But the user shouldn't be put in a position where they have to commit changes and then back them out.

Obviously MX shouldn't shut down if it's open and a file is modified. Instead, the first part of the original post applies: there should be an option to not proceed with code generation, rather than being seemingly forced to save or discard source code changes.

[TDK]

> That is kind of like saying that cars shouldn't have seat belts, instead the driver should have insurance so that they can go to the hospital if they are injured. It would be better to prevent the injury in the first place.

Suggesting using version control really translates into all of that? I'm not seeing it.

The "X" is the solution you're asking for. You have a seat belt available. You're just not wearing it because you don't like how it feels.

[msch]

I'm perfectly happy with using the tools myself, the way they are. But I'm offering suggestions to ST on how to improve the experience for new users, of whom which I was one a little while ago. The integration of MX with CubeIDE is a little quirky. It initially seemed to me like invoking MX was leaving the IDE entirely and running a different program. I now realize that MX is simply another (specialized) editor, running on one file in one view of the IDE, and that one can switch back and forth into the MX view. It makes sense to me now. It didn't at first. There will continually be new users of the software, and making their experience more intuitive and straightforward will be to everyone's benefit.

[mattias norlander]

Interesting feedback. Understood.

Internal ticket reference: 122494.

Ticket covers:

• Cancel option in the dialog box
• Prevent opening ioc-file if unsaved content in editor windows

We have to analyze of course, could exist multiple corner cases where especially point two is not desirable behavior. For example multi-project context...

[msch]

Thank you for taking my suggestion seriously!

Point number one is by far the more important. For point number two, I would not *prohibit* the user from opening the ioc file, I would just warn them: "There are unsaved source file changes--do you still want to launch CubeMX?".

Some cases where I might want to go ahead and lanuch MX when I have unsaved changes would be where I want to look for some information in the MX configuration, or perhaps I want to make a change before I forget, such as to a pin configuration.

It might make sense for MX to be more discriminating: it only needs to modify certain files, so it could only invoke the save/discard/cancel dialog when one or more of those particular files has unsaved changes.