|
Element = void*
I'm experiencing the same problem in a somewhat different situation
Here is the relevant code:
Element string_to_element(const char* val)
{
Element localElem = malloc(sizeof(val));
strcpy((char*)localElem , val);
return localElem;
}
const char* element_to_string(Element e)
{
int i;
const char* localStr = (char*)malloc(sizeof(char)*(strlen((char*)e)+1));
for (i = strlen(localStr) ; i > 0 ;i--)
((char*)e)[i] = NULL;
strcpy(localStr , (char*)e);
return localStr;
}
void string_free_func(Element strElem)
{
char* string;
if(strElem == NULL)
return;
string = (char*)strElem;
free(string);
}
void main()
{
char* str2;
char* str1 = "simple string";
Element e1 , e2;
e1 = string_to_element(str1);
str2 = element_to_string(e1);
string_free_func(e1);
}
This code is a bit modified but should illustrate the problem I'm facing.
any help would be most appreciate
|
|
|
|
|
Be care with pointers!
void main ()
{
int num = 2<code>, i</code>;
char** str_array;
char str1[] = "first string";
char str2[] = "second string";
<code>str_array=NULL;</code>
str_array = (char**)malloc(sizeof(char*)*num);
<code>for(i=0;i<num,i++) str_array[i]=NULL;</code>
str_array[0] = (char*)malloc(sizeof(char)*strlen(str1));
<code>for(i=0;i<strlen(str1),i++) str_array[0][i]=NULL;</code>
str_array[1] = (char*)malloc(sizeof(char)*strlen(str2));
<code>for(i=0;i<strlen(str2),i++) str_array[1][i]=NULL;</code>
strcpy (str_array[0],str1);
strcpy (str_array[1],str2);
printf("%s \n",str_array[0]);
printf("%s \n",str_array[1]);
<code>if(str_array[0]!=NULL)</code>
free(str_array[0]);
<code>if(str_array[1]!=NULL)</code>
free(str_array[1]);
<code>if(str_array!=NULL)</code>
free(str_array);
}
Russell
|
|
|
|
|
What is the best way in MFC to programmatically close a CView derived class instance?
I'm currently posting a WM_CLOSE to the views parent frame window. Is this the common way to do this?
|
|
|
|
|
Yes.
then the frame calls DestroyWindow to destroy itself. The message will be sended to all the childs, so also to your CView derived class.
Then you have only to write the right code to destroy correctly the view.
Russell
|
|
|
|
|
Thanks.
I was having a problem elsewhere in the code and I was trying to detemine if this method was sound or if it might mess up the MFC internal houskeeping somehow.
Most of the books I have don't cover this except one which suggested this technique.
Again, thanks for your help.
|
|
|
|
|
In addition to Russell's reply -
Typically you'd use DestroyWindow() to destroy a window but with MFC doc/view, that
would bypass the prompt to save an unsaved document and delete the document if its
autodelete flag is set.
I disagree with Russell's statement that the WM_CLOSE will be sent to the children, but
it's generally not an issue anyway since only frame windows do something useful with the
message.
I always figured the reason it's not documented is MFC just assumes only the user will
close a window. Just one of the many irritating things about the doc/view architecture.
Cheers,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark Salsbery wrote: Typically you'd use DestroyWindow() to destroy a window but with MFC doc/view
I hear you. I'm definitely not out to bypass MFC on the close. Actually, that was my concern. I was afraid I might be bypassing something important in MFC closing the view by sending the message to the frame. I was getting funky behavior with my window list when I tried something that might be considered unorthodox elsewhere so I figured I might be messing the whole MFC internal management scheme up.
Sometimes cause and effect is about all I have to go off of when the MFC source calls the win32 api internally so I figure I'll ask the pros here about what they might know about the internal behavior in general.
Thanks for the response.
|
|
|
|
|
bob16972 wrote: Sometimes cause and effect is about all I have to go off of when the MFC source calls the win32 api internally
Yeah  That's why the best documentation IMO is the MFC source code.
Cheers!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
It depends a lot on which properties had to have.
In my project, I had a CScrollView as MainView and then the possibility to hold a CFormView for EVERY element on the screen (up to 48). All secondary views should close without problems and /or asking to save changes on the document. I managed it with:
BOOL CMyDoc::CanCloseFrame(CFrameWnd* pFrame)
{ int nError = 0;
CView* pFrmView = pFrame->GetActiveView ();
if (pFrmView->IsKindOf (RUNTIME_CLASS (CFormView)))
return TRUE;
POSITION pos = GetFirstViewPosition ();
while (pos)
{ CView* pView = GetNextView (pos);
if (pView->IsKindOf (RUNTIME_CLASS (CFormView)))
{ CFrameWnd* pTempFrame = pView->GetParentFrame ();
if (pTempFrame)
pTempFrame->DestroyWindow ();
}
}
return CDocument::CanCloseFrame(pFrame);
}
Then I only have coded the OnDestroy in every secondary window to release all used memory and delete contents of listboxes, array and so on.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
anyone know of a good hierarchical tree drawing utility/library (MFC or even JS/DHTML) that can display trees of arbitrary depth, with arbitrary number of children per node ? this is for drawing the results of an expression parser, where parent nodes are functions and the leaves are parameters. the trees are non-recursive, ordered; nodes have single-parents and unlimited children (which can be other nodes or leaves).
i do not want to use a CTreeCtrl-style tree. i want something more like this (sample 1a) - a proper graph.
|
|
|
|
|
Chris Losinger wrote: i want something more like this (sample 1a) - a proper graph.
I have never attempted it for that purpose, but GraphViz does those type outputs:
http://www.graphviz.org/Documentation.php[^]
http://www.graphviz.org/Gallery/directed/unix.html[^]
I have never used it as a library, but I do use it as a utility (build graph language -- execute graphviz -- read image), Doxygen does the same thing, including hyperlinked text within the images (I have not gone that far, though debated on digging into their code to try).
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
GraphViz dot for your example:
digraph G {
S -> NP -> el;
S -> VP -> V1 -> hizo;
VP -> V2 -> decir;
VP ->NP1 -> lo;
VP -> NP2 -> ami
}
of course without the renaming of V1,V2 and NP1 NP2 to V and NP, but I could do that later.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
I have an MDI application with two view types for the same document. I am creating the instances of the second view type from an instance of the first view and then hiding all instances of the first view type using CFrameWnd::ActivateFrame() with a parameter equal to SW_HIDE. When all instances of the second view type are closed, all instances of the first view are reenabled using CFrameWnd::ActivateFrame() with a parameter equal to SW_SHOW.
It appears to work under certain circumstances and the window list in the menu appears to hide the references to those hidden frames. However, as I start to post WM_CLOSE messages to the visible views frame window class the window list gets quite out of sync and at the point I try to renable the instances of the first view types, nothing shows up in the window list even though the windows themselves are visible in the client area.
If I don't hide any views the window list remains in sync but I'd rather hide the views if possible.
Has anybody tried something like this before and got it to work?
// Here are some snippets
// CTheApp::InitInstance()
// First template
m_pDocTemplateFirst = new CMultiDocTemplate(
IDR_FIRST_TYPE,
RUNTIME_CLASS(CTheDoc),
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(CFirstView));
if (!m_pDocTemplateFirst)
return FALSE;
AddDocTemplate(m_pDocTemplateFirst);
// Second template
m_pDocTemplateSecond = new CMultiDocTemplate(
IDR_SECOND_TYPE,
RUNTIME_CLASS(CTheDoc),
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(CSecondView));
if (!m_pDocTemplateSecond)
return FALSE;
AddDocTemplate(m_pDocTemplateSecond);
// From the document class
// Creating the new view based on the second doctemplate
CFrameWnd* pFrame=pDocTemplate->CreateNewFrame(this,NULL);
if (pFrame) {
pDocTemplate->InitialUpdateFrame(pFrame,this,TRUE);
}
// Elsewhere
// Closing the frame and subsequently the view
pFrame->PostMessage(WM_CLOSE);
|
|
|
|
|
For some reason, this seems to fix the refresh issue.
In my CTheDoc::CanCloseFrame(), I have to do this to a child frame when closing it if I have other frames that are deactivated that are also associated with the document.
BOOL CTheDoc::CanCloseFrame(CFrameWnd* pFrame)
{
pFrame->ActivateFrame(SW_HIDE);
return CTheDoc::CanCloseFrame(pFrame);
}
Any ideas on why this would be necessary? Or am I just getting a false positive?
|
|
|
|
|
Looking at the app in Spy++ right after closing a few frames this way seems to be clearing them out cleanly so I'm guessing this technique will have to do.
Any comments still welcome as I'm quite perplexed as to why. The MFC source code seems to just call the Win32 api for the menu refresh so no clues there.
|
|
|
|
|
Copying from my answer above:
In my project, I had a CScrollView as MainView and then the possibility to hold a CFormView for EVERY element on the screen (up to 48). All secondary views should close without problems and /or asking to save changes on the document. I managed it with:
BOOL CMyDoc::CanCloseFrame(CFrameWnd* pFrame)
{ int nError = 0;
CView* pFrmView = pFrame->GetActiveView ();
if (pFrmView->IsKindOf (RUNTIME_CLASS (CFormView)))
return TRUE;
POSITION pos = GetFirstViewPosition (); while (pos)
{ CView* pView = GetNextView (pos);
if (pView->IsKindOf (RUNTIME_CLASS (CFormView)))
{ CFrameWnd* pTempFrame = pView->GetParentFrame ();
if (pTempFrame)
pTempFrame->DestroyWindow ();
}
}
return CDocument::CanCloseFrame(pFrame);
}
Then I only have coded the OnDestroy in every secondary window to release all used memory and delete contents of listboxes, array and so on.
About the process of creating other windows... I have answered it as well in many times. Take a look with the search option in the forum (not in the articles) with my nick. It is quite good explained.
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
Good day. My programming language knowledge is not strong. I am not sure what I did to my software and static library can prevent people crack or not. Please give me your opinions:
1) My software is communicating with a device.
2) The password is store inside the device and only the static library know how to send down command to device to retrieve the password.
3) The password is encrypt/decrypt when write in/read out from device by my software.
4) The encryption/decryption algorithm is a function in my software.
The current situation is that I know someone have the ability to mimic my library call to the device to retrieve the password, and my problems are:
1) Is it possible for someone to find out the password by intercepting the output of the decryption function?
2) What is the best method to protect the password in my case?
|
|
|
|
|
Hirakawa wrote: 1) Is it possible for someone...
If it involves a computer, especially one running Windows, yes.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
It means even a software with encryption and decryption ability also useless and vulnerable.
I think firmware is the only way to prevent hack.
|
|
|
|
|
Hi ...
I am expanding on a ATL Addin Framework from thomas_tom99.
http://www.codeproject.com/com/AddinProjectFramework.asp
To summarize the Addin Framework includes ATL COM (with MFC) Addin Components. The host application will use the Addin Manager to look for registered COM components with the matching CATAGORY ID and then load them into the host application. The Addin Components work nice.
The Addin Components are ATL COM with MFC. I would like to add a CFormView based object to the Addin and then access and use the view by my SDI MFC host application.
// Forms below are in DLLs. We will need to get the handle for the
// resource in the DLL while the view is in use (selected)
hDLL = GetModuleHandle("Addin1.dll");
hEXE = AfxGetResourceHandle();
AfxSetResourceHandle((HINSTANCE) hDLL);
m_nAddin1View0 = m_wndHorSplitter.AddView(1, 0, RUNTIME_CLASS(CAddin1View0), pContext);
AfxSetResourceHandle(hEXE);
I get the following error:
MainFrm.obj : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const CAddin1View0::classCAddin1View0" (?classCAddin1View0@CAddin1View0@@2UCRuntimeClass@@B)
I have done this in the past with a standard MFC DLL. ??
---------------------
Here is the addin and host code:
In Addin1.dll I have added the CFormView derived CAddin1View0 class.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
class CAddin1View0 : public CFormView
{
protected:
CAddin1View0(); // protected constructor used by dynamic creation
DECLARE_DYNCREATE(CAddin1View0)
// Form Data
public:
//{{AFX_DATA(CAddin1View0)
enum { IDD = IDD_ADDIN1_VIEW0 };
// NOTE: the ClassWizard will add data members here
//}}AFX_DATA
// Attributes
public:
// Operations
public:
// Overrides
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(CAddin1View0)
public:
virtual void OnInitialUpdate();
protected:
virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
//}}AFX_VIRTUAL
// Implementation
protected:
virtual ~CAddin1View0();
#ifdef _DEBUG
virtual void AssertValid() const;
virtual void Dump(CDumpContext& dc) const;
#endif
// Generated message map functions
//{{AFX_MSG(CAddin1View0)
// NOTE - the ClassWizard will add and remove member functions here.
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
};
In the host application I have a window splitter and would like one of four views to show in the horizontal pane. I have created three test views in the host and am trying to gain access to the CFormView class using the method below. This is how I did it with the MFC DLLs. ???
I have removed some variable declaration and other non related code to make the test more readable.
I get the following error:
MainFrm.obj : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const CAddin1View0::classCAddin1View0" (?classCAddin1View0@CAddin1View0@@2UCRuntimeClass@@B)
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext)
{
if (!m_wndVerSplitter.CreateStatic(this,1,2)) // rows 1, columbs 2
{
TRACE0("Failed to create split bar ");
return FALSE; // failed to create
}
GetClientRect(&cr);
CSize paneSize(cr.Width(), nHorizonalSplitterLoc);
CSize paneSize1(cr.Width(), cr.Height() - nHorizonalSplitterLoc);
// CSize cVertpaneSize(cr.Width(), nVerticalSplitterLoc);
CSize cVertpaneSize(nVerticalSplitterLoc, cr.Height() - nHorizonalSplitterLoc);
// create a pContext pointer if it is NULL
if (pContext == NULL)
{
pContext = new CCreateContext;
}
// create the horizontal static splitter
// We are nesting the horizontal splitter into the right pane of the
// verital splitter. So we have to do some messin around here
// rows cols
m_wndHorSplitter.CreateStatic(&m_wndVerSplitter, 2, 1, WS_CHILD | WS_VISIBLE,
m_wndVerSplitter.IdFromRowCol(0, 1));
// create the top part of right pane of the splitter (row cols)
pContext->m_pNewViewClass=RUNTIME_CLASS(CMasConsoleTestListView);
pContext->m_pCurrentFrame = this;
m_wndHorSplitter.CreateView(0, 0, pContext->m_pNewViewClass, paneSize, pContext);
// We will set up the various forms that will be able to be set
// as the program is running. Note: The order of these view classes may
// be significant. We are doing some research. When you put the
// CTransactionFormView then we have some strange crashing!!
m_nView0 = m_wndHorSplitter.AddView(1, 0, RUNTIME_CLASS(CMasConsoleTestView), pContext);
m_nView1 = m_wndHorSplitter.AddView(1, 0, RUNTIME_CLASS(CMasConsoleTestView1), pContext);
m_nView2 = m_wndHorSplitter.AddView(1, 0, RUNTIME_CLASS(CMasConsoleTestView2), pContext);
// Forms below are in DLLs. We will need to get the handle for the
// resource in the DLL while the view is in use (selected)
hDLL = GetModuleHandle("Addin1.dll");
hEXE = AfxGetResourceHandle();
AfxSetResourceHandle((HINSTANCE) hDLL);
m_nAddin1View0 = m_wndHorSplitter.AddView(1, 0, RUNTIME_CLASS(CAddin1View0), pContext);
AfxSetResourceHandle(hEXE);
nCurrentHorizHeight = 123;
m_wndHorSplitter.SetRowInfo(0, nCurrentHorizHeight, nMinHorizHeight);
m_wndVerSplitter.RecalcLayout();
m_wndHorSplitter.RecalcLayout();
m_wndHorSplitter.SetActivePane(1,0);
return rc;
}
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
void CMainFrame::SetActiveView(int nViewIndex)
{
switch (nViewIndex)
{
case 0:
m_wndHorSplitter.ShowView(m_nView0);
break;
case 1:
m_wndHorSplitter.ShowView(m_nView1);
break;
case 2:
m_wndHorSplitter.ShowView(m_nView2);
break;
case 3:
m_wndHorSplitter.ShowView(m_nAddin1View0);
break;
case 4:
m_wndHorSplitter.ShowView(m_nAddin2View0);
break;
}
}
Again, I get the following error.
MainFrm.obj : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const CAddin1View0::classCAddin1View0" (?classCAddin1View0@CAddin1View0@@2UCRuntimeClass@@B)
When I comment out referecnes to the CAddin1View0 class then I'm ok. Any comments or ideas.
Thanks!
Chris
macgowan@pobox.com
Chris
macgowan@pobox.com
|
|
|
|
|
Hi ...
I have fixed the problem by adding the __declspec (dllexport) to the CAddin1View0 class definition. I forgot to add this. Then you have to include the Addin1.lib in the project and then the application will require the Addin1.dll to be present ... this defeats the purpose of using the ATL COM Addin ... Where I can unregister the component and the host application does not care that it is missing.
I will continue to search for a method to expose the pointer to the a CRuntimeClass using the COM interface. ???
Any ideas ??
Thanks,
Chris
<br />
#ifdef ADDIN1_DLL<br />
#define Addin1DLLSpec __declspec (dllexport)<br />
#else<br />
#define Addin1DLLSpec __declspec (dllimport)<br />
#endif<br />
<br />
class Addin1DLLSpec CAddin1View0 : public CFormView<br />
|
|
|
|
|
I've been beating my head against the wall trying figure this one out. I am trying to find a CTL when all that I have is it's "identifier". If I create the CTL using makeCTL, I can specify an identifier by entering text in the "prefix that identifies this CTL" edit box.
I have tried using CertFindCTLInStore with a find type of CERT_FIND_SUBJECT_STR and CERT_FIND_KEY_IDENTIFIER. Neither attempt has worked. Can someone point me at an appropriate example? I've posted a snippet below to short circuit some of the "back and forth" Q&A.
HANDLE storeHandle = NULL;
PCCTL_CONTEXT pCTLContext = NULL;
wstring textToFind;
wstring storeName;
if (argc != 3 )
{
wcout << TEXT("argc = ")<< argc << endl;
exit(-1);
}
storeName = argv[1];
textToFind = argv[2];
DWORD buffSize = 0;
if (storeHandle = CertOpenSystemStore( NULL, storeName.c_str()))
{
wcout << TEXT("The ") << storeName.c_str() << TEXT(" store has been opened. \n");
} else {
wcout << TEXT("The store was not opened.\n");
exit(1);
}
PCCTL_CONTEXT prevCTLContext = NULL;
pCTLContext = CertFindCTLInStore( storeHandle,
X509_ASN_ENCODING | PKCS_7_ASN_ENCODING,
0,
CERT_FIND_SUBJECT_STR,
textToFind.c_str(),
prevCTLContext);
if (pCTLContext != NULL)
{
} else {
wcout << TEXT("Unable to find cert with subject of '")<< textToFind.c_str() << TEXT("'") << endl;
}
if (!CertCloseStore(storeHandle, 0))
{
wcerr <<TEXT("Failed CertCloseStore\n");
exit(1);
}
Joseph Lightfoot
|
|
|
|
|
I've never done this but just looking at the documentation I would consider using CTL_FIND_ANY and then for each one using CertFindSubjectInCTL() to confirm that what I was searching for actually existed.
|
|
|
|
|
Viola!
That was PURE magic! Thanks!
What documentation did you look at? I missed that type completely. Also, I thought that CertFindSubjectInCTL was what you used to look at the entries. Does your "magic" documentation show more about this function than MSDN?
Joseph A. Lightfoot
"It's not my fault!"
|
|
|
|
|
Joseph.Lightfoot wrote: Does your "magic" documentation show more about this function than MSDN?
http://msdn2.microsoft.com/en-us/library/aa376067.aspx
That is the documentation for CertFindCtlInStore() which contains a table entry for the CTL_FIND_SUBJECT find type which contains a link to CertFindSubjectInCTL[^]
Perhaps I'm just lucky
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
