|
That's incorrect, GC.Collect forces a collection immediately.
|
|
|
|
|
It won't give you the list of remaining objects, but it will force the GC to cycle through a collection. However, it is almost always a bad idea to call GC.Collect() yourself as it puts an undue burden on both your app and the GC.
Whenever the GC runs, it actually freezes the main thread of your application for the duration of the GC cycle. Making your own calls to GC.Collect() will end up causing more context switches and thread freezing/thawing than would otherwise occur and will actually end up hurting performance.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Scott Dorman wrote: It won't give you the list of remaining objects
Since it returns void and accepts no parameters I knew that.
Scott Dorman wrote: Whenever the GC runs, it actually freezes the main thread of your application for the duration of the GC cycle
and I'm clear with that too.
But I use for testing purposes GC.Collect. The question is how can I realize a list
like some memory profilers do? Not as detaliated but just the actual situation of some objects (if they still exists).
I don't know how too explain more clearly. Anyway I'm playing with a memory profiler to see the allocations/gc's.
|
|
|
|
|
Zoltan Balazs wrote: But I use for testing purposes GC.Collect. The question is how can I realize a list
like some memory profilers do? Not as detaliated but just the actual situation of some objects (if they still exists).
I don't know how too explain more clearly. Anyway I'm playing with a memory profiler to see the allocations/gc's.
I think using the memory profiler or looking at the various .NET related performance counters will be your best bet. I'm not sure how you would actually accomplish what you are after...obviously there is a way as the profilers are able to do it, but it is certainly not a trivial task.
-----------------------------
In just two days, tomorrow will be yesterday.
|
|
|
|
|
Zoltan Balazs wrote: Is there a way to find out what reference is keeping alive an object after garbage collection?
Not really.
Do you think that you have an object that is not collected? How have you come to this conclusion then?
Do you think that there is a reference somewhere? It doesn't have to be a reference that keeps an object from being collected. Perhaps the garbage collector just didn't collect the specific heap generation that contains the object.
If it's a large object (>85 kiB), it's allocated in the large objects heap. that heap never shrinks, even if the objects in it are collected. If you are monitoring memory usage, you won't see a direct change.
If the object has a finalizer, it will survive at least the first garbage collection, as the object has to be finalized before it can be collected.
---
single minded; short sighted; long gone;
|
|
|
|
|
Guffa wrote: Do you think that you have an object that is not collected?
Yes.
Guffa wrote: How have you come to this conclusion then?
I have an application in .Net 1.1. and reading through some articles regarding weak delegates
(like this one "Observable property pattern"[^]. I also did a couple of test in my app and there were indeed leaks.
However there is something that I don't understand: I'm using a class for representing a standard window to the user when there is something long going on. This class is instantiated in other classes and disposed after it is used. However the memory profiler shows that I have 15 live instances since last GC, but not as much instances of the class that creates it. So I think I have a problem somewhere.
|
|
|
|
|
Guffa wrote:
Do you think that you have an object that is not collected? How have you come to this conclusion then?
Just to complete this thread (and maybe somebody will find this helpful):
- yes there was a memory leak
- I was using a freely available component (VisualStyles linkety[^]) for enabling themes. As it turns out using it prevented all forms that had some reference to it from being fully disposed and garbage collected.
- I downloaded a trial of .Net memory profiler linkety[^] to observe allocations and garbage collections. A nice tool by the way!
Sadly the latest version of the VisualStyles component has the same side effects. I guess I have to remove it from my project.
|
|
|
|
|
I need to assign loop variable value to GroupList Footer member
in foreach loop.
I tried code above but got error
Cannot modify the return value of
'System.Collections.Generic.List<mynsp.reportband.group>.this[int]' because it is not a variable
How to fix this error ?
using System.Collections.Generic;
static class Program {
static void Main() {
}
}
public class ReportBandEntity { public int objcode, foo,bar; };
public class ReportBand {
public List<ReportBandEntity> EntityList;
public struct Group {
public ReportBandEntity Header, Footer;
}
public List<Group> GroupList;
public void GetGroupList() {
GroupList = new List<Group>();
foreach (ReportBandEntity e in EntityList)
if (e.objcode == 1) {
Group g = new Group();
g.Header = e;
GroupList.Add(g);
}
int i = 0;
foreach (ReportBandEntity e in EntityList)
if (e.objcode == 2) {
GroupList[i++].Footer = e;
}
}
}
Andrus
|
|
|
|
|
Your problem is because GroupList happens to hold struct s, instead of class es. The reason why the compiler refuses to compile is because
<br />
GroupList[i++]<br />
returns a copy of the actual struct, because structs happen to be value types. And the assignment of e to the Footer property would happen on the copy and not on the original structure in the list. To solve the problem, you can explicitly modify the copy and put it back in the list. Something like
Group x = GroupList[i];
x.Footer = e;
GroupList[i] = x;
|
|
|
|
|
Soon as I do reflection on an Assembly in a seperate AppDomin. It would appear that it gets pulled into the currentDomain. Does anyone know how i can avoid this?
Basically i just want a list of Types from an Assembly operating in my secondary domain.
Anyone any suggestions?
Rich
|
|
|
|
|
Well, to process the Type instances in the other assembly, your current AppDomain would need to load the assembly anyway. Your best bet is to use standard data types (like strings) to represent the types.
|
|
|
|
|
Hello,
Did I miss something to setup in the following code snippet in order the binding to work correctly with the IDENTITY Column ID? When I try to edit the title field, the grid does not display the next IDENTITY value in the read-only column ID.
Any help appreciated
public partial class frmExpensesList : Form
{
SqlConnection sqlConn;
SqlDataAdapter sqlAdapter;
BindingSource bind;
SqlCommandBuilder sqlCmd;
DataTable tbl;
public frmExpensesList()
{
InitializeComponent();
}
private void frmExpensesList_Load(object sender, EventArgs e)
{
sqlConn = new SqlConnection();
sqlConn.ConnectionString = "Integrated Security=true;" +
"Initial Catalog=Expenses;" +
"Data Source=(local);";
string selCmd = "SELECT ID, Title FROM tblExpenseGroup";
try
{
sqlConn.Open();
sqlAdapter = new SqlDataAdapter(selCmd, sqlConn);
sqlCmd = new SqlCommandBuilder(sqlAdapter);
tbl = new DataTable();
tbl.Locale = System.Globalization.CultureInfo.InvariantCulture;
sqlAdapter.Fill(tbl);
bind = new BindingSource();
bind.DataSource = tbl;
groupsGrid.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCellsExceptHeader);
groupsGrid.DataSource = bind;
groupsGrid.Columns[0].ReadOnly = true;
}
catch (SqlException s)
{
MessageBox.Show(s.Message);
}
finally
{
sqlConn.Close();
}
}
private void btnCancel_Click(object sender, EventArgs e)
{
Close();
}
}
|
|
|
|
|
For those having the same problem:
After defining the columns, and setting the IDENTITY column property "AutoIncrement" to true all worked out!
|
|
|
|
|
All I need to do is to draw coloured points, lines, and text to the screen.
Have I to deal with DirectX/openGL or is there something simpler which fits my needs?
Sorry for my poor english...
|
|
|
|
|
Override the OnPaint method of a form and use the Graphics class passed in the parameters of the function to draw lines, e.g.
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
e.Graphics.DrawLine(0, 0, this.Width, this.Height);
e.Graphics.DrawLine(0, this.Height, this.Width, 0);
}
|
|
|
|
|
Hii all
I have a VC++ DLL that contains a function with the following signature:
int myFunction (const char* pXMLFile, int PageCode, int eNumberConversion);
and i want to use it in c#, after searching the internet i found that i have to use the DllImport and do some data marshaling in order to be able to call this function.
my question is: what is the C# type used for the const char * ??
Thanks
MiNa
|
|
|
|
|
string I would think, it depends more on the attributes applied to the parameter than the type. You can also use the StringBuffer .
|
|
|
|
|
Should a member variable be passed to a private method in the same class as a method argument, or should the method simply call the member variable?
For years, I have passed member variables to private methods in the same class as method arguments. For example, if Public method Foo() calls private method Bar(), and if Bar() uses member variable m_MyVariable, I declare the private method with the signature:
private void Bar(SomeType myVariable)<br />
{<br />
...<br />
}
Foo() calls Bar() as:
this.Bar(m_MyVariable);
In other words, even though Bar() could call m_MyVariable directly, I don't do it. Instead, I create a local variable within Bar() to hold the value.
I've done this to keep my private methods as self-contained as possible, and to make it obvious from the method signature just what the method needs in order to do its job. Arguably, this approach makes it easier to follow the flow of control within the program.
But now I'm not so sure it's such a good idea. I often end up with long method signatures with a half-dozen or more arguments, and I find that I'm passing the same member variables (typically helper objects) to every private method in a class.
So, what do you think? Am I better off passing member variables to private methods as arguments, or should I simply let the methods call member variables directly? Thanks for your input.
David Veeneman
Foresight Systems
David Veeneman
www.veeneman.com
|
|
|
|
|
I'd say you're approach is more "procedural programming" oriented than OO oriented. While your approach has its advantages, I generally prefer to let the private methods be intelligent. My public methods usually do only parameter validation and simple state manipulation and let the private methods handle the heavy work. Private methods "hide" how they accomplish the job - which implies that private methods directly deal with member variables.
Have you tried running one of those code analysis tools (FxCop, VS 2005's Code Analyzer)? I distinctly remember one of them suggesting that methods defined in your style be made static. And it makes sense too, they don't need to interact with the state of the object.
|
|
|
|
|
Thanks--that's very helpful!
David Veeneman
www.veeneman.com
|
|
|
|
|
The whole point of member variables, is that they are there. I would pass them only if I felt I may want to pass something else to the same method at some point. I would never pass them if the code then always relied on the right variable being passed in. The idea is to write self documenting code that others can work on easily.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I raised this issue on comp.object. You can read my original post here[^]. Be sure to read the replies.
At one point, I was using your approach and to an extra step in making my private methods static. My main reasoning is that I didn't like my private methods changing the state of the object. For example, say that a public method needs to call two private methods, one right after the other, in order to perform a task. Say that the first private method alters the state of the object. Also, say that it's possible for the second private method to fail for some reason. If the first method alters state and the second method fails, you will need to revert the state to its earlier, pre-error condition. My approach at the time was to call my private methods, passing them whatever info they needed, store the results of the methods in local variable (to the public method), and finally update the object's state once the private methods have completed.
However, I have fallen out of this practise, if for no other reason than laziness. Most of my private methods can alter state and such. I'm a little uncertain, still, if this is good design.
|
|
|
|
|
Thanks Christian--very helpful!
David Veeneman
www.veeneman.com
|
|
|
|
|
Thanks for your feedback--it's very helpful.
I've gotten sold on changing to the way you are doing it now. What I found persuasive was the argument that private methods are first-class members of an object. The are only private in order to hide their workings from the outside world, not because they are somehow inferior. As such, they should have the same access to an object's state as any other method.
That makes a lot of sense to me. I've just refactored a project I'm working on to remove member-variable arguments, and I think it does simplify the code and make it easier to read.
David Veeneman
www.veeneman.com
|
|
|
|
|
I had write this code
for (int i = 0; i < totalEquipment; i++)
try
{
for (int j = 0; j < sEquip[index].index; j++)
{
try
{
...
bar[j].Size = new Size(length,20);
bar[j].BackColor = System.Drawing.Color.Blue;
bar[j].Location = new Point(xPosition,yPosition);
this.Controls.Add(bar[j]);
...
}
catch (Exception ex)
{
throw new Exception(ex.Message + " " + ex.StackTrace);
}
finally
{
xPosition += length;
}
}
}
catch (Exception ex)
{
throw new Exception(ex.Message + " " + ex.StackTrace);
}
finally
{
yPosition -= range;
}
}
}
The problem is this part which it keep add panel to window form without stoping like non stop looping. How can i stop this error?
try
{
...
bar[j].Size = new Size(length,20);
bar[j].BackColor = System.Drawing.Color.Blue;
bar[j].Location = new Point(xPosition,yPosition);
this.Controls.Add(bar[j]);
...
}
|
|
|
|