C / C++ / MFC

You are getting build configuration mode as in "debug" and "release" mode come in that isn't relevant. The act of connecting a debugger does it's thing which is connect to the memory space, function and variables it doesn't give a rats about build mode. From a memory point the key thing it does is drop it's own heap manager which has been forever but started to be improved in VS2014 and now it connects to that whole memory display gadget that seems to get slower and slower each release. C++ Debugging Improvements in Visual Studio "14" | C++ Team Blog[^] That means whenever you run the debugger the heap is different to normal unless you go thru the hijinx to turn it off which used to be as simple as _NO_DEBUG_HEAP = 1 but like everything it has gotten successively harder. In vino veritas

There are multiple third party tools available on the internet, you just need to find right solution. I have used OST to PST tool when I required same issue and got accurate result. This is download link of software, download from here OST to PST. Visit here: http://www.sametools.com/convert/ost/

Start by checking the documentation: LoadStringA function (winuser.h) - Win32 apps | Microsoft Docs[^]

Well techinically it is x = 0 but there is nothing stopping you simply entering a negative x co-ordinate of a few pixels to allow for your white border. The richedit like all windows knows how to clip :-) In vino veritas

Since the problem appears to be within Microsoft's library it would be best to report it to them.

I'm not sure I understand. If the variables you called dl and dr are part of your code, then surely it is in your hands how to define and use them? If any code breaks, it is an indication that code was bad to start with. I'm not surprised though: there must have been a reason for the odd malloc statements, and my suspicion, as stated before, is that someone uses these pointers not as pointer to some struct array, but as a pointer to some meta-struct: see my other posting with a suggestion how to declare such a struct. If you don't fix that broken code, it won't be clean. And reinterpret_cast does not fix anything. It only makes your code compile, but it doesn't make it work, much less clean. I do not suggest to fix or change the structs hci_dev_req and hci_dev_list_req themselves, only the code using them. That code defines variables called dl and dr, and the way these are allocated currently indicates that code is broken and needs to be fixed. And that includes any code that uses dl and dr. If for some reason you can't get std::array to work even though it does not require C++11, you could try std::vector instead: the main difference is that std::vector does not require the size to be known at compile time, and it can be resized dynamically. If HCI_MAX_DEV is a constant, std::array should work just fine; otherwise you need std::vector. Of course, you can't pass a std::array into ioctl where it requires a hci_dev_list_req - you first need to convert it. That is not unusual for modern C++ code using old C APIs: in such cases you need some helper or wrapper functions that perform these conversions under the hood. If you want to avoid these conversions, then the task you're asking for is an entirely different one - you should have stated that much from the beginning. Then we could have told you that it's not a good idea to transport a hackish C struct into C++ code and expect the resulting code to be 'clean'. GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)

Thanks wasn't sure if bullets could be colored I'll use the the SetSelectionCharFormat member crTextColor of charformat to color the text thanks

Did you take note of the comment Due to the way OLE works filename must be fully qualified (ie c:\folder\a.jpg) That is usually the first port of call to why OleLoadPicturePath fails. In vino veritas

It’s the thread immediately below.

thanks that's all I was looking for from the way you see it I should be able to modify the text, I did a SetWindowText to the Richedit e.g. this is a test message and was able to type in it the rich edit control thanks for your help if from the way you see it I should be able to modify the text Ill research the problem

charlieg wrote: Oh if this works, Christmas has come early! I'll check it out. You make it sound as if you are the only developer that has ever had this requirement. There are dozens of commercial and open source products that have the capability. List of performance analysis tools[^] Intel VTune is probably the easiest to use and has a lower learning curve. There is also a free trial version. Best Wishes, -David Delaune

leon de boer wrote: In the past for just basic files I have used GitHub - brechtsanders/xlsxio: XLSX I/O - C library for reading and writing .xlsx files[^] thanks its working now

First, I use Visual Studio. Invalid after adding add "/fixed" linker option. and error LNK1146: no argument specified with option '/base'

Of course, I see that now. I knew I was making some type of stupid mistake, but those are always the hardest for me to catch and correct. Thank you for your response.

Please don't post the same thing in multiple places - you have it in QA as well, and duplicating work doesn't help anyone... "I have no idea what I did, but I'm taking full credit for it." - ThisOldTony AntiTwitter: @DalekDave is now a follower!

Unfortunately there is no way in standard C/C++ to do that, but I see you're already using non-standard functions anyway. As David pointed out, _getch() should do the trick: #include "stdio.h" #include "conio.h" int main() { char c; c = _getch(); putchar('*'); printf("\nYou entered %c\n", c); _getch(); // just to pause the program before closing the output console return 0; } If this doesn't work, refer to this thread for more advice: c++ - Capture characters from standard input without waiting for enter to be pressed - Stack Overflow[^] GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)