Ubuntu 20.04.1 LTS, SeamlyMe 0.6.0.1 20201026, 20200730
When using the search function in the “Add known” dialog to find measurements involving “hip”, if I right-click the list SeamlyMe closes without comment. “high” is fine, “highhip” closes, “hip_circ” closes. “waist” is fine. “hi” & “ip” are fine, at least part of the time.
ETA: The moment before right-clicking:
Hmmm . The search term shouldn’t matter… That being said, is this something you just noticed showing in recent releases?
Won’t be at my PC’s till later tonight… so I don’t know if this is affect the Windows release as well.
On Windows: These are fine - hip, hi, waist, ip
These close the program - high, hip_circ, highhip
Yeah, I was a bit shocked when in an effort to have an accurate report I tried “waist”, (I was wanting to add a hip-waist measurement,) & Me didn’t vanish. It can’t have been much before the July 30 release that the bug was introduced, since it wasn’t much before then that the search field was added to the “Add known” dialog.
In MacOs using the same SeamlyMe weekly release when I open Add Known, the right click works fine for any measurement. It only crashes for right click with the same measurements when I use Find: Independent of the word I use in Find it crashes.
I just checked the “Add Known” issue and it is confirmed in the windows ver. It indeed appears to have started in the release with the “find” feature added. I found that it doesn’t matter what search text is entered… as soon as anything is typed in the find box, and then trying to use the right mouse button the program closes.
Which also brings up another issue. The dialog is handling the “textchanged()” signal - which means every time something is typed the dialog has to handle the signal… instead of handling the “editingFinished()” signal which is emitted only when the < return > key is pressed. In addition, when the < return > key is pressed - the dialog closes. It should not do this. The < return > should only trigger the OK button when the find lineedit looses focus.
Another UI nit pick item… the Dialog title currently reads “Measurement data base”… since one presses the “Add known” toolbutton the dialog should be titled - 'Add known measurements".
This matches the trend to have auto-complete in searches. If we need to take that step backwards in order to safely proceed, that’s okay, but we don’t want to lose that functionality lightly. It’s helpful for imperfect spellers & typists. For instance, if I were to start typing “hieght”, I’d be able to see quickly where I went wrong & use “height_hip” to know how to actually find all the measurements with “height” in them.
That would be fine if the dialog WAS auto completing… it’s not.
Either way to not handle the < return > properly is not desirable. You can connect both signals. In fact what should happen is, when the find line edit has focus the OK button should be disabled until the line edit loses focus - either by < return > or clicking elsewhere.
I looked at the dialog code last night and found the problem, and it should be a relatively simple fix.
Just pushed a fix for the tree widget’s context menu crashing the app.