cincyreds

Thanks for for the advice and great explanation. I'll give it a try. :)

I have a collection (collection "A") on which I need to do some processing. The processing will actually modify "A" by deleting entries. After the processing is over, I want to restore the collection to its original state. So, before the processing starts I need to copy collection "A" to a temporary collection (let's call it "Temp"). Then do the processing which basically destroys collection "A" After processing is over, copy "Temp" back to "A". The problem with just using: Dim Temp as new Collection Temp = A <do some processing> A = Temp is that anything that happens to A during processing is reflected in Temp, so Temp gets destroyed too. I've tried putting the processing into a separate function and passing collection "A" ByVal to that function, then restoring upon completion. No go. It seems passing a collection ByVal has no effect - the collection is STILL modified. What's the quickest way to copy a collection "ByVal " for lack of a better description? Thanks, Dean

Is there any code in your form's Resize event?

Intersting, but there are a couple caveats: 1. It will only work with fixed-width fonts and you have to hard code the characters per line into the code. I guess the real trick would be getting this to work with ANY font as I would suspect most people use proportionate width fonts. Maybe tapping into the GDI might be the only way to make things foolproof, but that would be a real challenge especially in the case of multiline scrolling textboxes. Regardless, your code is kinda cool. :)

If it were up to me I'd get rid of the "Syntax Specific" forum altogether. I think it's too all-encompassing (almost anything that needs to be done involves syntax one way or another). But the kicker - every post except one since the beginning of the year has been moved. That oughta tell you something - people just don't really understand what the forum is for. Trash it. It'll help keep topics from straying into the wrong area and make a little less work for the admins. Cheers, Dean

Wraith, thanks for the comments. Yeah - it'd be nice to shake some users from time to time <grin>. I agree with you, though as programmers it is our job to make an app tailored to the end user. If the end user is ignorant, we should take that into account. I'll use the analogy of those cheesy infomercials you see all the time advertising absolutely useless junk. If they decided to design their commercials to appeal only to smart people who aren't gullible, they would never sell a single unit. Instead, they appeal to morons and suckers and sell the crap out of their junk. So it is with programming (though hopefully we're not writing crap!). If I can keep my app in the hand of an ignorant user by masking the technical stuff they don't understand, then great. A good programmer will make the program appealing to a wide audience. Yeah - maybe I'm over-thinking this, but I always consider the end user even if the end user is a technophobe. Anyhow, thanks for the comments and have a great weekend!

My mistake. I tested this using words that were too long to fit on one line, so it appeared to wrap on a character level. Good catch. My bad. Sorry about. I deleted my original reply seeing as the info was wrong.

Definitely. And performance is fine. But the numbers in the task manager are important as well. If someone **thinks** my app is using too many resources (even when in fact it isn't), it may get the 'old heave-ho anyhow. So, not only do I want to use few resources, I want it to **appear** to use few resources as well. OK - maybe I'm being a little anal, but solving this dilemma is also a good learning experiecne. As for GC.collect - I'm not using that at all. I only tried it to see what would happen, then removed it from code. Right now the app is 100% managed code. :) Cheers, Dean

Make sense. Thanks for the explanation. Absolutely. I only tried GC.Collect() to see what would happen, but I do realize this is bad practice and the app is not doing this. The difference between 900k and up to 20 megs. Part of the reason in wanting to keep footprint small is for user perception. I plan on releasing the app publicly and part of its appeal will be the small memory consumption. Because it's something that would be running 24/7, it's important to use as little memory and cyles as possible so I've approached this with the attitude of dropping resource requirements to as low as possible rather than having a "well, it could be lower, but it's probably good enough." If anyone else is like me, when I install a new app which has to run for an extended time and I see it consuming 12 megs of ram and a good amount of clock time, it better have a damned good reason for being there or it gets uninstalled. That's the rationale behind my "quest" for lowest possible resource requirements. Hmm. Not really second guessing, just optimizing. Part of the reason is for appearance as remarked in my reply to the last statement. Besides actually **using** few resources, I want my app to **appear** to always be using few resources. I suspect most end users do not know what the "garbage collector" is, let alone how it works. I can't explain in the readme.txt that "if you see it using lots of resources, don't worry - the GC will eventually clean it up." As well, I'm not using GC.collect or anything really fancy. Just trying to free resources asap. That's exactly what I thought, but it now seems that initial allocation may be based on some kind of pre-existing algorithm to determine the **potential** of resource needs. Obviously something different is happening when, like I mentioned, a window in 2 identical states (which you'd think would have the same allocation requirements) uses vastly different amounts of memory. Frankly, I'm just not technically smart enough in this area to really explain it. Absolutely. Usability is king. This whole memory thing is just one facet of the app. I've spent a LOT of time tweaking every little thing to make sure end user experience is optimized, makes sense and easy to use. But I do lump resource usage into that experience on a certain level. Like I mentioned, I for one will uninstall an app if I see unacceptable resource usage. I love those little apps written by good C programmers. Resource usage is always spartan. Although I know the overhead of the CLR can make that difficult, I'm shooting for as low as I can get. Right now I've tweaked this as much as I can and I think I'm happy with resource usage at this point. When the app is idling (which is probably 98% of the time), it uses around 900k and runs on a low priority thread. I'm using a separate system timer that fires in the background at a regular interval which does a quick call to my memory cleanup routine. It's funny, but if the app sits in the tray doing NOTHING, resource usage will slowly continue to climb. Makes no sense because NOTHING is being done except for having the main system timer (not a windows form timer) running. Even if its interval is set for days in advance, the app does nothing but sit in the tray waiting for that timer to fire. Running the memory cleanup routine keeps things in check. The ONLY thing the cleanup routine does is issue the following commands to the form running in the tray: FormTray.Show() FormTray.Windowstate=Normal FormTray.Windowstate=Minimized FormTray.Hide() The form itself is set to NOT show in the taskbar and has a startup state of minmized, so when it is technically shown, you can't see it. Just issuing the 4 statements above seems to force the app to drop resource usage. For the hell of it I'll post a link to the finished product here if you wanna have a look-see. Thanks for your great answers - they helped! :) Dean

Thanks for the quick reply and link. Seeing as you deal with XML a lot, what's your opinion about the following: My app is a task scheduler that runs in the system tray. When it comes time to check for any events that need to be fired, it parses the list of scheduled events and retrieves the pertinent info for each event. This involves accessing anywhere from 5 to 20 individual settings for each event depending on its status, etc. My concern is speed and overhead. I want the loop that checks these events to be as tight as possible. If I have to access the hard drive a few hundred times then this can become critical - especially in a timing application where it's critical not to miss events. Memory consumption is also a concern. I've taken great pains to make this app as memory efficient as possible and right now when idling it runs on a low priority thread in only 800k of memory. I don't want to keep large chunks of data cached, etc. Currently the program pulls in what it needs to only when it needs to, then releases it immediately after. No extra classes, references, strings, etc. hanging around. It just ***seemed*** that XML involved more overhead which might result in slow performance especially in cases where I might only need to read one value. That being said, how do you find the performance of XML in terms of speed, overhead and memory consumption? For my situation, the RETRIEVAL speed is more critical than the WRITING speed. Most major writing is done only when the user manually saves or updates a new task. Any other writing is only 2 or 3 values to update its status, etc. As well, there are LOTS of places where I code reading and writing. I'd hate to have to specify overly long function calls with long parameter lists just to write a single value. I wrote a registry class wrapper that optimizes everything so function calls are short and sweet without having to re-specify sections and keys that are being reused. Thanks for your time! :) Dean

(NOTE - I just realized I was in the wrong forum when I posted this. If a mod could move this to the I/O section that would probably be more appropriate- thanks). I'm writing an app which currently uses the registry for storing program data. Unfortunately the amount of data which needs to be stored can easily exceed the limits for keys, values, etc. so I need to go with a file based system for storage. In keeping with the .NET "mindset" I originally planned to use XML config files, etc., but after looking at some of the overhead and hoops that need to be jumped through just to save/retrieve simple settings, I now think that INI files would offer a better solution (the app is time sensitive so I want data retrieval to be as quick as possible). I plan on writing a 100% managed code class for INI file manipulation. I've found only one on the web, but it was quite basic and not very well written. All the others use API calls which I'd like to avoid. Does anyone have a robust 100% managed code INI file class? If so, could you post a link? If not, is there anyone interested in a managed code INI file class? If so, I'll post it here when complete. BTW, this would be written in VB.NET. Cheers, Dean

Try this link: http://www.schroeder-ka.de/Downloads/LvSort.html

Convert your icons to .PNG format (Microangelo Studio, for one, can do this). PNG supports transparency. PNG files are almost always smaller than ICO files - an added bonus. (If you do so, just make sure to save the .PNG file using transparency).

That was my first guess, but I really don't think that's it. I'm familiar with the GC and have tried forcing it (which normally isn't a good idea). No difference. I've let the screens stay up for around a half hour and memory consumption stays the same. I hate to say this, but I don't think this has much, if anything to do with the GC. As well, when the app first starts and nothing has been done, there would likely be no GC activity for the app at that point (especially a simply app like the one above that just opens up and sits there doing nothing). So you would expect that the initial memory allocated is necessary. But then simply minimizing the form drops memory consumption drastically and instantly. Why would the app, in 2 IDENTICAL states need 16 megs of ram in one instance and only 2 in the other? I've always thought that once a form is disposed and set to nothing, it is gone and all resources released. Obviously this is not the case. I've tried all kinds of tricks to reduce memory consumption consistently. Right now I'm using one that is really goofy, but drops memory consumption. Basically, it creates a new form, sets Opacity to 0, ShowInTaskbar to false, WindowState to minimized and location to 8000 (to position it off screen for good measure). It then does a form.Show(), then minimizes it, then the subroutine exits. Calling this from my app after I close a form drops memory usage instantly. Although this works, it still doesn't make sense. The only other thing I can think of is that GDI objects are not being released. Not sure, and I don't know much about reclaiming GDI resources. :)

I've been scratching my head for days trying to figure this out, but can anyone explain why even a simple application seems to hold on to resources after (supposedly) releasing them? To duplicate specifically, create a new windows application project and add two forms. On Form1 put a button and in the button's click event put the following code: Dim f As New Form2 f.ShowDialog() f = Nothing Step 1. Start the app. Step 2. Check memory usage at this point in Task Manager. In my case, it shows about 15,920. Step 3. Now click Button1 which will pop open Form2. Step 4. Check memory usage again. In my case, it shows about 16,416 - a slight increase which is expected. Step 5. Now close Form2. Step 6. Check memory usage. One would ***expect*** that now that Form2 has been closed and set to nothing, memory usage would return to the level it was before Form2 opened. However, memory usage has not gone down at all - in fact, it has increased slightly! Why? Why? Why? And if you continue to open and close Form2, memory usage climbs each time. Makes no sense. To further confuse things further, do this: After step 2 (before clicking the button), MINIMIZE Form1. Wow - memory usage drops to 728k! Now restore the window. You would ***expect*** that memory usage would go back up to the level it was before the window was minimized. However, memory usage now has dropped to around 2,496! This again makes no sense. Why would Simply minimizing and restoring a form vastly decrease memory usage? Now more importantly, is there a way to reclaim memory when completely closing a form? Any experts out there with a solid answer? Thanks, :) Dean