|
Hello,
I need some help for this problem :
My mainform call a modal dialog, which contain a listbox, a multiline text field and a timer.
When user select a line in the listbox, the timer fire. His job is to fit some text ( string var ) into the textbox.
PB : this work fine only when the dialog is maximised or when i call first an other running program. All appp except my main form...strange !
Have anyone some suggestion ? I thanks in advance. Nicolas
nicolas@nsjs.fr
|
|
|
|
|
When you say it does not work, what exactly to you mean? Is there an error? Or can you just not type or something?
When you say i call first an other running program do you mean you activate some other application and return to your app?
|
|
|
|
|
Is the timer event called when the dialog is not modal? I guess the modal dialog block all other threads.
This statement is false.
|
|
|
|
|
What is the Timer supposed to do?
|
|
|
|
|
Hello, thanks for the interest. Is the dialog modal or not, the result is the same. The tick event's job is only to put a string in the multiline textbox. Here my calling code :
gpsInput = new Form5();
gpsInput.TopMost = false;
gpsInput.Visible = false;
gpsInput.ShowInTaskbar = false;
gpsInput.dlgevent += new Form5.infoevent(gpsInput_dlgevent);
this.gpsInput.ShowDialog();
Here the tick events ( the button enable on/Off is only for testing this problem. The ReadPort is normally called and return the string to put into the textbox.
private void timer1_Tick(object sender, System.EventArgs e)
{
if (button2.Enabled == true)
button2.Enabled = false;
else
button2.Enabled = true;
// ReadPort();
}
I dream about ghost...
}
|
|
|
|
|
Hello, thanks to all. I have found a solution. Instead of using VisualStudio toolbox, I create the timer in my code as this lines :
timer = new System.Timers.Timer();
timer.Interval = 1000;
timer.Elapsed += new ElapsedEventHandler(timer_Elapsed);
timer.Enabled = true;
with a public var timer. All things work perfectly but I don't have understand why the toolbax timer don't work. I found this solution from deusXL on developpez.net forums. Also thanks to him.
Thanks to every body for your time.
Nicolas
|
|
|
|
|
This is a question for GC experts out there:
[Please don't respond telling me to use Dispose, it's not what I'm looking for.]
I'm currently looking for ideas on how to release memory right before a generation 3 garbage collection. Specifically, I have a bunch of objects that all hold the contents of corresponding files on disk. I'd like to hold as many objects as possible in RAM and only release them as more RAM is needed.
The naive approach is to use a Dictionary of WeakReferences. This is what I'm currently doing, but the problem is that some objects never get out of generation 0, and thus are collected and then re-loaded a few seconds later.
So are there any ideas with regard to getting a good estimate of when a garbage collection is coming so I can move unused objects into WeakReferences?
Some constraints:
1 - My deployment scenario is Mono + Linux, so I can't use the Win32 API, hidden CLR functions, COM, ect, ect.
2 - I'm developing with Visual Studio 2005 Pro. I can't afford VS 2008 Pro, and 2005 has some vital threading features in the debugger that VS 2008 express lacks.
modified on Friday, December 4, 2009 5:32 AM
|
|
|
|
|
Not sure if I understood your scenario correctly, but would the dispose pattern be of any use to you?
|
|
|
|
|
No, this has nothing to do with Dispose.
So think of it this way:
I have 100,000,000,000 large text files on disk.
Each time I access a text file, I check to see if it's in RAM. If it is, I just return the pre-loaded string. If it isn't, I load the entire text file into a string and cache the string.
Ideally, I'd like to keep all of the text files in RAM as strings, but, as I have 100,000,000,000 of them, I can't keep all of them in RAM.
I have no idea when I'm going to access the file again, but it might be as soon as a second, or it might be 10 minutes.
The problem is, if I use a dictionary of WeakReferences*, my strings never get beyond generation 0. They get garbage collected too soon, which means that if I access the same file every 2-3 seconds, I have to keep loading it from disk.
Thus, I'd like to know when a level 3** garbage collection is going to happen so I can explicitly release my references to the most unused strings and make room in RAM for newer ones.
* WeakReference: A weak reference lets you hold a reference to an object without preventing it from being garbage collected.
** Level 3 garbage collection: This is a less frequent garbage collection that only occurs when memory is running low.
|
|
|
|
|
|
Like I said, I'm deploying on Mono + Linux, so I can't use COM or CLR-specific APIs.
|
|
|
|
|
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
|
|
|
|
|
Best thing is to use dispose() pattern to release memory by using below code
dispose()
{
base.dispose();
GC.SuppressFinalize(this)
}
|
|
|
|
|
This has nothing to do with Dispose.
I'm trying to release references right before a garbage collection occurs. It's for a cache that should grow to occupy as much RAM as possible.
|
|
|
|
|
Pls. refers once purpose of Dispose pattern and supressfinalize method of GC.
|
|
|
|
|
|
Kindly change the question and state the correct problem there......
|
|
|
|
|
Look, I appreciate that you're trying to be helpful.
My initial question does state the correct problem: I'm trying to release memory right before a generation 3 garbage collection.
|
|
|
|
|
The question is already correct and unambiguous. It seems you got it wrong.
|
|
|
|
|
AFAICT, there is no way to tell when a GC is going to occur without diving into the CLR-specific API. Short of creating your own version of the CLR, I don't see how you can do it.
|
|
|
|
|
Yeah, I agree. The techniques described for .Net 3.0 seem a bit sketchy.
I ended up using an algorithm that checks GC.GetTotalMemory() on a periodic basis. As a consequence, the system administrator will have to tune the program to give it a target RAM amount to occupy.
|
|
|
|
|
Idea: Maintain a queue of strong references to the most recently used objects. This prevents them from being garbage collected. When an object is used, move it to the front of the queue. When you insert a new object at the front of the queue, delete the strong reference at the tail of the queue if the queue size is above a certain threshold.
If recently-referenced objects are more likely to be referenced again, this cache will avoid re-reading them from disk.
An enhancement: Instead of just a plain queue, keep the items in keyed storage (hash table, binary tree, etc), and maintain the queue as a doubly-linked list, implemented by Previous/Next fields in your items. This will let you quickly look up an object which may be in your cache. Adjust the Previous/Next fields to move it to the head of the queue. You'll also want to maintain external pointers to the head and tail of the queue.
Hope this helps.
|
|
|
|
|
That's pretty much what I decided to implement, although I'm experimenting with GC.GetTotalMemory() to determine how many items to pull off of the queue. I keep building the queue until GC.GetTotalMemory() reaches a target size, and if GC.GetTotalMemory() goes above a certain threshold, I remove two or three items.
I'm not quite sure how the linked list plays in: I'm keeping references with a dictionary, and the queue is used to increment / decrement an access count.
Anyway, thanks!
|
|
|
|
|
It's your app, so you know if this is possible, but I would try to resturcture the logic so I do not need to be accessing the same file repeatedly to the point where I'm keeping a cache of files. If you are only accessing a file once every 10 minutes, I would assume that the performance gain from caching the string will be small.
If the Mono garbage collector works like the .NET one, the Large Object Heap may be what you need. (I do not claim to be a Large Object expert. I've only read the first article that comes up on Google about it. [1][2]) If the resulting string from the file is >85K in size, the string should get placed on the LOH and will thus not get collected except in a full collection. If the files are smaller than that and you still need to cache them, you may be able to hack something together with a large finalizable object, but I wouldn't recommend it.
If that doesn't work, you probably need a more defined caching policy than "keep them as long as the process has memory."
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
