Windows Form - ListView - Removing lines between columns - c#

I need to display a ListView in WinForms which should not have any lines between columns. I tried GridLines=false and also tried setting HeaderStyle to ColumnHeaderStyle.None. But this is not working. I want to remove the 2 vertical lines coming in the middle.
screenshot http://www.freeimagehosting.net/uploads/4bcee1f639.png

GridLine = False should work. (See Pramodh answer.) If not, you have something else wrong. If you setting this property in code, make sure the control's handle has been created. The method CreateControl and IsHandleCreated are helpful.
A common problem in C# that affects controls is accessing control properties in the form's constructor. Usually, the control handles are not created until they are "visible", which doesn't happen until the form is loaded. Therefore, if setting these properties in the form constructor, move the code to the Load event which is recommended by Microsoft.
Control.CreateControl Method
The CreateControl method forces a
handle to be created for the control
and its child controls. This method is
used when you need a handle
immediately for manipulation of the
control or its children; simply
calling a control's constructor does
not create the Handle.
CreateControl does not create a
control handle if the control's
Visible property is false. You can
either call the CreateHandle method or
access the Handle property to create
the control's handle regardless of the
control's visibility, but in this
case, no window handles are created
for the control's children.

just change the view into Details
and GridLines=false
like:
this.listView1.View = System.Windows.Forms.View.Details;
this.listView1.GridLines = false;

Related

Recommended way to manipulate User Control panels into a Windows From

I just started working with Visual Studio C# and to be honest I didn't fully understand what happens when we chose to hide a form or a user control.
My intuition tells me this hide/show method is kind of "inefficient" way to get an user through all the functions of my app.
So I am asking you guys if there is another workaround to "load" user control parts in a form.
Right now my main_menu form has all the user control objects placed on the form, but hidden, and I am using buttons to show them.
Is there a better way to achieve the same result? (I was thinking of a workaround like having an empty panel where I can load the User Control - not sure if possible)
Thank you!
You can create the controls on the fly and add them to or remove them from the Controls collection. On the class level, define this field
private Control _currentPanel;
You can use a more specific type here, if you are deriving all your panels from a common base type.
Then change the panel with
// Remove previous one.
if (_currentPanel != null) {
Controls.Remove(_currentPanel);
}
// Add new one
_currentPanel = new MyNewPanel();
//TODO: possibly set the panels Docking property to Fill here.
Controls.Add(_currentPanel);
In the example I am working with the form's Controls collection; however, you might have to use the Controls collection of some container control holding the panel.

Load like event in Windows Forms for any control like textbox, checkbox?

In Windows Forms when a UserControl or Form first time becomes visible the Load event is fired.
http://msdn.microsoft.com/en-us/library/system.windows.forms.usercontrol.load.aspx
Is there any such event for controls like Checkbox, TextBox, Label ?
No. You could use the HandleCreated event, it is fired when the native window for the control is created. The first event you can rely on to run after the class constructor ran. It is triggered when the parent adds the control to its Controls collection and the control becomes visible.
Beware however that it this event can fire more than once. Controls may be re-created when certain properties get reassigned, the kind that requires the native CreateWindowEx() function to be called with new style flags. So you'll at least need to carry around a bool flag that keeps track of this.
Also note that setting properties of a control after the native window is created is pretty inefficient. All Winforms controls were designed to allow properties to be set before the native window is created. Whatever code you are generating almost surely should use the class constructor instead. Either of the derived control itself. Or in the code of the parent, much like InitializeComponent() does for a form or user-control.
The same is true for the existing Load event. It tends to be over-used due to the VB6 legacy where the Load event was very important. In Winforms however it is only required for code that depends on the final location and size of a control or form. Which may be different from the design properties due to form scaling. Any other code belongs in the constructor.

A Form(?) appears briefly outside of Form1 when adding a control to it

I have a program which creates new Controls (actually - Form's with TopLevel = false) and puts them on a Panel which is on Form1.
For some reason, this is usually followed by what seems like a Form appearing very briefly outside of Form1. It's hard to tell exactly what's happening because it's so brief. Perhaps it's Form1 moving there (and changing its size) and then returning. Or perhaps it's the Form that's being put on Form1 that appears there (though how could that happen at all? It's out of Form1!).
I couldn't find anything in the code that might cause it, and the whole code is way too long to post here. (The relevant code is simply: MyPanel.Controls.Add(newForm);.)
Is there any known bug that might cause this?
I can sort of guess what the code looks like. The problem with adding a Form to the Controls collection with TopLevel = false is that you have to explicitly make it visible. This is an odd quirk (aka bug), normally a control automatically becomes visible when you add it to a Controls collection.
So it probably looks like this:
var newform = new Form1();
newform.Visible = true; // or newform.Show()
newform.TopLevel = false;
MyPanel.Controls.Add(newForm);
And yes, that can make it visible for a very brief moment, still as a top-level window, if you do something else that causes messages to be dispatched. Fix it by swapping the Visible and TopLevel property assignments.
If this doesn't help then post a code snippet.
So you tried adding a Form to a Form's Controls collection and received the exception telling you that you can't add top level controls. To "fix" it, you set the TopLevel property of that Form to false.
That's not the correct fix.
Use a Panel (or one of its derivatives) instead.

Where should InitializeComponent() appear in code order?

If I create a winForms "myForm" then the following boiler plate code is generated:
public partial class myForm: Form
{
public myForm()
{
//<<position 1
InitializeComponent();
//<<position 2
}
}
If I add extra code to the constructor method does it make any difference to the running of the app if I place my code in position 1 or 2 ?
Yes, it does.
InitializeComponent is the method that VS generates that is responsible for creating and positioning the controls on a form.
Code in "position 1" will execute before the controls exist. If you try to access a control in this position, you'll get a NullReferenceException (say, if you try to set the content of a TextBox). Similar code in "position 2" will work as expected.
There is use to "position 1" though: if you have custom controls or behaviour that rely on properties of your form, setting those properties in "position 1" might prevent that code from having to refresh if you allow controls to be created before those values are set.
Yes. Before InitializeComponent all controls have not been created yet.
in the function InitializeComponent(); you create all of your objects you put in the graphical layout. if you want to access them, your code should be in position2.
The button,textbox,combobox that you put on the Form automatically creates some code.This code is generated in InitializeComponent()
So calling the controls that you put on Form from position 1 is wrong because the controls are never created at that point of code.
You can call and access the controls that you put on the Form from position 2
Like the others here have said, position 2 should be used in most cases. However, there are exceptions where neither of the positions will work, and you will actually have to attach your code to another event.
Example: You have a ScrollViewer and an Image inside it. You insert a big image file in the Image component and want to show it so the center of the image is visible at the start, with an option to scroll around to see the rest of the image:
scrollViewer1.ScrollToVerticalOffset(scrollViewer1.ScrollableHeight / 2);
However writing this in the constructor either before or after InitializeComponent() (or even in) will not give you the result you want. (Because, even though the components have been initialized at this stage, the contained image file has not.) Instead what you have to do, is attach a new Event Handler ImageOpened to the Image and write the command there.

c# when I add control to panel, the control becomes NULL

There are two forms in my project and I am trying to add the controls of Form2's panel into Form1's panel.
So,
Form2 form2 = new Form2();
new_panel = form2.Controls["panel1"] as Panel; // form2's panel
this.panel.Controls.Add(new_panel); // add form2's panel into form1's panel.
And suddenly, the form2.Controls["panel1"] becomes NULL.
I can't understand why it happens.
A control can only have one parent - if you add a control which already has a parent to another control, it will remove itself first.
From the docs for ControlCollection.Add:
A Control can only be assigned to one Control.ControlCollection at a time. If the Control is already a child of another control it is removed from that control before it is added to another control.
If you think about it, that makes sense - a panel needs to know where it is, how big it is etc. It can really logically only be in one place at a time.
As an aside, I'd recommend using a cast rather than as when you're proceeding unconditionally as if the cast has worked - that way, if the relevant object isn't of the right type, you get an exception at the earliest moment of detection, instead of a null reference propagating itself through your system, possibly not being picked up for a long time (making it harder to diagnose the issue and introducing the possibility of data being lost).

Categories

Resources