>>Here's the expression, term by term (and simpler one at that - I've noticed that the n and columncount were annulling each other)
>
>>

nWidth=this.width-iif(bittest(this.ScrollBars,1),Sysmetric(5),0)-4

>
>The VMP code also had the "+4" in it. And I don't think you were nulling out anything with the column count as "n" is equal to the width of all columns except the last one. In my case, the numbers came up something like this (which might give a clue to what is going on); I will show the values of the vars before the whole line is evaluated. Here was your original code:
>
>

>nWidth=this.width-n-iif(bittest(this.ScrollBars,1),Sysmetric(5)+this.ColumnCount,0)-4
>

>
>THIS.Width = 519
>n=254 && width of column 1 to 5
>Bittest() = .T.
>Sysmetric(5) = 18
>THIS.ColumnCount = 6
>
>So nWidth evaluated to 237. Original column width was 238 and somehow the VMP code evaluated it to 239 which is what threw it wonky. Having your code run or restoring the manual width I set before their code ran fixes it.
>
>I am not sure why you added in THIS.ColumnCount - is that to handle the fact that there is a 1 pixel wide vertical line between columns?

What I saw as wrong in my code is that the number of pixels reserved for such a line has nothing to do with the existence of the scrollbar. Now I see it's actually two such pixels (i.e. they weren't annulling each other, they were both subtracted - which means two pixels per column). So, maybe the next iteration should be

nWidth=this.width-2*n-iif(bittest(this.ScrollBars,1),Sysmetric(5),0)-4

I wish I needed this for something :). I'm actually using another solution for what I'm usually doing: resizable columns and their widths (and ordering) saved in an ini file, and restored at grid.init. So the users lay out the columns in any way they want and they stay so.