Volume knob in focus area

EA4GLI

I posted this at the end of another issue thread. I think it might make more sense if it is presented separately. This is a minor bug. However, minor bugs could have implications later on so it might be good if it can be added to the bug tracker. Also, I think it allows for other users to replicate the bug, if it exist, and maybe point to a user issue vs a software bug.

The bug:

The infocus area of the volumen round slider is smaller than the actual image of the slider in the screen. This happens in both the floating menu besides a slice and the Active slice menu on the side menus. This makes is very difficult to move the volume up and down (left and right) with the mouse pointer, because you can have the mouse on top of the knob but SmartSDR doesn't recognize it and doesn't set the focus of the mouse on the volume. It only happens with the slice volume and not the other sliders.

SmartSDR 1.5.1.152
Flex 6700 HW v. 1.5.1.70
Windows 7 64Bit SP1

See video below for a graphical description.


https://www.youtube.com/watch?v=X0qHbEnqR_g

K1UO Larry

I'll vote it up 1 for that "fix".

DrTeeth

I find this issue very common with many controls in SSDR.

EA4GLI

Hi Guy,

I tried on pretty much every knob, button and switch inside the SmartSDR window and the only one where I can see this issue is in the Slice Volume. Where are you finding this?

DrTeeth

Hi Salvador,

On nearly every slider to some extent or another, particularly noticeable on the three slice audio controls on the right of the screen (I use these more than those attached to the carrier line). I even noticed that the active area has got slightly smaller with some of the recent releases. It was either from 1.3 > 1.4 or 1.4 > 1.5. A little OT:- I just hope the 'contest version' (aka 1.6) sorts out these interface inconsistencies/difficulties. My biggest bugbear is that the mouse scroll wheel does not operate the slider under it like in most windows programs...I am forever trying to operate the slider and find I have detunes my slice. Sri for the rant.

EA4GLI

Tim, have you guys had a chance to review this one?

Ken - NM9P

I have always noticed that, especially when trying to "click-bump" a slider up or down one step at a time, i must be extremely precise as to mouse placement before it will "take" the command.  Some sliders are more forgiving than others.  Some require almost pixel-perfect placement.  

For this reason, I have often dreamed of up/down entry boxes like we have on TX bandwidth settings rather than sliders for some functions that need more precision (Such as AGC-T, power, mike gain, Downward expansion, CW Speed, etc)  If that were provided, I could also click in the value box and manually enter a precise number if needed.

DrTeeth

Ken, I find that many of the numerical boxes in SSDR will take text inputs, so if you want a non-standard frequency step, for example, one just has to enter it in the box in the normal way. Having to be so precise with my cursor for so many adjustments really grinds my gears. Maybe the expensive Maestro is the solution to this issue, hi hi. Seriously, this really needs addressing. Hopefully, if it drove/drives enough contesters nuts we could be in luck soon.

Happy Thanksgiving to you and your family and everybody here.

Ken - NM9P

I have a feeling that we may see some Maestro-inspired GUI improvements at some point in the future.  I strongly considered picking up a maestro, but an amplifier is higher up my needs list at present.  

Jay Nation

Ken and thread

Maybe a larger 3rd party button, (DDUtil comes to mind) with a macro command that increments and or decrements, +1 or +3 or +6, something like DDBU"X":6; have it query for the current value add or subtract from it and then set the control. I'd love to have keys on my Genovation keypad labeled BUMP+ and BUMP- .

Or would that be useless?

73, Jay - NO5J

EA4GLI

I just find this issue on the slice volume (AF) knob, it is the only one that is smaller than the rest in the UI. I think it can be fix in the code giving a larger area to the InFocus of the UI element.

Jay Nation

Salvador
I don't doubt what your saying. It's obvious in the video. I have trouble with this too.

However, I can't detect any difference in size, I just wiggle the mouse until the popup for the current value opens up which tells me that windows has noticed its that it's focused on the control, then click and drag. However increasing the size of the focus area a little would be useful.  So would increasing the size of the trough on both sides of the slider knob, or changing the color of the troughs to something with more contrast. to make incrementing/decrementing by single mouse click easier. 

Which is one of the reasons I have one of the buttons on my FlexControl assigned to Slice AF. 

Higher resolution displays might make this even more of a problem. 

73, Jay - NO5J

Jay Nation

There are a couple of Windows mouse settings that might be related. I have no idea if they will help or hurt. I just turned them on now, to find out what if any effect they might have.

Enhance pointer precision
and
Automatically move pointer to the default button in a dialog box.

My guess is the first might help, and the second probably doesn't even apply to the issue.

The first supposedly enables more precision, the slider above that controls mouse acceleration.

In my case the Slider was defaulted at the 6th index mark (the middle) and when I enabled mouse precision I had to lower (slow) it down two notches to tame down the cursor slightly. It "feels" like it helps a little, might just be the placebo effect.

73, Jay - NO5J

Walt - KZ1F

I'll play with that next time I'm on ssdr. Even back in my Windows development days the control itself was what had focus, not some overlay. For instance, in javafx8, and Swing, before that, and SWT, etc clicking anywhere in the control generated a focus msg. I have to believe WPF works the same way as mfc did before it. It could be since these controls are very small indeed as is the pointer that it's very sensitive to being precisely over the control. In either event, that would be a Windows issue as opposed to a FRS issue.

EA4GLI

I tried both Jay and neither provide an improvement. The default button one is even counterintuitive to me as I lose the mouse in the screen.

EA4GLI

You might be right Walt. The interesting thing is that is only happens in the AF Volume for the slice and none of the other knobs that is what makes me think that it might have a infocus area vs being a library knob class with default values.

Walt - KZ1F

I just tested that Sal and it works as I would expect. Now...having said that, look very closely at the control...in fact go full screen. The control for volume is a lighter shade of black than the surrounding area. It is a very subtle difference in shade. The height of the control is the diameter of the circle. If you type below or above the upper or below the lower 'latitude' of the circle you are not in the control. The boarder of the control is a different shade. The slider proper is inside the border. One of the other things I suspect the WPF slider does, as Java visual controls do, is they can be anchored to surrounding controls such that when the surrounding areas change size so do they. This, likely, explains the perceived different behavior of the last several releases or point releases. Remember WNB was added. Yes, it was added to a different 'tab' but the size of the drop down is likely tied to the inParentSize of the others. The would result in a slightly different sized slider with a slightly different slzed border.

Jay Nation

Salvador 

I also disabled the default button option, didn't affect SSDR any that I could tell, But the cursor went a little crazy in some windows, browser windows in particular.
Increasing the focus area, or increasing the size of the controls would help.
I wonder if lowering the display resolution might improve things any?
It's probably, not worth the loss in desktop real estate though.

73, Jay - NO5J
.  

Jay Nation

Coincidentally, right after I clicked submit on my last post. A window popped open informing me of todays release of new AMD Radeon video drivers "Crimson Edition" which are finally optimized for Windows 10 64 bit. 

So yes, I immediately installed them.

This new video driver might be the game changer I've been in need of. Now I'm not stuck with running drivers optimized for Windows Older 64 bit.

Likely won't help with the slider focus area problem, but hopefully they won't make things worse.

They aren't beta drivers either.

Wish me luck while I'm test driving!

73, Jay - NO5J

Tim - W4TME

I have entered this problem report into our bug tracker for additional investigation. Thank you for the defect report.