search

PhonologicalCorpusTools / SLPAA

5 stars 0 forks source link

[BUG] modifying info. while not having x-slots visible causes issues with stored x-slot information #372

Closed kchall closed 2 months ago

kchall commented 2 months ago

Describe the bug If a sign has been coded with x-slots, and then those are turned off in the preferences temporarily, modules that were modified while the x-slots were turned off seem to 'lose' their x-slot information. When x-slots are turned back on, they show up with no x-slots selected, but then it is impossible to edit their x-slots, because SLP-AA seems to think they are there.

Sample corpus file Discovered this while working on 2023_07_26_DAMN_DEGREE_v4_MR_KCH.slpaa. In the sign DECLINE, I wanted to modify some of the locations. The initial coding looked like:

image

The location window is currently too big to fit on my screen, so, I turned off x-slots in the preferences to allow myself to modify location modules. I made modifications to H1.Loc2, H1.Loc4, and H1.Rel2. I saved the changes and then turned x-slots back on. The summary now looks (in part) like this:

image

...where the three modified modules no longer have known x-slot information and are shunted off to the left of the main coding summary.

When I edit one, e.g. H1.Loc2, nothing is selected for x-slots:

image

...but if I try to do so, I get the warning message about overlapping with an existing selection:

image

Expected behavior It should be the case that modifying a module while x-slots are turned off does not affect its x-slot information.

Operating system and SLP-AA version

kvesik commented 2 months ago

@kchall I will look into this and see what the underlying issue is (I suspect it's because when a module is saved in no-x-slots mode, it is saved with no x-slot info). I can't recall whether we said that users should expect to be able to flip back and forth between x-slots and not within a corpus-- it's possible that this issue is coming up because I didn't think it would be relevant. :) Do you remember?

kchall commented 2 months ago

@kvesik Thanks! I don't think that we specifically made a plan for it, but I guess it's just odd that modules that haven't been edited are 'sticky' in terms of remembering their timing, while those that have been lose it, even though it specifically can't have been the timing that was modified.