Trying to open the same odf to "reload"

[Bumblebee001]

When I try to open the odf (with same name) to reload or to access an earlier version from another directory, I get this:

[Bumblebee001]

For some strange reason this happened at least twice. I tried again now and this did not occur. I was looking at the old settings I had on a backup copy and now opened the latest file I have been working with - no issues!

[larspalo]

Please try to find a way to reproduce this issue, preferably with an odf that can be shared so I can examine it and test/fix it. At the very least I must have all the exact steps done to trigger this crash with every detail. Otherwise I'm pretty much in the dark!

[Bumblebee001]

It seems to happen when the odf is open on a stop (internal rank window) and I select to open the other odf. I got the issue again in this situation. So basically when the focus is away from the default opening window. GOodf crashes and closes.

[larspalo]

@Bumblebee001 I cannot reproduce this issue on Linux or with a windows crossbuild running in wine. I'll try to test a github release on a 64 bit windows computer and see what happens.

Just to be clear, does this happen every time for you? Steps to reproduce the issue are:

• Open an .organ file from menu or with Ctrl+O
• Go into a Stop internal rank tab
• Open the same .organ file again from menu or with Ctrl+O

Is this right or are you doing anything more or in between the steps? Are you using a recent github release version?

[Bumblebee001]

Those are the steps. However this time I was trying to open an identically named odf on another drive.

On Wed, 22 May 2024 at 15:49, larspalo @.***> wrote:

@Bumblebee001 https://github.com/Bumblebee001 I cannot reproduce this issue on Linux or with a windows crossbuild running in wine. I'll try to test a github release on a 64 bit windows computer and see what happens.

Just to be clear, does this happen every time for you? Steps to reproduce the issue are:

• Open an .organ file from menu or with Ctrl+O
• Go into a Stop internal rank tab
• Open the same .organ file again from menu or with Ctrl+O

Is this right or are you doing anything more or in between the steps? Are you using a recent github release version?

— Reply to this email directly, view it on GitHub https://github.com/GrandOrgue/GoOdf/issues/102#issuecomment-2124848685, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVM7NU7B4EPMLNSW2G6NQLZDSO6DAVCNFSM6AAAAABIC7VDRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUHA2DQNRYGU . You are receiving this because you were mentioned.Message ID: @.***>

[Bumblebee001]

Did you manage to replicate the issue?

[larspalo]

Finally got some idea about what this issue could be about. Fixed a crash caused by trying to open a recent file that didn't actually exist anymore (for instance because it had been moved somewhere else). You could test an intermediate build at https://github.com/GrandOrgue/GoOdf/actions/runs/9811410536 to verify if this issue is fixed.

[Bumblebee001]

I clicked on that link and cannot find anything I can download!

Mark

[larspalo]

At the bottom there's an artifact for windows, direct link is https://github.com/GrandOrgue/GoOdf/actions/runs/9811410536/artifacts/1671968891 to download and extract.

[Bumblebee001]

It seems like the issue is still there.

[larspalo]

I need the exact procedure you're using to make the crash happen. There's a huge difference if the issue happen when you manually open an .organ file with Ctrl+O (File->Open menu item) or if it happen when you select the organ in the recently used file list. Especially if you have moved the file or have them on some temporarily attached discs/drives.

I certainly cannot get a crash to happen if I have the same .organ file in two separate directories and directly alternate opening them repeatedly without closing the app or doing anything in between.

I previously did manage to get a crash when using the recently used file list if I had moved the file to another location and the program still tried to open the now non existing file, but that should have been fixed.

If it's too difficult for you to give an exact description, you could perhaps record the screen and upload a video (youtube is free) that show the whole process to get the crash to happen from the first startup of GoOdf to the crash, possibly with some additional showing of the circumstances - where the files are in relation to each other, that they actually work when loaded individually on a (single) fresh GoOdf instance.

If only a specific .organ file causes the crash there might be something else completely in the reading/parsing that is the culprit. If it can be done with any random .organ file the reason is likely completely different.

[Bumblebee001]

I am using the laptop keypad to click on things.

I opened GOodf from my desktop (it's where I keep the GOodf folder after unzipping the download and a shortcut I created using an icon I had and have been using for your software).

I loaded Burea Church 3 odf (not any of my odfs this time to ensure it was nothing in my odfs that was generating the error)

Went into pedal stops and selected first stop.

I opened its internal rank tab

I then went to File > Open File > Went to same external drive and same Burea Folder and selected another Burea odf marked as Burea_Church_4x3 and the error window popped up.

I clicked about 3 times "ignore" then it loaded this odf into GOodf. The program is not crashing. as such; It's this error window that pops up - the same one I posted at the beginning of this thread.

I hope this helps.

Mark

[larspalo]

Is this happening only when you're on the right panel of a Stop internal rank tab? Never on any other right kind of panel even if it's the same .organ files you have open and is opening?

I've still not been able to reproduce it myself...

[larspalo]

@Bumblebee001 Ok, so at last I've been able to make it happen, but it seems to be a windows port particular which makes it harder to track down but I'm on my way...

[Bumblebee001]

To be quite honest I have not tried out other scenarios. But I guess now that you have managed to replicate the issue you can test other situation that you consider important to identify. Very often I only report the situation that I needed that gave be an unexpected result.

[Bumblebee001]

It did not happen if I went into the Tremulant of your Burea 3 sample-set on my external drive and then try to open the 4x3 odf. GOodf went straight into the new file.

[Bumblebee001]

I got it when I was on the Ta' Xbiex sample-set (original, switches) and tried to open the Siggiewi odf from that view. Clicking Ignore repeatedly did not help. Abort shut down the program.

[Bumblebee001]

I am using GOodf 0.14.2

[larspalo]

This should have been fixed with commit 1427433d5559bfab723d16f2bd133cfeb2437114 and you have a build to test at https://github.com/GrandOrgue/GoOdf/actions/runs/9880283246/artifacts/1688126810 if you want.