|
|
The question is:
How to get current cell type? i got a loop like this:
foreach (DataGridViewRow row in dgv.Rows)
{
foreach (DataGridViewCell cell in row.Cells)
{
String HeaderName = cell.OwningColumn.HeaderText;
}
}
So the question is, how do i get a cell type, for example, is it combobox cell type, or textbox cell type, or button cell type, or checkbox cell type? Or, in other words, do my current processing cell belongs to a column of type DataGridViewComboBoxColumn or DataGridVieTextBoxColumn, or DataGridViewButtonColumn?
thanks
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
Try getting the type of the cell.OwningColumn and see what you get. Something like:
switch typeof(cell.OwningColumn)
|
|
|
|
|
Alright, thanks for the hint.
Actually, it was pretty much straightforward:
if(cell.OwningColumn is DataGridViewButtonColumn) then...
thanks
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
if you're interested in one or two types only, you could use the is keyword to your advantage, as in:
if (cell.OwningColumn is DataGridViewCheckBoxColumn) { ... }
if (cell is DataGridViewCheckBoxCell) { ... }
|
|
|
|
|
Yup, thats it, just figured it out second ago, but thanks
011011010110000101100011011010000110100101101110
0110010101110011
|
|
|
|
|
Is there an easy way to utilize some diagnostic class/method in a manner similar to the MFC ASSERT macro in that I will be taken to the location of the assertion failure in the code while debugging.
This would be more helpful/quicker than trying to embed hints on the location in the Debug.Assert message string. I checked my books and the MSDN documentation but I have not been lucky enough to trip over any alternatives yet.
|
|
|
|
|
The closest you're going to get is to check for the condition using a normal If statement, then call Debugger.Break.
Read up on this page[^] for some ideas to implement what you want.
|
|
|
|
|
O'Well. I guess the call stack details will have to do.
thanks for the response and link.
|
|
|
|
|
That's a good question. It doesn't seem to be a standard practice in .NET unlike in C++, or not that I've seen anyway, and I think that's probably to do with the difference between debug and release not being as clear cut in .NET than in C++. Not even sure if conditional compilation exists.
As suggested you can Debugger.Break, but that's ugly, and if you were to wrap it up in a little function then it would break in that rather than where you want (unless you could inline it out somehow??) The other alternative is just don't do it, just do the check and throw an exception if the check fails - that's more what you see - people tend not to assert the arguments to a function are correct, but throw an ArgumentException instead if they're wrong as an example.
Regards,
Rob Philpott.
|
|
|
|
|
Most of my asserts are more usage based (for changes that might get tossed in years down the road after I've forgotten how things work) but I still got into the habit of inserting them within private and protected areas of the class and putting runtime checks only at the public entry points for performance reasons. Basically following the MFC source code way of doing things.
I agree with you that the Debugger.Break isn't compact enough to tuck into the code without sticking out in an ugly way so I'll probably just adapt and use the Debug.Assert or Trace.Assert.
thanks for the response.
|
|
|
|
|
Rob Philpott wrote: unless you could inline it out somehow??)
The C++ compiler handles macros as a pre-compiler process. And it should be one that is controllable from the compiler.
Thus with some work one can use the C++ compiler as a macro compiler on the front end of any language. One would start with a file named something like 'Test.csx' run it through the compiler to create 'Test.cs' (in the project tree) as a pre-build step.
At least in the past there were also stand alone macro processors.
|
|
|
|
|
Debug.Trace isn't even close to being the same thing. What you really want is Debug.Assert() in the System.Diagnostics namespace.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Oops. you caught me. That's what I meant to type.
|
|
|
|
|
Hi,
sorry for my bud English.
I have to draw up an Forms.panel using a "Graphics" object (objPanel.CreateGraphics). I uploaded my design (graphic DrawLine) and I would "fizzle" because I run this graph by drawing a vertical line near the mouse pointer. Mine is a refresh problem because scrolling the mouse leave the previous vertical lines. I tried with "invalidate (rect)" but I do not redraw the chart below. Can you help me with an example? Is 'possible "to fizz" below the others drawlines and draw on a higher level without losing low level?
Alex
|
|
|
|
|
I think this[^] should help you.
|
|
|
|
|
thanks ... I try this ..
Alex
|
|
|
|
|
It works great!! Thanks a lot!!
)))))
Alex
|
|
|
|
|
You're welcome.
|
|
|
|
|
Your problem is probably caused by not doing all of your drawing in the Panel's Paint event. Do NOT create your own graphics object. Use the one that Windows hands you in the event args of the Paint event.
|
|
|
|
|
thanks Dave, I try to not create a graphics obj ...
Alex
|
|
|
|
|
Drawing a grid on a panel? I just did that a little while ago. Here's a sample that makes a 20-px grid.
private Pen pen = new Pen(Color.FromArgb(60, 60, 60), 1);
private void something_Paint(object sender, PaintEventArgs e)
{
for (int x = 20; x < Width; x += 20) e.Graphics.DrawLine(pen, x, 0, x, Height);
for (int y = 20; y < Height; y += 20) e.Graphics.DrawLine(pen, 0, y, Width, y);
}
[Edit]: Moved Pen object out of method.
|
|
|
|
|
You forgot to Dispose the Pen. Nothing like an example that leaks GDI resources!
|
|
|
|
|
Or even better, don't re-create it on every Paint in the first place. Moved it out of the method.
|
|
|
|
|
thanks to all ..
Alex
|
|
|
|