GitXL shows "junk" after regular diff on XLA file and freezes SourceTree

[Jazz331]

I am using GitXL with SourceTree and after the fix due to Microsoft's last changes to the VBA project structure we were glad to receive the updated GitXL version 0.5.1. But now in our history we see lots of "junk" code when viewing our XLA add-in. When switching back to GitXL 0.5.0 everything is fine, but then we need to use very old Office version to safe the files in a readable format.
There was the suggestion to change from XLA to XLAM because this our other add-in and this doesn't show such behavior, but the history is already checked in and can't be changed. We may think about changing the file type in the future, but also rely on several internal and external factors.
I can't tell if this is a bug or just something that needs to be adjusted on my side. I already installed several versions of SourceTree and also Git. My colleague who works in a different country doesn't have this issue and I already installed and tested on a VM and face the same behavior. We even compared our settings. Only difference are the language settings of Windows, but I also already tried switching from German to English without success.
It results in heavy slow-down and partial freezes of the whole program making it almost unusable. So I would need help to find out what could cause this and how to solve it.
Here is a screenshot that shows the huge load of "junk" code (I guess it's reading the complete file structure?). See the scrollbar is rather much at the upper part, even though we had many code changes (even though some were only automatically changed case sensitives...). Starting with the red /dev/null line the things become unusual.

[fzumstein]

Can you attach a sample XLA file to reproduce the issue? This kind of looks like a log dump to me from https://github.com/decalage2/oletools not sure why that would be triggered. Conversion to xlam is definitely recommended.

[Jazz331]

I am not allowed share my own project's XLA file externally. But if I find some time next week, I'll try to create an example, even though this will be much smaller.
As already written, we can't convert our check-in history and also in our work we have several factors that are against converting our current state right now.

[Jazz331]

I tried a little bit with a fresh dummy XLA file but it didn't seem to work. Now I've tried to delete all specific sheets, values and code from my project's XLA file. Then renamed it and erased all project information from the document properties, changed the VBA project name, kicked out even more code modules to make it easier for you to read the file. When all looked clean in Excel and the VBA editor, I saved the state and uploaded on my gitlab playground. Then just changed one bit in a general function and the junk still shows up. Now with the heavily reduced file content, it comes to an almost acceptable performance in SourceTree but this won't help me for my project as loading the whole file structure kills everything. I wonder what could cause this. It's still there even after deleting so much (> 99 %). I attach the two XLA files with only 1 code line diff here. Just make sure to push one in SourceTree and then rename the other file to have the same name and you can already see it in the commit screen. There are 7 rather small modules left, but in general there is no real automatic functionality left. Just some dummy code to make the situation visible.
VBAtest.zip

[fzumstein]

Looks like the file is corrupt. When I open it on macOS, I get:

Compile error in hidden module: 'mdlGUID'. This error commonly occurs when code is incompatible with the version, platform, or architecture of this application.

[Jazz331]

I am working on Windows, never got anything else. But the code works on Windows clients with Office 32 bit.

[fzumstein]

gotcha, didn't expect the file to be password protected, so I couldn't see it's Windows-only. I still don't have a better answer though other that there's something going on with the file (even though Excel can cope with it).

[Jazz331]

Sent the PW via mail to you in case it helps. The code could be compiled on my 2 clients without issues, as these are leftovers of our main project which many people are using. I can't imagine that the error is on the file, as the users of the original project would have gotten this error too then. Also there is not much left anymore in the test file. Is GitXL somehow working differently? Spreadsheet Compare from Microsoft also shows only the changed code line and no junk.

[Jazz331]

@fzumstein Are the any news from your side? Could you find out why the junk appears?

[fzumstein]

No, but I would start a new xla from scratch (or xlam for that matter) and copy/paste all the code. Something is off with the file.

[Jazz331]

Thanks for your reply. It's simply too much to carry over to a new file.
I already placed the suggestion in my dev team to switch from old file types (XLS, XLA) to modern file types (XLSX, XLAM), which would definitely have less effort on our side. Some years ago when we started a derivative add-in based off our main add-in we directly converted to XLAM without any issues on our and user side. Just need to change few XLS file mentions in my VBA code to XLSX and rewrite our Inno setup script also to remove old XLA/XLS files from the app folder when installing the add-in, should be no big deal. I just had to wait for a good time in my project to convince my project manager. ;)
Just hoping the type conversion removes the junk. I will install the current GitXL version to verify. But it may take some time as we need to bundle this with our feature development. We only check in final states.
I've so far only seen some annoying case sensitive findings, but Spreadsheet Compare also shows them, e. g. Worksheets.count VS Worksheets.Count. Even though I didn't touch the code there. Maybe MS screws up some things again. Or because my colleague and I have different region settings as he is located in another country where German is not the default. I prefer to have only real diffs shown because with more diff lines the performance becomes so bad when you want to scroll through in Source Tree. Not sure which of the tools is responsible for the performance.

[Jazz331]

I did a quick test and converted the add-in to XLAM and it looks fine for future check-ins.
Unfortunately our history with checked-in XLA files still have the whole junk so I deeply hope, that this will still be fixed. Our history goes back some years and the junk causes the whole app to freeze when you want to look up on previous changes.