Hi all,
I’m new to Xojo and have to take over an existing quite big project.
First step I did was to save the project as text to manage it on Github for source versioning
I noticed that source files are updated by the IDE to add/update whitespace, making source diff very difficult.
Here is an extract of source diff from Github Desktop to illustrate:
Can anyone tell me what I have to do to prevent this or what I’m doing wrong ?
Thank you in advance
Philippe
Are you editing the files in an external text editor?
It appears to be tabs at the start of blank lines. Did you out dent and then indent it again?
No, this is the result of automatic IDE behaviour when I save the project.
The screenshot is just an extract of a very long file (56k lines) and it’s like this for the whole file.
You’re right indeed,
I don’t want to change anything manually as the file is very long and I’d have to do it for every file in the project.
I’d like to find a solution to prevent the IDE from doing such a thing I think, maybe there is an option somewhere for this ?
Not that I’m aware of. I’ve not known a version of the IDE that didn’t indent everything that was inside a loop or conditional (if, case etc). That’s what this looks like. If you are just saving this in text format now, how did the existing version get into git in the first place?
You could do a find and replace for “\n\t\n” and replace with “\n\n” in something like BBEdit (across all files), however you will find that double nested items are “\n\t\t\n” so it becomes more of an issue. Equally you will end up doing that for every single version you ever save. I would just take the hit this time and have things easy from now on.
The good news is if you just accept everything it is unlikely ever to happen again.
The thing we need to know is what version of the IDE was the project last edited in and what are you using now because if they’re nott the same, you will see things like this as bugs in the IDEs save routines were fixed over time. For instance, a few annoying bugs were fixed last year which make the IDE only save things that were actually changed by the user.
The good news is if you just accept everything it is unlikely ever to happen again.
I hope so
Thanks for the info,
I don’t know about the xojo version last used to save the project (it was a binary project until now).
And I’m using the last xojo version from now on (version 2022 release 1)
You can’t upload a binary xojo project to GitHub, so it must have been text.
It used to be a binary project not using version control.
Now it is a text project under GitHub
Ok I think I understand what happened.
It was my mistake, I used Visual Studio Code to search code (for conveniency, much faster than using the IDE cause the project is big, I will have to dig into optimizing it, I already noticed there are 6843 warning in the project…).
But VSC had specific indent param making all the changes I was talking about.
So Xojo had nothing to do with it.
I’m sorry for the inconvenience and thank you all for taking the time.
Glad you go to the bottom of it.
Don’t think about warnings as “you’ve got to fix this right now”.
Now that the API 2 transition is done, it’s likely going to be a long time before any of those warnings become something that you need to take care of. One of the misconceptions that many users have is that they need to clear that list right away, when the reality is that the deprecated items for API 2 will likely never go away, because API 1 is heavily used in the IDE itself and the risk of introducing critical bugs by transitioning is just too high.
Something else to keep in mind… if you do start to transition the project to API 2, do it in a branch. it is very likely that a project of that size will not be buildable for a period of time while you work out the issues… and keep a close eye on the things that now have a zero-based index that used to be 1-based. Things like Mid => Middle.
Very good to know, thank you for this
Having said that, the project does not have a lot of deprecated warnings, more:
“Unused method parameters”
“Unused local variables”
“Unused event parameters”
And I read somewhere that getting rid of those can improve compilation time, can you confirm ?
Yes, about 20% in my app.
It won’t improve compile time. They’re handy for knowing if you care, but when you’re just starting out, you can probably turn those off for now.
Thanks, I remember I read it from you 
