I am looking for the best solution to my problem. In short, I need to make a form that looks like an existing piece of paper. This paper is a formular, which you would normally fill out by hand. Instead, this form contains textfields, checkboxes and so on.
The important thing is, that this form shall NOT look like a form, but should look like the paper formular. That means the possibility of background elements, customized textboxes without the white background and black borders, and so on.
How do you achieve this goal in the easies way? Some kind of special technology you could use?
So Arg's object will represent parameters to be passed.
6 Now the problem comes. More the parameter we pass to a function in external assembly, more the memory leaks are there. If we call a function several times, memory leaks grows proportionally (even when that separate app-domain is unloaded).
7 So the reason of these memory leaks is that parameters (represented by Arg class derived from MarshalByRefObject) are not being collected by Garbage Collector (even when called explicitly).
8 Any comment on how can we free objects of Arg (created for passing parameters)? Or is there something that we should take extreme care about while doing stuff like this?
when objects are no longer required yet fail to get collected, the most common cause is you still are referencing them somehow. Maybe you have a collection of Arg instances somewhere, which is growing all the time? A simple Clear() could fix that. Remember, a static class is loaded and initialized on its first use and never relinquished.
The objects that we are creating are purely local to a function. And we don't have even a single global/static variable. So the reason is something else. I guess it has something to do with either Application-Domain or MarshalByRefObject. Something we should take care about them which we are not doing.
I would see stuff like this when I was using mixed (managed C++) code. What I found was that the references to the called DLLs were not being released unless I unloaded them by hand.
So, what you might try is loading the DLLs dynamically in your C# app, then unloading them and setting their references to null when finished using them. Each time a DLL function is called, you might then reload the DLL, but this might help you get rid of your memory leak.
Once an assembly (a .Net dll) is loaded, it cannot be unloaded and so it will remain in application's address space until process's life time. To avoid this we should load an assembly in a separate application domain. An application domain can be unloaded whenever we want and while it unloads, it also unload all assemblies loaded inside it. So problem can not be resolved as you said. But yes, as you said we have mixed code of Unmanaged C++, Managed C++ and C#. Could this mix of code have any implication?
To be 100% sure what the problem is, crack out windbg with the SOS extension for .Net. You can use ADPlus to take a memory dump of the .Net process in question, and then load the dump file into windbg.
The SOS debugger extension is used for debugging .Net memory dumps. Using !dumpheap -stat will show you all instances of objects on the heap. Given an instance handle, using !gcroot <handle> will tell you which thread is keeping the instance alive. Using !clrstack for that thread will show you the stack for that thread, pin pointing the exact code.
These commands are only the tip of the iceberg though, check out Tess Fernandez's blog at http://blogs.msdn.com/b/tess/[^] for help on using windbg for memory leak debugging in .Net.
I have a question about how to handle Thread.Join() and the cases where the thread is updating using Invoke.
The problem is my background thread calls back into a method periodically that uses Invoke() to update some GUI elements. Now, when I call Join() on my background thread (in response to the user cancelling the job and the application waiting for the thread to finish), the whole application hangs as the subsequent Invoke() calls never return because Join() is blocking the caller thread (i.e. my main thread).
Does anyone know how I can get around this? Thread.Sleep() is no use either as I do want the main thread to be responsive and at least handle these UI events. I was under the impression that the message pump was supposed to be active when using Thread.Join()
Why would you need Thread.Join() in your main thread? As I told you recently, the main thread should never take long and should never block. Thread.Join() is OK when one background thread needs to wait on another background thread, you should not use it in the main thrad.
If your main thread needs to know some background activity is finished, use another mechanism; however most of the time, you should not be interested in when exactly the background activity finishes, all you need to do is set a flag that tells it you are no longer interested, which allows it to exit early and tells it not to produce anything anymore (yes, your code now needs to test that flag on every action you don't want to go on).
1. Do not use the Thread class unless you have to, because it adds a lot of complexity (could BackgroundWorker do the job?)
2. I would never use Thread.Join() unless I really had to... What if you just set a flag to notify the background thread about the cancellation and wait for the thread to complete without calling Join()?
Just because you call a join does not mean that the function that you are running is terminated. When calling join, the caller (in your case the background process) will block indefinetly as long as the thread has not terminated. If the thread is completed, then the join method will end immediately. To fix your problem, ensure that you are exiting the function that is running in the background thread when the user 'cancels' the request.
As others have said, I also recommend the BackgroundWorker, b/c it works very well and was designed to be used in conjunction with a UI. I'm curious, however, why you need a background thread at all if you do not want your GUI to be responsive. You could just do everything in the main thread if you don't want the GUI to be responsive.
Also, have you considered setting Enabled = false on controls you do not want the user clicking (since you don't want them messing with things). An easier mechanism is to put controls in a panel (or container) and set Enabled = false on the panel (or container). This way the GUI is still responsive (no stupid white "not responding" window) but the user can't update / click fields either.
Hope this is the right place to post this issue. If not, please let me know the right place.
I'm using Visual studio 2008. I'm trying to create setup file for my application. In File System properties, while adding a shortcut on User's desktop it is not showing any dialogue box to choose the exe from "application folder".
I continued ignoring that dialogbox and installed the setup. I found a shortcut icon on desktop. On clicking that it opened Desktop folder.
Please let me know where I missed. Thanks in advance.