OSDev.org

bewing wrote:Then let me say it this way, since you seem to be insisting on being pedantic:

There are not, in actuality, 200 different kinds of events inside a windoze computer. The 200 separate messages overlap in their functionality. They are not exclusive of each other.

Indeed they are, otherwise there would be no case where one message could be received by a window without another message also being sent at the same time. True, Visual Basic does combine things like WM_LBUTTONDOWN, WM_RBUTTONDOWN, etc, but it's not enough to bring the count down below the original stated 200, nor would I consider these messages "redundant" or "overlapping" (unless I'm severely confused about set terminology!)

bewing wrote:Therefore, it is quite possible that an intelligent combination of some 24 element subset of those messages may actually, in fact, comprise a complete set.

This becomes philisophical, but the fact remains that subclassing is so used that it is often confused for processing windows messages at all (see the first few posts here). This suggests the opposite of a complete set of functions.

bewing wrote:Plus, the 24 functions that you refer to are not all methods of the same class of object, are they? So they don't necessarily have to all be the same 24 functions, do they?

I'm not sure what you mean here, they are all methods of a form object.

bewing wrote:I am programming Windoze in C, ATM. In just about every Windoze GUI program I've written in C, I need to subclass the stupid edit windows. I almost never have to subclass a damned thing in VB -- because the VB interface to the API does it all for me.

VB does not subclass anything on its own to attain extra functionality. Chances are you are unnecessarily subclassing something in C.

bewing wrote:In fact, somehow VB manages to create effects that I've never been able to figure out how to recreate in C.

More evidence that you are not doing things correctly in C.

bewing wrote:The problem that I have with VB is that it can take a flawless piece of sourcecode, and make it run wrong every time, or make it run wrong in a random fashion. There are places where you never ever want bugs, and your compiler is at the top of that list.

It's not necessarily that it's buggy, it's just that it tries to be foregiving (unless you're thinking of a specific instance). Always using Option Explicit can help here.

Visual basic does subclass controls under the hood, since the events that you can handle are a superset of that which is sent to the parent, but also contain internal messages for the control (including mouse messages, keypress messages). Whether it always subclasses, or only when you defined the required functions, I won't comment about.

I can't check the details since I'm on linux, but your pendantcy seems to be quite a double standard.

Majority? Please.

Majority of messages that are actually used, fine.
I've actually bothered to open up a list and count them:
66 that are handled in vb (one way or another)
23 indirectly in vb (since they go paired with other messages or things that can be done via non-WM routes)
19 not in vb (of which 17 account for the NC* messages, for which I'm tempted to put in the next category, since UI theory dictates uniformity, and changing the default is not part of that, and vb can do forms without title bars out of the box if you really want that.)
that leaves 92 messages that are not interesting except in very specialized contexts (a rough overview: 8-bit modes are out of fashion, users changing system settings generally only occur in the short phase after installation, you have resolution changes that always go in pairs since tabbing out of directx apps restores the resolution, and the occasional hardware changes - safe eject anyone?)

Yes, these are things I'm saying that subclassing is necessary for in Visual Basic.

Well, apparently they are not. And even if you subclass, you'd do so much less than in C, which was the real point in question

Combuster wrote:Visual basic does subclass controls under the hood, since the events that you can handle are a superset of that which is sent to the parent, but also contain internal messages for the control (including mouse messages, keypress messages). Whether it always subclasses, or only when you defined the required functions, I won't comment about.

For example? Sure you can even write an activex control that subclasses itself to achieve some goal and then that could be a control in VB that subclasses under the hood. But none of the default controls, or even many of the ones that ship with VB6 do this. At least not as far as I'm aware, so, examples?

Combuster wrote:I can't check the details since I'm on linux, but your pendantcy seems to be quite a double standard.

How so?

Combuster wrote:Majority of messages that are actually used, fine.

Majority of ones that you are almost guaranteed to need to use, maybe, but certainly not the majority of ones actually used in the cases that I described several posts back.

Combuster wrote:I've actually bothered to open up a list and count them:
66 that are handled in vb (one way or another)

I'm sorry sir, I've consulted the MSDN documentation for each individual message to find that VB6 allows the programmer to handle only 28 messages. I gave you the benefit of the doubt for notifications that visual basic only lets you handle for specific parameters.

Combuster wrote:23 indirectly in vb (since they go paired with other messages or things that can be done via non-WM routes)

Such as? I'm curious which messages you think are "paired" with each other?

Combuster wrote:19 not in vb (of which 17 account for the NC* messages, for which I'm tempted to put in the next category, since UI theory dictates uniformity, and changing the default is not part of that, and vb can do forms without title bars out of the box if you really want that.)
that leaves 92 messages that are not interesting except in very specialized contexts

Well, since your original figure of 66 handled in VB is wrong, these numbers are not only off, but your dismissal of these messages leads me to believe you have not had any proper training for windows programming. Removing the title bar from the form is not the same as drawing in the non-client area, and it's awful, awful programming practice.

Combuster wrote:(a rough overview: 8-bit modes are out of fashion, users changing system settings generally only occur in the short phase after installation, you have resolution changes that always go in pairs since tabbing out of directx apps restores the resolution, and the occasional hardware changes - safe eject anyone?)

I've written several applications that needed to be aware of any system setting changes. In fact, looking over a project I wrote for a company one summer, I had to subclass a form in order to handle these messages:

WM_MOUSEACTIVATE
WM_ENTERSIZEMOVE
WM_EXITSIZEMOVE
WM_NCHITTEST
WM_NCACTIVATE
WM_NCPAINT
WM_SETTINGCHANGE
WM_NCCALCSIZE
WM_DESTROY
WM_SYSCOMMAND
WM_MOVING
WM_WINDOWPOSCHANGED
WM_GETMINMAXINFO
WM_SETCURSOR

The amount of routines in the actual visual basic form object that I could use? 3: Form_Load, Form_QueryUnload, and Form_Resize.

Did Visual Basic make this very unpleasant as well as present quirks that required an understanding of how visual basic handles these messages in order to make it behave how I needed it to? you bet.

Combuster wrote:

Yes, these are things I'm saying that subclassing is necessary for in Visual Basic.

Well, apparently they are not. And even if you subclass, you'd do so much less than in C, which was the real point in question

So subclassing isn't necessary for docking toolwindows in Visual Basic? May I see your implementation so I can tell you why it's wrong?

I've consulted the MSDN documentation for each individual message to find that VB6 allows the programmer to handle only 28 messages.

Proof wanted.

Combuster wrote:

I've consulted the MSDN documentation for each individual message to find that VB6 allows the programmer to handle only 28 messages.

Proof wanted.

That would be quite a research paper, to cite over 200 MSDN entries, and document Spy++ messages and whether or not a function is triggered in a VB application.

This is the SMART solution, works on cbuilder2009 perfectly.

This is the onKeyPress event of the TEdit component:

if (Key==13) {
doSomething();
Key=0; // <<<<<<------- Wonderful!
}

NO DINGS and NO subclassing needed.

That's very interesting. However, if you have access to individual events, then your cbuilder must be doing your subclassing for you -- because the default event handler does not call any external code before it runs and handles the event completely.
It's surprising that you can modify the VK keycode like that. Typically, keydowns arrive in readonly format as a subfield of LPARAM in a win32 message.