C / C++ / MFC

1. Always post the code that you actually use and that shows the described (problematic) behaviour 2. Cleaning up your code can occasionally help, but if you do so, then (a) make sure the clean code still compiles (and runs) to the extent the original code did, and (b) make sure the code still shows the same issue(s)! There really is no point discussing code that doesn't show the behaviour you are describing. 3. Learn to use a debugger, step through your code, and examine the current value of your local variables. Since you already know where you're crashing, it's a good starting point to set a break point before the call to push_back(), and investigate the state of your variables then. Bonus tip: remove that line using namespace std; It is a crutch and will make it more difficult to spot issues in your code. You'll need to add the prefix std:: in many places, so that requires additional typing, but it really isn't that hard, and it adds to the readability of your code as well as reducing the likelyhood that you're mixing up local and library symbols! The extra effort of always typing std:: pays off very quickly! If you don't believe me, the warnings are all over the place right in the C++ reference. See for example http://en.cppreference.com/w/cpp/language/namespace#Using-directives[^]: cppreference.com wrote: Using-directive does not add any names to the declarative region in which it appears (unlike the using-declaration), and thus does not prevent identical names from being declared. and cppreference.com wrote: The using-directive using namespace std; at any namespace scope introduces every name from the namespace std into the global namespace (since the global namespace is the nearest namespace that contains both std and any user-declared namespace), which may lead to undesirable name collisions. This, and other using directives are generally considered bad practice at file scope of a header file. Emphasis mine. 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 arc

Member 12108486 wrote: As per my knowledge, this need IE browser right? CHtmlView doesn't need a browser, it is the browser. "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

The code that attempts to use this function must have admin rights. The difficult we do right away... ...the impossible takes slightly longer.

Member 8534035 wrote: ...the tabulator is ignored completely. Of course, since it was not meant to handle it as a special case. One solution would be to call AfxExtractSubString() to break your source string up into its individual tokens. Then you could call InsertItem() to insert an item in the list control, followed by SetItemText() to set the text of subitems. "One man's wage rise is another man's price increase." - Harold Wilson "Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons "You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

I had the same problem using a CMFCPropertyGridCtrl in a CPropertyPage with VS2012 (without Touch Screen). Using the resouce in a CDialog is no problem, but when used in a CpropertyPage,the page calls OnDestroy as soon as it should be initialized. The Solution was, dont include the CMFCPropertyGridCtrl aus a resource control and dynamically create it after the InitDialog of the CProperyPage is called. CMFCPropertyGridCtrl * pctrlPropertyGrid = new CMFCPropertyGridCtrl(); if (pctrlPropertyGrid) { CRect rect; GetWindowRect(&rect); ScreenToClient(&rect); rect.DeflateRect(5, 10, 5, 10); pctrlPropertyGrid->Create(WS_CHILD | WS_VISIBLE | WS_TABSTOP | WS_BORDER, rect, this, IDC_MFCPROPERTYGRID1); ... }

See https://msdn.microsoft.com/en-us/library/ee125077(v=vs.85).aspx[^].

intelstar venus wrote: The problem was in using bad logger function. In general that should never happen. A good logger should not normally impact an application if the logger fails.

So what is the problem?

It is difficult to guess what may be happening in your code, but changing the text of a control should have no effect on the message passing and event handling for that control. I would try it myself but do not have MFC on my system. There is also some useful information at https://msdn.microsoft.com/en-us/library/65dtx4a4.aspx[^].