>*snip*
>>For awhile I speculated that we might get them in the 64 bit version when it arrives. However, I've come to the conclusion that this is one of those things that'll never happen. In some respects, it may not be a bad thing. One area that might be hurt is form refreshes. Assume the following:
>>
>>You set LockScreen to .T., issue ThisForm.Refresh to update all the controls, then set LockScreen back to .F. In this scenario, VFP issues a LockWindowUpdate() on the form, updates the controls, then calls LockWindowUpdate again to release the lock.
>>
>>If each of the controls were windows, you couldn't do this. In fact, LockScreen might only be a property for backward compatibility. Windows can only lock one window at a time. This means that each control would have to individually be locked and unlock. Certainly, one, with judicious use of ThisForm.Refresh, might not see much of a performance hit, but there would almost certainly be one.
>
>I'm not sure I understand the problem here. Yes you can only lock one window at a time but that window and all of its child windows are then "locked". No refreshing/painting can occur until after you issue LockWindowUpdate again and unlock the window.

Don't think so. Drop a treeview on a form. The treeview is a child window. However, it does not respect LockScreen = .T. The only way to specifically lock the update is to call LockWindowUpdate() with the window handle of the treeview itself.

>The situation I do see is that if you do issue a Refresh, you are only sending the WM_PAINT message to one window. However, in the situation we are discussing, the WindowProc function would have to propagate that message to all of its child windows. Presumably this is what VB does now when you issue a Refresh.

WM_PAINT isn't sent until after the window is unlocked. But, yes and this is where the performance hit would occur.