Oh, thanks for updating it. It always feels good when someone else appreciates your own patch enough to keep it updated.
You are welcome. I am interested in getting this thing into trunk - sooner or later. And for this, we need an up-to-date version of the patch - otherwise it won't make it at all.
I found some free time now and resumed work on this. For consistency I want to extend the changes to conditional orders. It just managed to compile, and it didn't crash yet, but I found some bugs, so I'll keep it for myself until those are squashed.
Do so. And when you are ready, just post the new version of the patch here. I'll then have a second look at it and will test it.
On the way I rewrote some parts of the patch, [...] could you tell me what you changed so I can copy the fix?
It wasn't much, what I did. But it took me several hours to find the root cause, which - as usual - was trivial at the end (i.e. only some lines with a logical error)
As this is just an operational issue, I'll send you the delta, which I did, as diff via PM. Then you may incorporate it into your newest version at will.
The button text part is still not done (shame on me
), but if I'm right we'd just need to throw some SetTooltip calls into UpdateButtonState, similar to how text and tooltip of the refit/autorefit dropdown change.
No shame on you
I also had a look at that part of the topic and tried to implement the button change text thingy -- and came to the conclusion to not do it (yet). The background is the following: The Strings for the label text of the button and the drop down Strings are physically not the same. That is to say: someone intentionally has made them different. As user, we only get puzzled, as the text on the label is the same as one of the commands - by chance. Having seen this, I suddenly knew why I always was confused when using the buttons.
[...]We could (maybe?) also turn them into normal dropdowns like the condition variable and comparator, what do you think?
I think this would be a good idea: currently, it's a button with a dropdown attached, but it better should be a classical dropdown, as some sort of state is compulsory to every single order anyway. However, I think that this would be a "bit larger wheel to turn". I personally feel that this is "another, new feature" - and I have learned here that mixing multiple features into one big patch is close to a guarantee not to get into trunk
Thus, I would recommend to postpone this topic for a minute, fix the "old issues" and better to provide a second patch on top of it which then deals with the button texts/replacement with a dropdown.
Or maybe replace the action for clicking the raised Unload button to Transfer because that's probably used more often?
I don't think so: The modifiers are inherent to any kind of order. I always had problems with it that they behaved like buttons - so let's better replace them with "classical dropdowns". I think that's better in the end.
PS: @All: Warning - I just detected that my latest patch versions above somehow break conditional orders. I will have a closer look into it soon, but as you, 3298, are working on an adjustment there anyway, I don't know how much value my efforts will have.
EDIT: Found the issue - it's a merge clash with r25894 where OrderClick_Conditional() and OrderClick_Share() have been integrated into OrderClick_Goto(). It appears to me that this is just a problem with my patches above. I will try to fix it and come back.