random file open when run the code

[Thsl]

Hello

im trying to run the code , but in the CUbeIDE there are multiple files are opening and pointing to some coding , its hazzle , tried to find a direct answer , ow to avoid this jumping file when run the code.

[TDK]

It's annoying and there's no way to fix this.

[Thsl]

oh 

Thank you for the information. I see—I'm currently using version 1.18. Does the new version exhibit the same behavior? It’s quite inconvenient during run and debugging, as the cursor jumps to different files and unrelated code locations. We then have to manually navigate back to the main file, which disrupts the workflow. Has ST acknowledged this issue, or are there any plans to address it in upcoming releases?

[Andrew Neil]

This is a long-standing and well-known issue:

Annoying open random file when I run my project

random file open when run the code

Jumping to random file after pressing Run button

etc, etc, etc, ...

It's not really random - it's the IDE going through the startup process before it reaches main().

[Andrew Neil]

Does the same thing happen in VSCode ?

[TDK]

It is talked about occasionally. I doubt it will ever be fixed.

@mattias norlander Any plans to fix this?

[Andrew Neil]

---

@Thsl wrote:

We then have to manually navigate back to the main file,

---

Do you?

When it's set to 'Run to main', it will always end up focussed on the first line of main().

Does for me, anyhow...

[Thsl]

hi

i didnt find this issue in VS code. STM32Cube IDE 1.19 has the same issue ? cos im using 1.18

[Thsl]

hi 

in my case curser goes to STM321xx_hal.c file and stop some line of code, then to modify my main i have to manually select the main.c file do any changes , in my code there is no errors or warnings. 

[mattias norlander]

Thanks for looping me in @TDK!

This is probably the most annoying bug we have in the Eclipse/CDT based STM32CubeIDE today. The issue has existed since v1.0. We did some analysis a few years ago on how to fix this. We brought up the issue in the monthly  community meetings with the Eclipse/CDT community experts. We could not find a simple fix that could be up-streamed. The launch sequence of our debug stack does not work well with Eclipse/CDT framework. 

Today the dev-team is fully focused on de-coupling CubeMX from CubeIDE tools (into stand-alone tools). I consider this higher priority for reasons mentioned in this thread (there are more reasons). Once the split of the tools is completed and matured, we can re-assess priorities and possibly try to attack this issue again. No promises made.  

As you know we are today focusing on VS Code and an accompanying growing CLI offering as our future. This bug does not exist in VS Code. 

Conclusion: We are aware. We agree that this has been annoying for far too long. But short-term priorities/bandwidth goes to tools split. Then we re-assess.

Feel free to challenge us!