Click here to Skip to main content
15,904,416 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
Hello CP,

I'm currently in the process of writing a custom control which inherits from the abstract ListControl (the parent of ListBox). Now I'd like to display scrollbars only I don't know how to do it without inheriting from ScrollableControl.

So, how do I add scrollbars without using ScrollableControl?
Sergey Alexandrovich Kryukov 4-Mar-13 14:44pm    
Why without inheriting it? What's the idea? We won't be able to help you without knowing the detail on required functionality.
Groulien 4-Mar-13 14:50pm    
The control has to be exchangeable with the 'ordinary' ListBox (doing this through the parent class) so that users can get used to the new interface but, in case they're confused, can still switch back. All I really need is the SelectedIndex property which they would both share (and I don't like additional type checking for it).
Sergey Alexandrovich Kryukov 4-Mar-13 14:53pm    
Still not clear, as I don't see how it's different from ListBox. All you say tells me that you actually can use ScrollableControl as the base, why not?
Groulien 4-Mar-13 15:00pm    
Current situation has a ListBox of which I use the SelectedIndex (defined by ListControl).
New situation allows the ListBox to be replaced (at runtime) by the new custom control of which I also want to use the SelectedIndex property.
(This new control does behave like a list)
By using the abstract class ListControl, I can switch the two more easily (at runtime).
If I use the ScrollableConrol then I can't refer to the same variable without having to check for its type.
Sergey Alexandrovich Kryukov 4-Mar-13 15:06pm    
In other words, you need to have list-box view and non-list-box view of the same controls (would be good to know what it is, at least, give it a name). The problem is more general. First, does list-view needs to be exact type of System.Windows.Forms.ListBox? or it can be further derived? Can you explain some ultimate goals of it? I feel that I know the solution, but you approach to it from wrong side...

You live too many unknown detail of functionality. I'll try to go in a most general way.

You probably need to have two modes of the same control. One is something like ListBox, but probably is extended, so you may want to use the System.Windows.Forms.ListBox functionality, or create some other control. As on option, you can create just the "list-box-like" interface, implement it, and allow your user to create alternative implementation. The second mode should show some new behavior.

Your problem is not inheriting from ScrollableControl, but inheriting in general.

Here is how you can work around it. You need to create a user control with two child controls: each one representing a separate mode. First, you need to start with defining it's common interface. Each of the two child controls should implement its interface (you already named one member of it — SelectedIndex). And then you may need to extend this interface to two specific interfaces. It's more about the list-box-like control. If you want you parent control class to be overridden by the user, you may add a method IListBox GetListBox(). Then the user would be able to change the functionality of list mode by overriding this method and supplying an alternative child control for this mode. You may or may not need this part of functionality; I fail to understand it from your comment. So, you can have this functionality for one or another mode, all modes, or none, it's up to you, but now you know the idea.

Only one of these two controls should be visible at a time. Mode switch (you should define a enumeration type with two members representing modes, and the read/write property of this type, to switch) should be done by hiding one child control and showing another one.

Now, I suggest you derive your parent control from System.Windows.Forms.Control, and your child controls implemented modes — from whatever you want. If the implementation of those controls can be overridden by the class user, it's not even your concern. You only provide the interface, write your default implementation with the base class you want, and the user can re-implement it using any other base class.

Share this answer
Espen Harlinn 12-Mar-13 17:26pm    
If I'm reading you right you are thinking about something like a popup container edit control.
Sergey Alexandrovich Kryukov 12-Mar-13 17:41pm    
As far as I understand, DevExpress in not open-source; that's the only problem. Such "double-mode" control can be well implemented from scratch. If needed.
Thank you,
What about overriding
protected virtual CreateParams CreateParams
  get {...}

You can then modify the Style as needed

WS_HSCROLL has a value of 0x00100000L
WS_VSCROLL has a value of 0x00200000L

Window Styles[^]

Best regards
Espen Harlinn
Share this answer
Sergey Alexandrovich Kryukov 12-Mar-13 17:06pm    
You see, I think the problem is different. I tried to argue that OP actually needs to use ScrollableControl, not get rid of it; I basically explained some ideas (OP's requrements were vague, that's the problem), so OP does not actually want what she/he thinks she/he wants. Using CreateParams and Windows-specific constants always can become a source for some incompatibility, should be avoided by all means. Pure .NET solution should work...
Espen Harlinn 12-Mar-13 17:23pm    
Overriding CreateParams and modifying the Style property is how you add scrollbars to controls when you use Windows Forms. This is exactly how he did it with Delphi too. Windows Forms and VCL are so similar I find it strange that the similarity isn't mentioned more often.

If I'm reading OP right, he should be using WPF which is more flexible, not Windows Forms.
Sergey Alexandrovich Kryukov 12-Mar-13 17:39pm    
I know, but CLR is isolated from native OS API. In a ported CLR, your low-level code may not work, that's why it's the best to avoid it...
Espen Harlinn 12-Mar-13 17:43pm    
The Style stuff is implemented in Mono too, they found it easier to simulate many of the 'native' windows elements.
Sergey Alexandrovich Kryukov 12-Mar-13 18:11pm    
I know; even some Window messages are simulated, so such Windows-specific, say, message IDs can probably be used on Mono. So actually your code might work even on Mono, I'm not sure. I would be very carefully with anything defined in Windows API and not defined in .NET FCL, isn't that reasonable?..

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900