[RESOLVED] The subclass WM messages in the Grid control.

[dreammanor]

I plan to develop a grid control to replace the Farpoint Spread that I've been using for many years. I read the source code of the vhGrid, S-Grid 2.0, LynxGrid and Krool's excellent FlexGrid. These four grid controls all use subclass, but they receive different windows messages(WM_*)

The WM messages used by vhGrid:

WM_DRAWITEM, WM_PAINT, WM_ERASEBKGND, WM_LBUTTONDOWN, HDM_LAYOUT, WM_LBUTTONUP, WM_KEYDOWN, WM_CHAR, WM_MEASUREITEM, WM_MOUSEMOVE, WM_MOUSELEAVE, WM_MOUSEWHEEL, WM_NCLBUTTONDOWN,WM_SETFOCUS, WM_SETCURSOR, WM_SIZE, WM_TIMER, WM_SETTINGCHANGE, WM_DISPLAYCHANGE, WM_NOTIFY

WM_RBUTTONDOWN, WM_MBUTTONDOWN,WM_RBUTTONUP, WM_MBUTTONUP

WM_HSCROLL, WM_VSCROLL, WM_WINDOWPOSCHANGED, WM_STYLECHANGED

WM_TIMER

WM_CTLCOLORLISTBOX, WM_CTLCOLOREDIT, WM_CTLCOLORSTATIC, WM_CTLCOLORBTN

WM_SETTEXT

WM_SETFOCUS, WM_KILLFOCUS

WM_CLOSE

The WM messages used by Krool's FlexGrid:

WM_SETFOCUS, WM_KILLFOCUS, WM_GETFONT, WM_SETREDRAW, WM_SIZE, WM_HSCROLL, WM_VSCROLL, WM_PAINT, WM_PRINTCLIENT, WM_MOUSEACTIVATE, WM_SETCURSOR, WM_SETTINGCHANGE, WM_STYLECHANGED, WM_MOUSEWHEEL, WM_KEYDOWN, WM_KEYUP, WM_CHAR, WM_UNICHAR, WM_IME_CHAR, WM_LBUTTONDOWN, WM_MBUTTONDOWN, WM_RBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP, WM_CAPTURECHANGED, WM_NOTIFY, WM_NOTIFYFORMAT, WM_LBUTTONDBLCLK, WM_MBUTTONDBLCLK, WM_RBUTTONDBLCLK, WM_LBUTTONDOWN, WM_MBUTTONDOWN, WM_RBUTTONDOWN, WM_MOUSEMOVE, WM_LBUTTONUP, WM_MBUTTONUP, WM_RBUTTONUP, WM_MOUSELEAVE

WM_CONTEXTMENU

WM_CREATE, WM_DESTROY, WM_NCDESTROY, WM_UAHDESTROYWINDOW

WM_NCPAINT

WM_ENABLE, WM_MOUSEHOVER, WM_NCDESTROY

The WM messages used by LynxGrid

WM_SETFOCUS, WM_KILLFOCUS, WM_VSCROLL, WM_HSCROLL, WM_MOUSEWHEEL, WM_MOUSELEAVE, WM_MOUSEMOVE, WM_MOUSEHOVER, WM_THEMECHANGED

The WM messages used by S-Grid2.0

WM_LBUTTONDOWN, WM_RBUTTONDOWN, WM_MBUTTONDOWN, WM_ACTIVATEAPP, WM_SETTINGCHANGE, WM_DISPLAYCHANGE
      
WM_NOTIFY

WM_MOUSEWHEEL, WM_VSCROLL, WM_HSCROLL, WM_NCLBUTTONDOWN, WM_NCRBUTTONDOWN

Of these four controls, vhGrid is the best performance, and the primary rendering routine(DrawProc) is triggered only by the WM_DrawItem.

The primary rendering routine(DrawProc) of Krool's FlexGrid is mainly triggered by WM_PAINT, WM_PRINTCLIENT and the UserControl_Paint event.

LynxGrid executes the primary rendering routine(DrawProc) in many places, and the primary rendering routine(DrawProc) is repeatedly executed many times, so the performance of the LynxGrid is the lowest.

In addition, I also read the source code of cwVList and vwGrid (vbRichClient5). the cwList just executes the primary rendering routine(DrawProc) in the W_Paint event.


My questions are:
(1) Is it necessary to use so many WM messages in the subclass of a Grid control ?

IMO, if we don't consider the ScrollBars (because I can use the VB6 ScrollBars), we only need to receive WM_MOUSEMOVE, WM_MOUSELEAVE, WM_MOUSEWHEEL, WM_KILLFOCUS in the subclass-proc. Other WM messages can be completed in the events that UserControl itself carries. Is my thinking correct?

(2) Where is the best place to execute the primary rendering routine(DrawProc)?

That is, where is the best place that can make the primary rendering routine(DrawProc) be repeatedly executed the least number of times?

Is WM_DrawItem the best choice?



Any suggestions and advices would be greatly appreciated.

[LaVolpe]

I'm not familiar with the details of those other grid controls. If any are creating an API window, then the messages subclassed is kinda defined by what that window expects since you are subclassing that API window. Likely reason for many of those paint-related messages being subclassed. If the entire grid control will only be a VB usercontrol, then you can decide what messages you want to subclass since you decide what will be acceptable and what actions would trigger a rendering.

DrawProc should only render visible rows. That routine should be called for various user-actions: scrolling, page down/up, tabbing between rows, searching, resizing, etc. Of course, it would also be called during a refresh action. If not using an API windows, and the usercontrol AutoRedraw is false then you'll want to respond to the usercontrol's Paint event.

Edited: Also note, that you may want to consider just painting a particular portion of a row, due to an immediate change, instead of the whole row. For example, a selection rectangle, highlighting, etc.

May consider the DrawProc having custom event(s) raised to the user so that they can override default rendering?

[Jonney]

10tec sell the source code for iGrid ActiveX so that you can save your life from stress.

[dreammanor]

I'm not familiar with the details of those other grid controls. If any are creating an API window, then the messages subclassed is kinda defined by what that window expects since you are subclassing that API window. Likely reason for many of those paint-related messages being subclassed. If the entire grid control will only be a VB usercontrol, then you can decide what messages you want to subclass since you decide what will be acceptable and what actions would trigger a rendering.

DrawProc should only render visible rows. That routine should be called for various user-actions: scrolling, page down/up, tabbing between rows, searching, resizing, etc. Of course, it would also be called during a refresh action. If not using an API windows, and the usercontrol AutoRedraw is false then you'll want to respond to the usercontrol's Paint event.

Hi LaVolpe, thanks for your detailed reply. vhGrid is very powerful, but it's a bit complicated. I'm studying its code.

http://www.planet-source-code.com/vb...67906&lngWId=1

Edited: Also note, that you may want to consider just painting a particular portion of a row, due to an immediate change, instead of the whole row. For example, a selection rectangle, highlighting, etc.

Yes, I'm going to subclass(hook) WM_DrawItem to repaint partial windows.

May consider the DrawProc having custom event(s) raised to the user so that they can override default rendering?

It is a good idea. Thank you very much, LaVolpe.

[dreammanor]

10tec sell the source code for iGrid ActiveX so that you can save your life from stress.

Hi Jonney, thank you for the information provided. My work has been going on for some time and it will be completed in a few weeks. So I don't consider purchasing the source code of iGrid ActiveX for the time being, thank you.

In addition, I have no stress, programming makes me happy and I like to challenge some difficult things.

[wqweto]

Hi Jonney, thank you for the information provided. My work has been going on for some time and it will be completed in a few weeks. . .

FYI, WM_DRAWITEM is sent by owner-drawn listbox/combos to it's parent. You are barking on a totally different tree here IMO. Reading this thread, I wouldn't be surprised if this project comes out a bit late. (I'm thinking about something like 2 years. . . maybe)

How about making something easier at first to get you familiar with subclassing and usercontrol authoring in general? A multi-column combobox for instance?

Just my $.02 worth.

cheers,
</wqw>

[dreammanor]

FYI, WM_DRAWITEM is sent by owner-drawn listbox/combos to it's parent. You are barking on a totally different tree here IMO. Reading this thread, I wouldn't be surprised if this project comes out a bit late. (I'm thinking about something like 2 years. . . maybe)

Hi wqweto, thank you for your advice. I know that WM_DRAWITEM is mainly used for owner-drawn ListBox and ComboBox, but WM_DRAWITEM can sometimes be used very cleverly for a owner-drawn grid control and vhGrid is a excellent example.

Farpoint Spread is a very powerful grid control and it's almost 10 times more powerful than MsFlexGrid. It might really take 2 years if I implement all the features of this grid control from scratch. In fact, I only need to implement 30% of its features to meet my needs. I've been preparing for this project for a long time. Although I have not yet written a single line of code, I'm confident that the project will be completed within a few weeks.

How about making something easier at first to get you familiar with subclassing and usercontrol authoring in general? A multi-column combobox for instance?

I am actually very familiar with the development of user controls. 10 years ago I used subclass a lot, and I used subclass to owner-draw all MS Common Controls, but I had not been able to solve subclass crash in VB6-IDE, so I removed all subclass code from all my software. Now, I haven't used subclass for 10 years and I've forgotten a lot of knowledge about subclass.

Although almost all grid controls use subclass, each of them has a different handling of WM messages in the subclass-proc. I'd like to find the best solution (simple and efficient).

[wqweto]

Subclassing is like handling events. There has to be some code that is actually rising these events. You cannot handle WM_DRAWITEM "event" if no one is firing it.

If vhGrid is listbox or listview or other common control based, then it makes sense to handle WM_DRAWITEM in response to base control sending this notification to it's parent hWnd.

Otherwise speaking about how you are going to handle WM_DRAWITEM makes no sense, as standard bare window's DefWindowProc is not going to fire it for you at all.

Farpoint Spread vs bound grid controls is a wide topic. Basicly there are two camps when speaking about grid controls -- unbound camp and data-bound camp.

Unbound camp are easy to spot -- these controls always have something like ValueMatrix property where the user can access a cell directly by row/col "coordinates".

Bound grids are much more scaleable as these can be bound to an arbitrary data-source and will fetch only a tiny "window" (a page) of data as much as needed to format and display it to the user. Implementing a proper (complex) DataSource property is a challenge of itself, strongly advise against wasting your time investigating this.

cheers,
</wqw>

[Jonney]

Although I have not yet written a single line of code, I'm confident that the project will be completed within a few weeks.

I am not confident enough, a few weeks is too short for a Grid control. A few years is also not comfortable for most of us.
In Grid market, there're a few players, which means good and reliable Grid control is not easy to do.

[dreammanor]

Subclassing is like handling events. There has to be some code that is actually rising these events. You cannot handle WM_DRAWITEM "event" if no one is firing it.

If vhGrid is listbox or listview or other common control based, then it makes sense to handle WM_DRAWITEM in response to base control sending this notification to it's parent hWnd.

Otherwise speaking about how you are going to handle WM_DRAWITEM makes no sense, as standard bare window's DefWindowProc is not going to fire it for you at all.

Yes, vhGrid is ListView based.

    With tRect
        m_lHGHwnd = CreateWindowExA(0&, WC_LISTVIEW, "", lLVStyle, 0&, 0&, .Right - .left, .Bottom - .top, m_lParentHwnd, 0&, App.hInstance, ByVal 0&)
    End With

Farpoint Spread vs bound grid controls is a wide topic. Basicly there are two camps when speaking about grid controls -- unbound camp and data-bound camp.

Unbound camp are easy to spot -- these controls always have something like ValueMatrix property where the user can access a cell directly by row/col "coordinates".

Bound grids are much more scaleable as these can be bound to an arbitrary data-source and will fetch only a tiny "window" (a page) of data as much as needed to format and display it to the user. Implementing a proper (complex) DataSource property is a challenge of itself, strongly advise against wasting your time investigating this.

Farpoint Spread can be used either as a bound grid control or as an unbound grid control, and I always use it as an unbound grid control.

There will be a DataSource property in my grid control, and the DataSource property will only accept vbRichClient5.RecordSet, so it won't be too complicated.

[dreammanor]

I am not confident enough, a few weeks is too short for a Grid control. A few years is also not comfortable for most of us.
In Grid market, there're a few players, which means good and reliable Grid control is not easy to do.

Yes, grid controls are the most complex controls. The development workload of a powerful grid control exceeds the sum of all Microsoft common controls development workload.

If we use the normal(traditional) ways of VB6 development without relying on third-party libraries, just like Krool does now, then it will take about 2-5 years to develop a Grid control like Farpoint Spread or ComponentOne Spread.

If we use the great RC5, the situation will be completely different. For a developer familiar with RC5.Cairo (such as ColinE66), maybe he only needs a few months to develop a powerful grid control like Farpoint Spread. For Olaf, he may only need a few weeks to complete a similar work (because he always has many clever methods, and his RC5 vbWidgets already includes cwVList and cwGrid)

I'll also use RC5 extensively in my grid control, but I'm not familiar with RC5.Cairo yet and I'm learning it.

I've been using Farpoint Spread for many years and I've written a lot of helper code for this control. These helper codes will be applied to my new grid control. In addition, my grid control only need to implement 30% of Farpoint Spread's features to meet my needs, so it's possible to complete my grid control in a few weeks. Although this is a challenge for me, I like the challenge.

[wqweto]

For Olaf, he may only need a few weeks to complete a similar work (because he always has many clever methods, and his RC5 vbWidgets already includes cwVList and cwGrid)

Why do you think there is no cwGrid widget as of yet, if it only takes a couple of weeks for Olaf?

It takes me couple of weeks just to design a barely usable sockets class for instance. The first version is designed from thin air, with lots of assumption how its going to be used. Then come tests apps and flaws in the design become obvious. Then come dependent projects, other utility classes that are using this base class, more flaws of the original design come up.

Designing whatever API, i.e. method/props that are going to be used by other devs is always hard to do from first try. Needs lots of experience designing good interfaces, needs good portion of humility (API users are not ret*rds), needs couple of iterations to smooth the naming convention only, needs experience from the consumers side too.

cheers,
</wqw>

[dreammanor]

Designing a new product is quite different from imitating a product. It is much easier to imitate a product than designing a new product. I believe that Olaf won't do such a thing.

IMO, there are two goals for RC5 vbWidgets:
1. As a replacement for Windows common controls.
2. Provide sample code for Cairo.

There is no similar product to Farpoint Spread in Windows common controls, so vbWidgets does not have a similar product too.

In fact vbWidgets contains cwGrid, but it is completely different from Farpoint Spread.

[wqweto]

In fact vbWidgets contains cwGrid. . .

This turns my argument 180 degrees :-)) lol

cheers,
</wqw>