|
|
Comments and Discussions
|
|
 |

|
Very poor and sloppy coding. No conventional code practice was followed. Code is a really bad representation and usage of our beautiful VB.Net language.
I have yet to figure out, what, are developers trying to save electronic 'paper' when they force all classes into one file?
Keep in mind that there are Visual Basic Coding Conventions[^]
The goal of the .NET Framework design guidelines is to encourage consistency and predictability in public APIs. It is strongly recommended that you follow these design guidelines when developing classes and components that extend the .NET Framework and attempt to instruct others in the VB.NET language.
Please take some time read/download/print Brad Abrams blog on "Design Guidelines, Managed code and the .NET Framework". Design Guidelines[^] Yes, its in CSharp however, the basic design principals are global. Good luck and happy coding in the future.
modified on Thursday, December 17, 2009 6:25 PM
|
|
|
|

|
I downloaded and modified this for Framework 2.0 ChecklistboxRO control, and found the code was documented just fine and was easy to follow. Although this is a small project, I actually think it is a good idea to group similar supporting classes into a single file, despite what the guidelines may say.
The author should be commended for making this contribution to the community. Good job and keep up the good work!
Chris (another lonely programmer!)
|
|
|
|

|
Thank you much for your opinion, It moved these dead waters a bit Actually I ran across Design Guidelines for Developing Class Libraries[^], especially this chapter[^], and I found lot of interesting insights!
What I have concluded from article GuideLibs\GuideType\Nesting[^] is, that it's generally not good to nest types. But this "generally" is very pretty general, and may be confusing in this context.
Quotes:
- Do not use public nested types as a logical grouping construct; use namespaces for this.
- Avoid publicly exposed nested types. The only exception to this is when variables of the nested type need to be declared in rare scenarios such as subclassing or other advanced customization scenarios.
- Do not use nested types if the type is likely to be referenced outside of the declaring type. ...For example, an event-handler delegate that handles an event defined on a class should not be nested in the class;...
- Do not define a nested type as a member of an interface. Many languages do not support such a construct.
So what? If you check point 3, part in italic, you can reconsider and reconsider if it is right or not to nest EventArgs in their "producer". You can reconsider it infinitely even if you focus on this case.
By my opinion, some of EventArgs classes should really rather occupy another level, Support.cControls in this case, because they can be reused. I didn't really thought of such possibility when writing first nor second version of article and code. I will surely make some of stylistic updates arised, but until I'll ship my whole library as a framework, it has no importance at all to. That's also because nested EventArgs classes seems much advanced, nested delegates - they may be more advanced than those EventArgs, and finally, because this article provides also code, and anyone who took some time to read text, comments and feedback threads, will know what to do with code, if it's needed to be absolutely correct (just changing EventArgs, de-nesting subset or all of types, more commenting).
I don't know what is to be considered poor and sloppy. Actually this nesting seems, with my fresh new knowledge (thanks MSDN), not big issue in local circumstances. I still have doubts about correctness of that Reflection mechanism, but that's because I didn't try to extend it yet (so it can cause issues when extending). And I know, that with introducing DoDragDrop ('external drag drop') support I probably let some trash in code, and that it can go, at least, under formatting revision. But in this development phase, I don't think it needs to have absolutely correct code-style.
Maybe it can be told, that every code, in any phase should be absolutely correct and stylish. But that's not true in any moment. If I start to write function *, I may recomplex subsequent situtations in code in number of times, still modifying used types, buffers. Concept of implementation evolves hand in hand with writing code. And this moment - writing method - can be, in the same manner as presenting and developing this article, decomposed to many garbaged and ungarbaged, correctly-formed and malfunctioning at the moment.
If this article was closed for discussion and updates, situation would be bit different. But I tend to extend the code, if there is any feature request.
Currently it does its work, maybe it can do more...
Thank you for your revision and support again, and I hope I didn't bored you to death (just one joke for such Piece(Of Theory)
Best wishes, Matt
* its interesting that I do this usually from top of method-body container to its bottom - but think about it, we all cast as being good programmers, in some way, but noone of us is able to write complex function in direction from return to arguments ... shame on us!!!
modified on Thursday, December 24, 2009 11:32 AM
|
|
|
|

|
Lonely loner, on the lonely road ... alone
|
|
|
|
|

|
There's a bug (with no consequences at all). If you mind, you may rewrite CancelDrop `e` type to CancelDropEventArgs. It accidentally stayed EventArgs from initial design. This relates to mistaken info in this article on this event. This event also informs you, that DragDrop you already handled is not external, what is basically thing not described in this version of article, and what is also indicator you can't use until you rewrite event declaration for proper type. Event comes when data was empty,OR was not converted, OR DragDrop was cancelled, OR DragDrop was just internal reordering accidentally leaving control as DragAndDrop for a while. This last option is indicated by e.ReorderCancelled property. I will include this new information with improvements to behavior and look (if any look improvements) Maybe I could make insertion line also horizontally customizable ).
I am opened to discussion
Matt
|
|
|
|
|
|

|
hm, but you initiate scrolling when almost on border. this maybe requires enumerator behavior selection to be exact. because I start scrolling in specified inside area, and only for no dragdrop I let it scrolling inside when mouse is outside.
|
|
|
|

|
I set it up this way so you can change the scroll speed by Dragging the cursor futher and closer to the control.
|
|
|
|

|
Yeah, I see. But what happens when you need reorder listview in fullscreen mode?
|
|
|
|

|
The scroll triggers before you are totaly off the control, so it will still scroll. Plus I didn't expect the control to be right up on the edge of a window there is usually some kind of border area.
|
|
|
|

|
And always there is a chance to use wheel, isn't it? You are true, but I am used to count with all possibilities, if they are really possible. But I will have to adapt your idea, it will solve my problems when listview is shrinked unbelievably. I will implement that as behavior change on resize. Also I am sure I will adapt your scrolling cursor, it is one of very usual features which I can adopt from your project with no changes or generalizations to it. Thanks! You'll be in credits, if you mind.
|
|
|
|

|
A have code updates, but I don't know how to modify this article . Any idea?? Thx
|
|
|
|

|
I think you have to send codeproject the updated code and article. I normally send my updates to submit@codeproject.com. They will then update the article for you.
Anthony
Check out my desktop conversion software for Windows -
www.universalconverter.net
|
|
|
|

|
Ah, thank you.
|
|
|
|

|
I didn't try your code, but I adopted BottomItem property from your class and it returned null when listview had few items or it was scrolled all the way down. So here's a small change:
public ListViewItem BottomItem
{
get
{
return GetItemAt(0, DisplayRectangle.Bottom - 1) ?? Items[Items.Count - 1];
}
}
|
|
|
|

|
Thank you for your attention. I will proceed necessary updates to code and include you to contributor comment, if you mind. Best regards, Matt.
|
|
|
|

|
I've run your demo and that thing with BottomItem doesn't seem to affect your code behavior. Instead i've noticed some other issues. Using mousewheel when dragging results in insertion line being drawn without being erased. And it seems strange to me that dragging items over the bottom of the list is way slower than dragging over top.
|
|
|
|

|
I also noticed that scrolling continues when mouse leaves the list. It doesn't react on mousemove, though it stops on mouseup. I encountered those problems and my first attempt was to hook all events, but then i realized that scrolling should stop on dragleave because user probably wants to drop the items somewhere else and not to change their position in the list.
|
|
|
|

|
Hi. I have no access to this content already (I have no idea why). You can find all your feature requests and bug reports heard here http://quilt.ic.cz/tmp/devfus/ListViewRo.zip[^]. If you have any idea how to edit this page, let me know. Thanks for all your deep analyze
|
|
|
|

|
You can check out article and files now. It is even more different than file I linked in my last reply. Cheers; PS: sorry for not fullfiling your concept of BottomItem, and going with LastVisibleItem standing for previous version's BottomItem and BottomItem doing still the same stuff. If you have better point in this convence issue, let me know. PSII: I still didn't checked speed difference you issued. PSIII: thank you for moving me forward in this project!
|
|
|
|

|
Good detail in your article. Learned something from it.
cheers,
Donsw
My Recent Article : Backup of Data files - Full and Incremental
|
|
|
|

|
Thank you very much for this!
Anthony
Check out my desktop conversion software for Windows -
www.universalconverter.net
|
|
|
|

|
Anyway, didn't we met at msdn once? Regards, Matt
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
Inherited ListView which enables user to order multiple items by mouse, and automatically scrolls if necessary
| Type | Article |
| Licence | CPOL |
| First Posted | 30 Aug 2009 |
| Views | 22,189 |
| Downloads | 485 |
| Bookmarked | 24 times |
|
|