@TWAMatthias Are you on Windows? If so, your second issue is probably a duplicate of #1531.

@isc-bsaviano
Yes, I'm working under Windows.
It’s similar but not the same issue. The setting objectscript.autoAdjustName causes the changes from LF to CRLF.

I have switched it off - but it may be a problem that you want to fix.

Hi @TWAMatthias, thanks for checking. The objectscript.autoAdjustName code uses a different method to replace the file contents than the post-compile refresh does so the correct changes trigger a reload with the server when objectscript.syncLocalChanges is set to vscodeOnly. I still think the best way to avoid issues like this is to configure git to be less sensitive to line endings.

As for the export issue, I think it's going to be very difficult for me to reproduce given my experience debugging #1526, which I believe was reported by a colleague of yours. If you are willing to help me identify the cause I can give you a version of the extension with extensive logging so we can see what is going on. Do you only see this issue when exporting from the Explorer view?

Hi @isc-bsaviano,
Sorry for the delay, I've been busy lately.

Hi @TWAMatthias, thanks for checking. The objectscript.autoAdjustName code uses a different method to replace the file contents than the post-compile refresh does so the correct changes trigger a reload with the server when objectscript.syncLocalChanges is set to vscodeOnly. I still think the best way to avoid issues like this is to configure git to be less sensitive to line endings.

To be honest, I can't see how the git setting would help. I tested the git config. During iris-export vscode it still opens all exported classes (unsaved state, CRLF). When I save it, it compiles and converts it back to LF. Nothing to do for git, but a lot for vscode and iris - for a whole bunch of nothing.

When we set syncLocalChanges to vscodeOnly, switches between branches does not trigger the import to IRIS.

I can't see why the different method shouldn't use the same line seperator for it or it needs to be configurable.

But this is up to you. We set the autoAdjustName now to false.

As for the export issue, I think it's going to be very difficult for me to reproduce given my experience debugging #1526, which I believe was reported by a colleague of yours. If you are willing to help me identify the cause I can give you a version of the extension with extensive logging so we can see what is going on. Do you only see this issue when exporting from the Explorer view?

I tested a like bit more. The solution from #1526 unfortunately doesn't work properly. I switch to a branch with about 60 changed classes and I got the same issues.

• Several compilings
• "open for editing" message (see below)
• Remains uncompilied classes

ERROR #5864: User 'SYSTEM' in process '9232' has 'hide.this.package.MyClass.cls' open for editing.
  > ERROR #5030: An error occurred while compiling class 'hide.this.package.MyClass2'

And yes, you can send me a custom version with more logging.

br Matthias

Thank you for responding @TWAMatthias. Those git settings should tel it to ignore line ending differences. They are in use a lot by teams that work on different operating systems. I can look into changing this extension's behavior so the line endings are preserved where we can. However, having git ignore line endings will prevent this behavior from happening with any tool your team might use, so I would recommend doing it anyways.

Thank you for volunteering to install a version with logging. Please install the vsix in the attached zip archive, reproduce your issue, and then send me the contents of the ObjectScript Output channel. Feel free to obscure the URIs for your files if necessary, I just need to know what order the events are fired for a specific file.

vscode-objectscript-3.0.3-matthias.1.vsix.zip