Requirement:
Currently, I have a requirement to present grouped lists of information in an optimized amount of space with the least amount if any scrolling potential. The item presented has a number of subitems hence the need for a ListView or DataGridView control. Items must be highlighted and selectable across all columns of visible data in each item-row. Horizontal and vertical scrolling must be avoided as much as possible.
Problem Issue:
I am aware that ListViews can select and entire row-item across all columns. However, to avoid vertical scrolling at some point, I must wrap to and create a new column of items. One possible approach is to create a new ListView control to the right of the old one when the virtual list size exceeds the visible number of items in the list. Dynamically creating one-to-many list view controls with eventual use of a horizontal scroll bar below them seems like a lot of work. So, I am looking at this "list" property which appears to provide and handle a multicolumn view of data, but only for the first item-column of information; detail information of subitems is not available. So, this begs the question: Can I owner draw a child ListView control containing one-to-many columns of its own in an item-column cell of a parent ListView control The child ListView controls would have the View property set to "Detail" rather that "List" in the parent. Conceptually, the parent would then handling any need scrolling functionality, horizontal or vertical. And, I can have the benefit of a newspaper like multicolumn approach.
Comments:
I suppose with my old C++ hat on, I would be looking for a handle to the item control in the list. I would then create a child ListView control setting its size, properties to include no headings, only one item-row, and multiple columns, and then subclass or attach the child ListView control with its handle in place of the handle to the child item control in the parent ListView control. This assumes that I can get this internal handle. This is not a simple owner-draw paint scenario. This sounds like a custom user-control scenario of some nature.
Questions:
Can I develop this strictly in VC# If not, then managed VC++ .NET
Can I avoid using interop services with PINVOKE Win32 calls to native code
My past experience with C++ and Views usually meant you traded quick implementation with less functionality and flexibility with encapsulated code for access to internal controls, handles and so on.
Are there any restrictions on the number of child controls within another control or window
Years ago, in Windows, the limiting number of child controls capped at 256. Also, I think the limit for items in a list box was at one time 64K items hence the creation of a virtual list box where only a portion of items are kept stored and viewable in the list box control. If so, I assume this would fall on similar lines for a ListView control. In any case, maybe the 32-bit flat memory model abolished some of these restrictions. I also recall a Windows limit on resources of approximately 8096. In my case, it is highly unlikely that my parent ListView control will come new let alone exceed 256 items or child ListView controls.
I would greatly appreciate any UI VC# advice and insight on courses-of-action or direction.
Thanks,
James Sigler
Dallas, TX
ListView.View=List property and owner-drawing within ListView items.
Ram Ram
In .NET C# do same things like VB.NET or C++ .NET. In my own opinion - C# is more natural to .NET than C++. So, don't bother looking for other languages to solve your problem.
P/Invoke required only when there is no way to use .NET provided functionality. In your case ListView, DataGridView, etc. already in .NET - no need to mess with Win32 API.
Windows have restriction - 10 000 window handles per process. Also there is good self restriction - use as less handles as you can. The more controls you create - the more time CPU working. Also managing this stuff is not always pleasant.
About Windows limits that you mention - they extended, but this is again not the reason to overflow system with used handles.
I think ListView with groups are good at the first look, but when I used it I find a lot of little details, that don't make me happy. For example, you can set it to SmallIcon or List view (don't remeber for sure) and get multiple columns, but you will not see subitems (no columns for them). Also long texts can make it hide other items.
DataGridView is more convenient in many cases, grouping can be done by inserting fake rows with custom formatting or by making different colors to the rows backs. But you will not put item titles into multiple columns.
Another way (interesting in fact) is to use WebBrowser control and provide generated HTML to it. But this is more theoretical, because page update and scroll prevention are hard to do best in HTML. In fact here is good to use WPF, but designer still raw (even no delete command) and runtime is still in beta.
If I understand all right - you propose to create ListView with titles and over selected item will be displayed subListView with details This is not good to do, because you will hide other items in list by your embedded control and user still will have something like scrolling.
I think you need split screen on 2 parts: on top (left) part you put ListView with Groups and List/Small Icon or ListBox with mutliple columns. On bottom (right) part you put "details pane" where selection details (subitems) displayed.
BTW, ListView have Tile mode, which can help to display few lines of text for each item. But if you want to save space - this is not for you.
Tola Omicron
I have re-educated myself on Microsoft class views. View classes are generally a wrapper to a lower level control. For example, a ListView control is a wrapper extension to a ListBox control. An MFC CEditView is an extension to a CEdit class, an O-O wrapper to an edit control. Microsoft View classes offer additionally functionality quickly but have the potential to reduce flexibility. I rediscovered that ListView items are edit controls, and they may be subclassed. This allows all windows messages to be trapped by the control not just those originally designated for that type of control by Microsoft. Also, with subclassing, this child control has the opportunity to handle the message first before the message is optionally passed from the child control to its parent. Anyway, none of this really helps me here because my thought was to replace the item-child edit control with another ListView control. This is impossible. Because the ListView is already a wrapper class that is only designed to work with child edit controls. If any scenario were to work, it would have to be lower-level such as with the use of a list box that would have items remapped to ListView controls versus edit controls. I could then write my own view wrapper class, a list box containing items which are child ListView controls. Although nice, this is too much effort. I would probably call this the NewpaperListView control. I do recall years ago something designed or implemented along this line in C++ to obtain a multicolumn format for multi-column data.
The answer, I now believe, is to use create multiple ListView controls side-by-side additionally create or destroyed as needed. ListViews have do have a “List” multi-column wrappable format for items and “Details” format for multi-column subitems which is NOT multi-column wrappable. This latter case is a major drawback for my needs. Underneath the controls, I can add a horizontal scroll bar that appears when the parent window to the ListView control(s) can no longer show all the items in the child ListView control(s) to the user.
I am not sure the web path suits my needs for functionality.
I DO like your suggestion for the split(ter) window. It is right in the ball park for what I have been thinking. What I am designing has to be very fast for the user. So any use of a tree view concept is ruled out for the design.
Thanks for your suggestion.
James