Xpnctoc wrote: I also did specifically mention video games and real-time simulations. amic calls. Could be mistaken though. Presumably you are familiar with 'video drivers' on PCs? The things that directly drive all the video on the box. They are pluggable components in the OS.

I use C++ A LOT, so I do forget that one sometimes... and as you've noticed, depending on the compiler (and settings), it may or may not allow it... pain in the butt! X|

I actually agree with you here... it is normally considered bad practice in GUI design to disable options by making them not visible. It creates confusion such as this, it is better to make to make the option inaccessible but still visible.

That sounds really intriguing and I'd love to read it, but $80 (Amazon Marketplace) for a mere 150 pages is terribly steep.

Pre-increment's return value is the iterator itself, while post-increment must return a copy of the iterator before it has been incremented. Since the for loop discards the return value, using the pre-increment version of the ++ operator saves some CPU cycles by not making a copy that will be discarded anyway. A longer explanation is here.[^] Edit: Oops, I did not see that there were so many replies already. Only the OP was visible at the bottom of the forums window.

Re-ordering the #includes did the trick. I had read about the use of printf/cout but I hadn't gotten to that point since I couldn't even get my variable declaration to compile. Thanks for the pointers.

I read the article, very interesting. I think I'll stick to my Allen 10 Wheeler. Dave.

Since there was no "remove" widget available, I was hoping that "delete" on the thread root would accomplish the same thing. Seems like the forum codebase itself could use a little tightening ;-)

OK, I can reproduce this under VS2010 (full and Express versions). I guess the only way forward is to raise this with Microsoft. I'm still confused as to why this happens with managed but not unmanaged code; I guess two different debuggers. It's time for a new signature.

Yeah, I saw that article before I even posted this. Just thought I would post to see if there were any .NET components out there so I wouldn't have to reinvent the wheel.

Never mind. I found it. The error message is actually misleading because it doesn't have to do with the names. It has to do with the sequence in which databinding takes place. I set up the BindingSource for the grid BEFORE the BindingSource for the ComboBox options. It's odd that this error was not detected right away but only after adding a row, but I'm not the only one to experience this: http://adamhouldsworth.blogspot.com/2009_04_01_archive.html[^] (Scroll down to the 7 April 2009 entry "Data Binding Pitfall").

FYI... It looks like I resolved it by cleaning the solution and rebuilding everything. Now all my .dll.meta data file have metadata in them and I can't reproduce the problem when I make additional updates to the class library. Looks like a Visual Studio glitch.

FYI... It looks like I resolved it by cleaning the solution and rebuilding everything. Now all my .dll.meta data file have metadata in them and I can't reproduce the problem when I make additional updates to the class library. Looks like a Visual Studio glitch.

Thank you. :-D Greetings Covean

Not sure why that would make a difference. I also noticed a syntax difference between your code and my code: Migounette wrote: comboBox1.Items.Clear(); I did not use a designer to make a custom control. I inherited directly from ComboBox. I call Items.Clear() from RepopulateChoices(), which is a private method in the inherited class. All of your code starting with "comboBox1..." is not at all how I'm doing things. I'm going to make another post to clarify as there seems to be a tremendous amount of confusion over this from all respondants.

it looks to me the only way to do this without making the form modal is manually... MyForm^ f = gcnew MyForm(); f->StartPosition = FormStartPosition::Manual; f->Location = System::Drawing::Point((this->Width - f->Width) / 2 + this->Location.X, (this->Height - f->Height) / 2 + this->Location.Y); f->Show(); Mark Salsbery Microsoft MVP - Visual C++ :java:

That answer is VERY CLOSE. I just had this problem, found your message, and it led me to a solution. Sorry for the reply an old thread. PROCEDURE: Right-click on properties and turn off "Description." Close the Properties window. Close Visual Studio. Restart Visual Studio and load your project/solution. Open the Properties window. Right-click on a property in the window and turn on the "Description" option. When I turned the "Description" option back on, the description pane reappeared.

Never mind. I just answered my own question. The answer is my application has memory leaks coming out of my ears. I just found an article that explains you need the keyword "virtual" in your destructor declaration. I haven't been doing that. Shame, shame, shame! In case anyone else finds it useful, here's the link to the article.

Get/set make it easier to change how access to the property is handled, WITHOUT having to change your code every place the property is referenced. For example, you could make the property (in effect) virtual, calculating it only if/when it's needed. Or you could easily add pre/post-processing to property accesses. Another benefit is it gives you a location to set a breakpoint when debugging, so you can see WHERE accesses to this property are coming from.