-Christian --
I'm familiar with this as I often run into it myself.
The problem with adding a global way to edit the c++ code is
that it'd be hard for fluid to, in a cross platform way, detect
where you made your changes in the generated c++ file, and then
fold that back into the .fl file. I suppose a "special" generated
.cxx file could include special comment markers that could help
fluid re-fold your changes back into fluid's "in memory"
representation of your code, but I could see that being very
tricky to do.
The workarounds I've found over the years is to either (a)
carefully edit the .fl file itself, or (b) not get carried away
with using a single .fl file to make the entire application, and
implement only the GUI aspects in one or more .fl files, and make
calls to a separate module (that I maintain in VI) to do all the
actual application's work. This way all the code I might commonly
want to change globally will be in my separately VI maintained
code.
If you edit the .fl file, keep in mind the .fl file's
escaping of special characters, like the escape character itself
(\) has to be doubly escaped inside the .fl file. So if you add a
printf() statement, be sure your \n becomes \\n inside the .fl
file. As long as you carefully maintain .fl's formatting, editing
the .fl is pretty safe to do.