All code generated by wxSmith ends in LF, ignoring the EOL mode setting in Editor->General Settings and the detected EOL mode of the file. In fact the \n is hardcoded in wxSmith's code.
After editing the code the file has mixed EOL and GIT warns on every commit about this.
To add: it also does not honor tab or space...
Idea: Use \t and \n in all wxSmith template codes and at the end of the code generation make add a replace function that replaces the \t and \n accordingly...
Function wxsCoder::RebuildCode() in wxscoder.cpp seems intended to do what you propose, but sometimes (not always) the generated code has wrong EOL and tab.
I'm surprised, wxSmith generates the full code each time you change anything (for example, check Centered in a wxFrame), so RebuildCode() is called five times per change.
This patch fixes EOL when adding events to widgets. This part of the code writes directly to the editor using fixed '\n' as EOL. Will look for the '\t' issue and others fixed EOLs this week.
This patch includes the one above and solves EOL and \t incongruencies found so far. The correction of them was left as a todo by the original coder in wxsitemres.
To achieve this I have made wxCoder::RebuildCode() static and public.
Last edit: Miguel Gimenez 2019-05-24
@bluehazzard: Would you handle the patch?
Added removal of a now obsolete comment
Yes i can take care of it. If I am lucky, this weekend...
Some parts of wxSmith (for example wxsmultichoicedialog.cpp) still inject tabs in the generated code, but I think they can be solved in a future second patch.
I have found why some tabs were surviving. The RebuildCode() method in wxscoder.cpp was using the tab setting inverted. The attached patch adds this correction.
Last edit: Miguel Gimenez 2019-06-21
Can you tell me how i can test this?
If I set the setting in Settings->Editor->General settings->Editor settings->End-of-line-mode->LF, restart codeblocks and create a new wxSmith project the line endings are always LF CR...
Do i test wrong or does it not work for me?
When you use the wizard wxSmith isn't even called, the files are pre-existent and they are simply copied using the GenerateSource function in wizard.script (the only change is macro substitution). This function can be modified so the wizard-generated files have correct EOL and tab settings, but this is another issue.
I create a new wxWidgets project using the wizard and then I create a new dialog using wxSmith -> Add wxDialog. This new dialog's CPP and H files should follow the EOL and tab settings.
Ok, thank you!
I was thinking that all code is rebuild if something in the wxSmith editor was changed...
here is a patch that should replace all.
At a other point there should be replaced all other scripts too.
I do not want to replace the line and tab endings in the script plugin for every generated file, because there is the possibility that a file must have tabs or a speciffic line ending. It is better to "fix" all scripts...
[Edit:] Updated patch.. had some error in it. Still building...
Last edit: bluehazzard 2019-09-06
Good job with the scripting wizard.
In wxscoder.cpp the boolean UseTab has been removed, so this line
should be
In sdk/globals.cpp, function GetTabStr(), this line
should be (because there is no need to translate the tab)
Also, you can change this
to
@bluehazzard
1. Please make sure to prefix functions in globals.h with cb prefix!
2. There is the automode which uses the EOLs in current editor to decide what should be used. You want to respect this, too.
Last edit: Teodor Petrov 2019-09-08
The wizard part kicks only in if there is no project, so i do not see how the auto mode should be used.
Should i rename to existing functions too?
I still do not understand how the auto mode should handle this... In all cases i use this function (the wizard and the wxSmith code) new files are created. So i should respect the current open file in the editor for line endings and tab settings? What if the current open file has nothing to do with the project?
How does it work:
1) A new file is created. The line ending is set to the current setting in the settings->editor. If the setting is on Auto the line ending for this operating system is used. This is the case for all new files in codeblocks, since ever. This patch only ensures that wxSmith respects this behavior. Until now "\n" mixed with "\r\n" was used and the setting ignored. Now new files are consistent with the settings.
2) The same is for the tab charachter. Here i add a function that returns the setting of the tab charachter. For new files this does not change anything, only for newly created files it makes it consistent to apply the settings. At the moment they are simply ignored and spaces used every time. Old files are not affected by the tab part of this patch. I think this is part of a second ticket ( i can not find it so i may be wrong here and will create one) i will fix in a other step.
Auto mode means that newly added text should respect the majority of the EOLs in the file. You've explained what happens for new files, you need to expand it to already existing files where wxsmith is replacing code and not just modifying code.
Is it clear now?
@Miguel Gimenez: Thank you for your suggestions. I have reintrpduced the UseTab variable. I think a compare is faster then a copy... I will post the patch as soon as i have understand obfuscateds suggestions and my build is finished.
Ok, this patch honors all settings about line endings and tabs.
It is not easy to honor the auto settings, but i tried my best...
The auto part can be polished later, if needed.
The comment around line 439 of wxseventeditor.cpp is now obsolete and should be removed:
Branch is here: https://github.com/bluehazzard/codeblocks_sf/tree/fix/ticket/832/1
The removing of the comment is missing.
I probably have to increase the SDK number?
Not sure if anybody really tested this, but I can tell that on Windows, this makes things really a nightmare and where the line-feed was working properly its now screwed every time you change something in wxSmith. So either the patch is incomplete or its simply not working at all.
Are you sure you've attached the right version here and tested this under both: Windows an Unix?
Yes i tested it on windows...
Have you tried the branch from github or the patch?
What are your settings for line endings? Auto? Do you have files with mixed line endings?
Is your setting different from the file?