Simple example: Subclassing of an edit control

[jj2007]

I make good use of the dwRefData parameter.

Right. How would you do this, using dwRefData?

Code: Select all

		#define GWL_USERDATA -21	' missing in Windows.bi
		Dim As Integer charcount=GetWindowLong(hWnd, GWL_USERDATA)
		charcount+=1
		SetWindowLong(hWnd, GWL_USERDATA, charcount)
		Dim chars As zstring*100=Str(charcount)+" characters typed"
		SendMessageA(hStatic, WM_SETTEXT, 0, @chars)

[Josep Roca]

> Right. How would you do this, using dwRefData?

Why should I do that using dwRefData if what I need is the window handle?

I can use dwRefData, for example, to pass a pointer to an structure or a class that contain information that can be useful for my purposes. Depending on which control you're subclassing, you may need it or not. Of course, I can also do it using other techniques, but this one is very straightforward.

If you want to use the old subclassing method it's up to you, but I don't understand that hostility towards a new function that adds some improvements.

[macko17]

I make good use of the dwRefData parameter.

Right. How would you do this, using dwRefData?

Probably the same way. Except it'd be more protected against random changes. You know, since anybody with the HWND can SetWindowLong to change the user data at any time (in any app!). Sure that's not gonna happen in a toy example, but it's a possibility in a real framework because 'nobody ever uses the user/class data'. The dwRefParam in the new stuff is less likely to be changed from underneath you, as it requires two pieces of data to identify and thus modify.

So one such advantage of using the new functions is because it's harder to modify. Whether anybody cares about that or not, I don't know, but it is an advantage