Comments by Aero72 (Top 16 by date)

Thanks, Barneyman - I hoped that's what the MMF was doing for me - reserving a fixed size of memory and have the OS read chunks of the file into that space. I'll try to roll my own and report back.

No worries, SA - answer rated 5 and accepted. Got myself a trial of a memory profiler. I was blind - now I'm learning how to see.

Thanks, Davey....so if I understand you correctly, the list is effectively an array of pointers, and it still has to put the data somewhere...so on my x32 machine, the 18 bytes of data per class instance is effectively 22 bytes of required storage when you take into account it has to remember where it put the data in memory.

Many thanks again, SA - lots of reading to do and code to re-configure. I will get back to you. The tip on WeakReference is potentially very interesting.

Thanks for your input - in answer to the questions you raise, the list type is a class which defines a float, two bytes, a UInt32 and a UInt64 - i.e. 18 bytes of data per instance in the list - so as you say I should be able to have several million items in this list without a problem.

As SA suspects there must be a leak. During one test run this pm, I calculated that the list should have occupied around 300MB, but overall memory usage for the program according to taskmgr (yes, I know I should look at using a memory profiler - that's tomorrow's job) was > 1.3GB!

You'll both be pleased to know that I have been able to work out a way of getting what I want to have (modeless floating forms inside a tab control) - and be able to control where the user is directing their input without using MDI.....so everyone's a winner :)

There is always a way - its just a matter of knowing enough to be able to make your fingers do what you think your brain wants.

Thanks for your input and suggestions. Aero

Thanks, Alan - your hint has indeed pointed to a solution for me. Thanks for your help

I think this is helping - presently doing quite a large mod to incorporate something along these lines will feedback when I've done some more experimenting...Thanks for the tip.

Thanks, Alan - I'll take a look at this later and give it a try

Yes that's right Bob - and it looks like using the ...SelectedTab.Controls.Add(Whatever)... you can add just about anything and have that tabpage host it. And yes, I have tried .ActiveControl previously.

SA - The reason for trying MDI is because it is actually what the user base for this kind of software is expecting (and I accept that doesn't necessarily mean its good for them) ;-)

I could just implement one instance of my user control per tab and have multiple tabs...or programmatically add a split container and allow several instances of it. However if I do that, the controls become docked - and again for this kind of software, the user is expecting to have floating controls to allow the user to set up their preferred screen (or screens - hence the tab control). My app already saves the size, location, user control type, what it contained and the tab page it was on so that the user can restore their last setup every time they run the software.

I have all this working quite well in "Non-MDI" mode with a couple of exceptions.

I tried using MDI because I know that an MDI interface has properties and methods associated with the Parent being able to know which child has the focus.

In Non-MDI mode, I can't find the right way to determine which of my user controls is being operated upon. At present the focus appears to be cycling round all of them - and that's the last thing I want. If anyone has any suggestions for this maybe I'll stop trying to use MDI!

Thanks and Regards, Aero