tonyt wrote:

I was a little confused by your original question

Me too! :) Thanks for the summary, but I finally understood all that! You get my 5 for careing that much.

All the best, Martin

Rob Philpott wrote:

That's one approach...

Which is nice, apart from the fact that you are not .Dispose() the GraphicsPath and Pen instances you created.

All the best, Martin

Hello, If you really unregister all the events (and I'm sure you do) I think you do not have a memory leak at all. It's just, like you found out, that you hold a lot of your chunk objects because of the recurse calls. This forces the GC to move the objects in a next generation. If your action is done, and no more new objects have to be created, the GC will not see the need of cleaning up the generations. I would assume, that if you start that action again (in the first implementated version), the 500Mb will not be topped, unless you haven't forgot to unregister the events or holding the objects in an collection for example! Here[^] is an article, which explains how the GC passes the objects threw the generation levels!

All the best, Martin

Hello, I followed the discussion and have a wild guess now!

Eduard Keilholz wrote:

The code does something with each chunk and then fires an event which tells the chunk is complete. The event handler then calls a method to start processing the next chunk.

If you are referencing this chunk, from an object which also holds the event ... And if you now register (subscribe) this event for every chunk from your "managing" class and not unregister (unsubscribe) after complete ... Your "managing" class would hold all the references to the objects which hold the references to the chunks and therefor the GC would not be able to free your objects. Just a wild guess! Hope you find it. P.S.: I'm sure with this[^] memory profiler you will find it quickly!

All the best, Martin

modified on Thursday, January 21, 2010 5:46 AM

<> wrote:

okay fine i will take up ur advice of using cmd.Dispose();

:thumbsup:

All the best, Martin

Hello again! Apart from the solution I provided, I would like you to know, that you should take care about the ressources used by the OdbcCommand instances.

<> wrote:

cmd = new OdbcCommand...

Here you are instanciating allways a new OdbcCommand in a nested loop, and do not care about the ressources. The OdbcCommand[^] derives from System.ComponentModel.Component[^], which does not implement IDisposable but provides a Dispose[^] method, you should call (cmd.Dispose();).

All the best, Martin

<> wrote:

Hurray!!! it worked.... Thank u.. Million thanx.. Now my application is fully finished one.. once again thank you

Wow, I'm really glad I could help!

All the best, Martin

Hello,

<> wrote:

thanx but genericlist can be used in Dotnet framework 2.0 but im using VS2003 on framework 1.0

that's true!

<> wrote:

can i make use of array.. but the problem is i am not very much strong in arrays.. Do please guide me.

Sure! instead of generics, you could use the StringCollection class, which is available in .Net 1.x:

using System.Collections.Specialized;

...
StringCollection fileNames = new StringCollection();

StringCollection, does also provide a Contains and a Add method, like the generic list. Hope it helps!

All the best, Martin

Hello, You could hold your outputed filenames in a list and make a lookup in the list bevor you do the next output. Like this (using a generic List):

List<string> fileNames = new List<string>();

string f_FileName = ...;
...
// foreach ...
if (!fileNames.Contains(f_FileName))
{
fileNames.Add(f_FileName);
Console.WriteLine("Please check Function file-{0} fields do not match", f_FileName);
}

Hope it helps!

All the best, Martin

Hello, Just came across your interesting question. If I got it write, I think you need to deal with inherited controls and a customzied property editor. I will try to give you an idea of how you can solve your problem, but will not sneak into the time costing details (I will mark them for you).

ArjenGroeneveld wrote:

like to create a Label control

What you need first is a custom label which derives from Forms.Label.

public class LabelExtended : System.Windows.Forms.Label
{
...
}

ArjenGroeneveld wrote:

One the respective control is set in Design time,

To make it easy (for me), I will use a string property to hold the name of this selected control (how we do this will be next).

private string selectedControlName = string.Empty;

[
CategoryAttribute("Arjens Properties"),
DescriptionAttribute("Holds the name of the selected control."),
DefaultValueAttribute(""),
EditorAttribute(typeof(SelectControlEditor), typeof(UITypeEditor)) // this is the key
]
public string SelectedControlName
{
get { return selectedControlName; }
set { selectedControlName = value; }
}

ArjenGroeneveld wrote:

an property in which I can select the available controls on the Form (except for the Label controls).

We just added an EditorAttribute to the property. This is a type of SelectControlEditor and derives from UITypeEditor, which we have to create now.

using System;
using System.Windows.Forms;
using System.Windows.Forms.Design;
using System.ComponentModel;
using System.Drawing.Design;
...
public class SelectControlEditor : UITypeEditor
{
...
}

What I want to show you is a DropDown editor, where you are able to select a control out of a list of control names. First we give the editor class the information about the DropDown, by overriding the GetEditStyle method like this:

public override UITypeEditorEditStyle GetEditStyle(ITypeDescriptorContext context)
{
if( context != null ) return UITypeEditorEditStyle.DropDown;
return base.GetEditStyle(context);
}

Now we need to tell the editor how to edit your property, by overriding the EditValue method.

public override object EditValue(ITypeDescriptorContext context, IServiceProvider provid

ArjenGroeneveld wrote:

Thank you for your quick reply and solution!

Glad I could help!

All the best, Martin

Hello, The ToolStripButton class doesn't Inherit from Control. Inheritance Hierarchy: System.Object System.MarshalByRefObject System.ComponentModel.Component System.Windows.Forms.ToolStripItem System.Windows.Forms.ToolStripButton So you have to look for the ToolStrip class (which inherits from Control) an than iterate over the Items property. Like this:

foreach (Control c in this.Controls)
{
if (c is ToolStrip)
{
ToolStrip ts = c as ToolStrip;
foreach (ToolStripItem tsi in ts.Items)
{
ToolStripButton tsb = tsi as ToolStripButton;
if(tsb != null)
{
...
}
}
}
}

Hope it helps!

All the best, Martin

Glad I could help!

All the best, Martin

Hello, In your ExpandableObjectConverter you have to override the GetProperties method, like this:

public override PropertyDescriptorCollection GetProperties(ITypeDescriptorContext context, object value, Attribute[] attributes)
{
return TypeDescriptor.GetProperties(typeof(YourClass), attributes).Sort(new string[] { "FirstProperty", "SecondProperty", "..." });
}

Hope it helps!

All the best, Martin

dojohansen wrote:

And since the class didn't implement IDisposable there is a higher probability that objects would not have been disposed.

Second that! I wouldn't like to see such an implementation in my projects as it makes no sence not to implement IDisposable. I just wanted to point to the "SuppressFinalize", also for the cases were you have to worry about your unmanaged recources.

All the best, Martin

Gideon Engelberth wrote:

As an aside, you should not have a class finalizer (the ~A()) method unless you directly own an unmanaged resource such as a file handle stored as an IntPtr. The IDisposable classes you own as fields will have their own finalizer to take care of the unmanaged resources. Having unnecessary finalizers decreases the efficiency of the garbage collector.

I agree mainly as it is a valid information, but he get's around this problem, as he is using:

GC.SuppressFinalize(this);

By calling the "SuppressFinalize", the GC will not move the object to the finalization queue, and so prefent the double lookup of the object.

All the best, Martin

N a v a n e e t h wrote:

You can trust me

;)

N a v a n e e t h wrote:

But if you take a look at C++/CLI's standard, you will not find anything related to extension method. And a search on the web also tells the same.

So true!

N a v a n e e t h wrote:

What it doesn't understand is to look for this specific attribute and show the method as an extension. This is simply because it is not implemented in the compiler.

You know what. I just wanted to ask you rereading the article, but as I was looking over it once again I found out that I completely missunderstood a sentence in the section "Making an Extension Method in C++/CLI". About "ExtensionAttribute": "Applying the attributes to the proper place in the C++/CLI project, I was able to get the extension method to show up" Yes, but only with the C# compiler, and not with the C++/CLI compiler. :doh:

N a v a n e e t h wrote:

It was a good read. Thanks for the link.

It seems, that I learned more new stuff from providing that article, than you reading it! :) With your help, I think I got it now! Thank you! My conclusion about the .Net implementation of extension methods: :confused: :wtf: :(

All the best, Martin

Hello and thank you for taking time!

N a v a n e e t h wrote:

Are you saying that from C++/CLI you are unable to use the extension method like the way you used it in C#?

That's correct!

N a v a n e e t h wrote:

C++/CLI won't support extension method and you can't use it like in C#

I'd like to trust you, but is there a documentation which confirmes your statement? I'm a little confused because of the supportage of the "ExtensionAttribute", which is nicely descriped in tis cp article[^]! Maybe have a short look and tell me what you think about it. Thanks again!

All the best, Martin

Hello everyone. I'm doing some research about the extension methods[^]! I was very critical as I heard about that feature and after some research my doubt, if there is a need for it, is even higher. (But that was discussed so often now, I will not waste your time and leave it open ...) Now my question (proplem)! I did a test, with a solution including: 1) C# project "Provider", which contains a class Foo and a parameterless method DoFoo (all public) 2) C# project "Extensions"(which references "Provider"), containing the extension method

public static void DoFoo(this Foo fo, int inValue) { ...}

3 a) C# project "UserCs" (which reference "Provider and "User") 3 b) managed C++ project "UserCpp" (which reference "Provider and "User") Also another test, with a solution including: 1) managed C++ project "Provider", ... 2) C# project "Extensions"(which references "Provider"), ... 3 a) C# project "UserCs" (which reference "Provider and "User") 3 b) managed C++ project "UserCpp" (which reference "Provider and "User") What happens in both tests now is, that in "3a" I have access to the extensions Method but not in "3b". I know that managed c++ does not provide the syntactic features (ofter heard as "syntactic sugar"), but is aware of the attribute "ExtensionAttribute", which in fact is the base technology of the extention methods. So for me, it seems that the managed c++ compiler can not deal with the build in C# feature, where the extension method is "turned" into a static method which is placed in a static class, all "surrounded" by the "ExtensionAttribute". I know that I'm lacking at the basic knowledge in manage c++, so I'm really looking forwared reading some expert statement pointing out the parts I have missed so far!

All the best, Martin

modified on Wednesday, January 13, 2010 6:57 AM

GWBas1c wrote:

Like I said, I'm deploying on Mono + Linux, so I can't use COM or CLR-specific APIs.

ok, sorry!

All the best, Martin