func(node* &h, int n, int m) h is a INOUT parameter, if func changes h then the caller see the changed value (that is after function execution, h could point to another address). func(node* h,int n, int m) h is a IN parameter, if func changes it, the caller doesn't see the changed value.

The Problem is that you ask the wrong question to the wrong partner. As I understand : MenuItem is a Control on your Form - which type has it ? Why do you search inside the Forms.Properties ? You should search it inside the Form.Controls-Collection. I could specify it with more information from you.

You're welcome :)

If your program isn't huge, no reason to do this in an external library, that would definitely be the slowest and most (disk) space consuming method. I'd say string table would probably be fast, and as long as you don't have too many strings, it shouldn't be too costly. If you have a huge number of strings, you may start using up quite a bit of memory to support this, then the library method starts to become more appealing.

I'm not quiet sure if I understood the question in the right way. I suggest : You iterate through the Application.OpenForms-collection to get the Forms of your Project. This collection return you a Form. Inside each Form you iterate through the Form.Controls-collection and look for your control.

econy wrote: I can't find a method in the Object You annot assume that Object will contain such a method; and where would it search for these items? You would need to first create some type of List that contains all the Objects, which you then search by name.

You need to customise the window's "chrome". If you're using .NET 4.5, the classes to do this are built-in[^]. For earlier versions, there's a library[^] you can use, although the site seems to be down at the moment. There's even a demonstration of how to use it here on CodeProject: WPF Custom Chrome Library[^] "These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

In the "Resources" section, you assigned a "Key" ("ButtonStyle" in this case ... it could have been called "Foo") to the Button style; the TextBlock style doesn't have a Key. Any style with a "Key" needs to be referenced via that Key (e.g. StaticResource ButtonStyle) in order to be applied to the relevant control. The TextBlock style (in this case) is applied to any TextBlock that is in the "scope" of that style (without needing a Key).

Thanks

If it's indeed the blit sucking that much time, prime suspect would be format conversion. Check out GetObject() for BITMAP, to see what the format of src and dest are. I'm willing to bet 3 lines of C++ that they are different. :-)

Trying things is the best way to learn.

HDC is a handle not an object.... You can use CDC::FromHandle() to get a temporary object for immediate use. Alternatively, you can CDC::Attach() to keep a more permanent CDC object around. You should make sure you release a device context (DC) when you're done using it (FromHandle sort of automatically handles this situation by going out of scope). If you have CWnds, you can also get a pointer to an existing CDC with CWnd::GetDC(). There is a lot of info on drawing in GDI online, I suggest you read up on it.

The first thing you've got to do is work out whether it's I/O bound or whether it's the data processing that's slowing things down. You might find that CFile isn't particularly well tuned for reading from flash and not buffering enough. If it turns out that it's the I/O that's causing the problem find the lowest level function you can call and see what the raw I/O speed of your device is for a range of buffer sizes and then implement something that hits the sweet spot in terms of buffer size. It's a shame you're using MFC classes and not standard library ones as it's a lot easier to replace the underlying buffering and I/O mechanism, but such is life! Another thing might be to try reading more data in your while loop (say 512 characters at a time) and manually parcelling out the data rather than letting CFile::Read do it. If it turns out that the I/O is fast enough then have a look at what you're doing with the data. If you've got a lot of string handling you might find loads of temporaries flying about (especially if you're using VC++ 2008 and earlier) and there's loads of hidden memory manipulation that's slowing things down. In that case look at reducing the number of temporaries you need by reusing objects and expoiting things like NRVO. Anyway, the main thing though is to find out where the bottle neck is then do something about it.

See http://publications.gbdirect.co.uk/c_book/chapter5/arrays_and_address_of.html[^] for a good explanation of this issue.

econy wrote: I think this is because ... More likely there is something not quite right in your code. But without futher information it is impossible to make any suggestions.

As far as I know, CMap has not such a facility. On the other hand, the std::map[^]... Veni, vidi, vici.

You are welcome. Veni, vidi, vici.

Exactly what Richard said above just subclass a static text box and you can use it over and over again. I have a standard code I use to do what you are doing and it also allows you to change the font, text color and background color as well which is all fairly trivial. Let me know if you want to see how to code it as I wont paste that amount of code if you don't need it.

GetClientRect returns the area of the drawable area inside the window. It will usually return something like 0,0,width,height in your rect structure GetWindowRect returns the co-ordinates of the Window itself relative to the upper left of the screen so they will be rather large. If you try to use GetWindowRect co-ordinates to draw on the window they will be way outside the right and bottom and the drawing wont be visible unless you drag the window right up to the top left off screen. You need to use GetClientRect co-ordinates to draw with. Looking at your code I am guessing this line is the problem if you have a position problem dc.BitBlt(137,107,176,50,&memDC,rect.left,rect.top,SRCCOPY); Are you sure that is right?