UDS Scanner: Starting/Ending ID and Lower/Upper Bound spin controls override user input
You cannot freely change Starting/Ending ID as well as Lower/Upper Bound in UDS scanner window. The code tries to prevent Starting ID getting larger than Endding ID while typing in things in the respective edit boxes.
I think doping this does more harm than it helps. It is very frustrating to me to not be able to input what I want in the order I want. I'd rather like the scan to fail with displaying a message box if I accidentally made start<end but not have my input ignored/changed while typing in things.
I can change that with a PR. Would like to check first if this is desired as the current behavior seems to be intentional.
Well, yes, the way it works currently is the intentional behavior. Before it would do sort of the same thing but actually just prevent you from making the lower higher than the upper bound so you couldn't, for instance, set the starting ID to a 29 bit ID in preparation for the upper limit also being a 29 bit extended ID because the starting address would have quickly become larger than the ending address. It would just refuse to let you make the start larger than the end. So, instead it was switched to automatically updating the upper bound to always be at least as large as the starting bound. This usually works more or less correctly. But, I could see how it might feel a bit strange as it is silently changing what you typed in. For instance, it isn't really possible to push backspace in the upper bound because it will very quickly go lower than the starting bound and then refuse to let you delete any numbers.
There may well be better ways to handle this problem. For instance, if the start is larger than the end they could be swapped before running the UDS scan. Or, like you said, it could provide an error saying the start can't be larger than the end.
When changing dependent fields SavvyCan has a hard time knowing which of the two fields to change. I might have made just a typo in the lower field but suddenly the upper field changes. (or the other way around, I don't remember). So instead of fixing my typo I also have to fix the other field again. Also in the right order.
The way it worked before was also problematic. SavvyCan didn't allow me to enter certain values. I first had to change some other field. While this at least doesn't destroy my inputs because of a typo it feels weird that SavvyCan changes my input while typing.
I made a PR changing the way it works. I like it much more and it was relativly trivial to implement. Instead of changing any fields it will color the conflicting fields red. There are also more sophisticated ways to solve this but in this end this is a car hacking tool. The main thing I want from it is helping me do the things I want quickly without getting in the way. If I mess up scan ranges it's nice if SavvyCan tells me that but it doesn't have to go to great length to prevent me from shooting myself in the foot.