SquireBum
The Draw tool turns into a single-headed pointer Arrow (Select tool appearance) when it approaches the controller handle and performs no function at all.  The Smart tool turns into a double-headed vertical arrow when it approaches the controller handle.

Okay, I was addressing the OP's issue with the Smart tool. Yes, the Draw tool changes to a pointer momentarily as you cross an existing controller value. The way I see this is that it's telling you there's no point in placing another controller at the same - or nearly the same - value.
 
But I'm not seeing a problem of the severity you're describing. I'm able to easily get single-value resolution with the controller lane at ~1/2 of full dock height, and no more than 3-4 values with a typical lane height of 1-2". I don't see your "whopping 10% of the usable resolution" increments until the lane is down to ~1/2" where you probably wouldn't be trying to work at high precision anyway.

brundlefly
I don't see your "whopping 10% of the usable resolution" increments until the lane is down to ~1/2" where you probably wouldn't be trying to work at high precision anyway.

 
No problem.  I'll just strikeout the line that contains the "whopping" opinion in my post.  The rest of the post is fact based on my system with a 1280 x 1024 screen.
 
-- Ron

On my system, in PRV controller pane, there's a range of 7 ticks in a normal sized (largish, expanded for controller management) pane where the grab function grabs; it's not so much getting precisely at 1 above or below, it's that I never want to grab, and yet anywhere near the existing value, the smart tool grabs and the draw tool refuses to start drawing.   There is NO TOOL that allows draw without grab!      The inline prv grabs too, though it seems to allow closer approach; selecting a controller to view in that area gives a drop down list that on my project is about 100 elements long ... a bit much for selecting one controller (because each controller for each damn midi channel-as-understood-by-sonar is listed).    And while Anderton's picture shows nice curves independent of each other, that's not what my tracks look like:   there is a great deal of overlap, so it's nearly impossible to tell what's what in the inline prv with multiple controllers viewed.    Hence: better PRV controller pane, please.    The whole notion of grab for controllers is flawed, it should be a special function: I have so often messed up earlier settings by accidental grab, and have no way to know without lengthy research what the original value should have been (undo isn't informative enough to say WHICH controller change was the erroneous one). 

williamcopper
And while Anderton's picture shows nice curves independent of each other, that's not what my tracks look like:   there is a great deal of overlap, so it's nearly impossible to tell what's what in the inline prv with multiple controllers viewed. 

You can isolate the view to a single controller; and with multiple controllers, the edit filter means that you'll affect only the chosen controller.
 

williamcopper
On my system, in PRV controller pane, there's a range of 7 ticks in a normal sized (largish, expanded for controller management) pane where the grab function grabs; it's not so much getting precisely at 1 above or below, it's that I never want to grab, and yet anywhere near the existing value, the smart tool grabs and the draw tool refuses to start drawing.   There is NO TOOL that allows draw without grab! The inline prv grabs too, though it seems to allow closer approach.

With either view, you can get within 1 value without grabbing. If you want to continue drawing a controller and not have a discontinuity, that's why the grab happens when there's a 0 pixel differential. I don't see the problem of not grabbing unless there's a 0 value differential. However I do see the problem of needing a high track height to make this comfortable, which is why I recommended the inline PRV as the main PRV won't let you do that with lots of controllers..
 
Whether or not this is exactly what you want with the main PRV, you're not going to get a revised PRV tomorrow. I'm not telling you you're wrong to want what you want, merely offering the suggestion that if you work with the inline PRV as described, it should make matters much easier for you once you get the hang of it.

Anderton

williamcopper
On my system, in PRV controller pane, there's a range of 7 ticks in a normal sized (largish, expanded for controller management) pane where the grab function grabs.

With either view, you can get within 1 pixel without grabbing. If you want to continue drawing a controller and not have a discontinuity, that's why the grab happens when there's a 0 pixel differential.

Does "range of 7 ticks" mean ±7 controller values or ±3.5? In my case, the "dead zone" is certainly more than ±1 monitor pixel, but with a "largish" controller lane, it does get down to ±1 controller value.
 
I could see reducing or eliminating the Draw tool's dead zone, but I think the differing behaviors of the Smart tool (move/adjust existing controllers) and the Draw tool (enter/erase controllers) make sense.
 
In any case, any change will need to be proposed in the Feature Request forum if it hasn't already.

First, in my previous post I meant "value," not "pixel." Sorry about that, I went and corrected my original post. I should never post before morning coffee 
 

williamcopper
There is NO TOOL that allows draw without grab!

 
That's not true, you can use the Draw tool to draw controller envelopes in the inline view (or use the Smart tool for when you do need to grab and continue drawing without discontinuities). 
 

williamcopperSelecting a controller to view in that area gives a drop down list that on my project is about 100 elements long ... a bit much for selecting one controller (because each controller for each damn midi channel-as-understood-by-sonar is listed)

 
When creating an envelope, you can just type in the controller number you want, choose the MIDI channel from the drop-down menu, and it's created. After the envelope is created, SONAR show the active envelopes in bold when making a selection with the edit filter, and places all active controllers at the top of the menu.
 

 

williamcopperAnd while Anderton's picture shows nice curves independent of each other, that's not what my tracks look like:   there is a great deal of overlap, so it's nearly impossible to tell what's what in the inline prv with multiple controllers viewed.

 
Referring to the picture above, the envelope you want to edit displays as a color; the others are black, in the background, and cannot be edited due to the edit filter selection. So it's very easy to see the envelope you want to edit, and it's also impossible to edit the wrong envelope, unless you select the wrong envelope accidentally from the drop-down menu.
 
Note that if you've already created controllers in the PRV, with the drop-down menu under Clips you can convert them into Envelopes and continue working on them as envelopes.  
 

williamcopperHence: better PRV controller pane, please. The whole notion of grab for controllers is flawed, it should be a special function: I have so often messed up earlier settings by accidental grab, and have no way to know without lengthy research what the original value should have been (undo isn't informative enough to say WHICH controller change was the erroneous one).

 
Don't know if there's already a feature request on this in the appropriate forum but you can certainly start one - just be specific in how you define "better" and the changes required to implement that. For now, the bottom line is there are three very different ways to deal with controllers, and it appears to me like you're currently using the option that's least suited to what you want to do.
 
The main disadvantage of using a track's inline controller envelope compared to the main PRV is you need to select the controller you want to edit from the Edit Filter's drop-down menu; you can't just go to a strip and start editing. But the Edit Filter is also what makes a specific controller so readily visible and locks out other controllers for editing (and showing the active controllers in bold makes selection pretty simple).
 
Another advantage is if you really want to get detailed, you can create smooth curves between envelope points - a very quick way to create crescendos and decrescendos.

I used the Controller lane in piano roll without CC value grap since 10 years, and I have to entirely change my working method in new sonar. In my opinion, users has verious working mathod, and I think developers way that remove Value handle on/off option is wrong. Just, I'm early adopter in my contury, maybe I could adapt using inline controller, but my friends does not use new sonar because of this issue.

I understand it's tough to change habits and "muscle memory," but I thought it was great when SONAR added in-line track editing so I then had three choices of how to do controller editing. I choose whichever method is appropriate. For one or two controllers - main PRV. To see a PRV-type display but one where all the waveforms are in the same plane so the timing relationships between them are obvious, and to have nice high view instead of narrow strips - in-line PRV. For very complex situations where are tons of controllers, converting them to envelopes is really efficient. To me, it's always worth being confused for a day to two to save weeks over time. As the French would say, "Reculer pour mieux sauter."

Thank you for your kind reply.
I tried track's in-line mode, but draw tool still does nothing to do in grap area. I think It's just a bug of PRV.

And I'm generally use one or two controller, the in-line controller is just same as Hide Controller Pane mode in piano roll as for me. But that mode couldn't edit notes and CC value as the same time, I concluded it can't upstep my working efficiency.

It's wonder why they don't fix this ridiculous bug. I just have to use piano roll after extend the controller pane too much until they fix the bug. It seems many people requested about the PRV bugs, but cakewalk has not give attention.