You are right, register the ActiveX has anything to do with the 'No Safe' message displayed. but if we want to use the Activex we have to register it. Now I'm doing same manually by using Regsvr32 /u D:\MyActivexCtrl.ocx. How can i do so programeticall? And also If I'm trying to register in some system it is giving error LoadLibrary(".ocx") failed - This application has failed to start because
the application configuration is incorrect.
How to fix this?
I'm getting some very strange behavior in an MDI MFC application with tabbed views I'm working on that I can reproduce easily in any new MDI application I make (that uses tabbed views), and I can't seem to fix it. I'm using Visual Studio 2010. I made a sample application to demonstrate my problem. In my CView (in my example called CNewTestView) I override CView::OnActivateView. I can't seem to call DestroyWindow in OnActivateView, but ONLY when the view is activated by switching to it through the Windows 7 Aero Preview thumbnails. ie. When I switch to a non-active view by either clicking a tab or by pressing CTRL+Tab there are no problems at all, but when I hover the mouse over the application icon in the taskbar and then switch views by clicking on the non-active one then the problem shows up. In the application, I create 2 tabs by pressing Ctrl+N.
As an example, I made a member variable of type CEdit called CNewTestView::m_edit, in a new MFC project with tabbed MDI views, and no other code at all added or modified. Here's the code for OnActivateView:
I get an assertion in CWnd::DestroyWindow on line 1047 when the HWND of the CEdit is being looked up in the HWND map returned by the call to afxMapHWND. Here's the code in wincore.cpp where the assertion occurs:
// Note that 'this' may have been deleted at this point,// (but only if pWnd != NULL)if (pWnd != NULL)
// Should have been detached by OnNcDestroy#ifdef _DEBUG
ASSERT(pMap->LookupPermanent(hWndOrig) == NULL);
Note that for the assertion all I get is a buzz noise to indicate the assertion, but the debugger doesn't actually break at the assertion. If I compile a Release version I still have a problem (basically I can't recreate the window, and so the application doesn't work properly). If instead I slightly delay the call to DestroyWindow, eg. if I destroy the window in CView::OnTimer after setting a timer in OnActivateView or in a message handler after calling PostMessage then there's no problem at all. Unfortunately I can't do this, since in my real application I'm developing there seems to be other calls resulting from OnActivateView that, after a long line of calls, eventually results in a call to CWnd::DestroyWindow, and the application has gotten large enough that it would be very time consuming to implement the PostMessage call to work with no assertions at all. Does anyone know what's going on?
In the example I gave above I did not add anything else at all to the empty application other than what I mentioned in this email.
I fixed the PostMessage problem I mentioned. Turned out the problem was with my code, so everything's working well with my call to PostMessage in OnActivateView. Regardless, I'm still curious as to why I can't call DestroyWindow of a child within OnActivateView of the CView. (I forgot to mention that I'm using a document/view architecture)
I don't have access to MFC, unfortunately, but can you attempt to debug the application and follow the code into m_edit.DestroyWindow()? It might give you some clue as to when things start to go wrong inside DestroyWindow.
I've read something about LookupPermanent going wrong when it is called from the wrong thread. I can't imagine that to be the problem, but it's something you might want to rule out, just to be sure.
I know Active document server can render a ole file such as office document, but i found AcroPDF also use Active document server technology toload .pdf files in IE.
When I open a pdf filewith UltraEdit,see binary data,not seems like a ole file.
and anyone can tell me how can i create a Active document server to render a txt file.
I construct a Streambuf with "an array of char". and use the steambuf to construct a ostream/istream:strm.
But the strm cannot do anything with "char array".like << | >> doesn't affect the char array data.
Have I missed something?
When using the Windows FileOpen dialog with multiple selection do you ever wonder how much memory you have to allocate for the buffer. Is one kilobyte going to be enough? Or should you make it ten? How about one Megabyte just to be safe?
It seems that no matter what you choose, you are either going to waste a whole bunch of memory just to be safe, or your user is going to select a bunch of files only to find their selection didn't work because your buffer was too small.
one way is Derive the CFileDialog class , the article as follow introduce it:
but I found when the file names buffer is enough large , it run successly; but when when the file names buffer is not enough large (it means the program will enter if(cbLength>(pOfn->lpOFN)->nMaxFile) ), when after run INT_PTR ret = fileDlg.DoModal(); the value of ret is IDCANCEL. I catch the error code, it is FNERR_BUFFERTOOSMALL . In the end even I allocate a enough large memory ,the error code still is FNERR_BUFFERTOOSMALL . Why???
I have a memory leak on a C++ MFC app I'm trying to solve.
In the problematc part of code there are some function calls as follows:
Since this unmanaged code, is it safe to do that without freeing the memory allocated by the new operator, or it will be released after exiting the functionA scope?
Shouldn't be something like the following a good solution?
ClassConstructor *obj = new ClassContructor();