|
You need to use manifest, there are number of articles that shows how to use them here in CP.
I'll write a suicide note on a hundred dollar bill - Dire Straits
|
|
|
|
|
The usual technique of traversing a folder and all it's sub-folders is pretty commonplace, but it suffers from the fact that the stack just might run out (sure, we can specify the stack size in vc, but we dont want to hog a lot of memory for the stack!).
What is a good way to use a non-recursive loop to traverse folders? Is there no solution apart from using "goto" statements? 
Bikram
|
|
|
|
|
Bikram Singh wrote:
What is a good way to use a non-recursive loop to traverse folders? Is there no solution apart from using "goto" statements?
Sure there is. Just call SetCurrentDirectory() with each directory encountered.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Do you have some source code for the entire problem?
Bikram
|
|
|
|
|
No. I've personally not ever used the function. It's a hold-over from the Unix world and its single-threaded environment. For Windows and multi-threaded applications, if another thread is running, the "current directory" is constantly changing for all of the threads. For anything that requires folder traversal, I always use recursion. Can you explain in more detail your hesitation in using this methodology?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
If your program in a Win32 app with a message loop you could use PostMessage to do the whole thing asynchronously, and then in the main function use a event loop to wait till it was all done. Dunno how efficient that is 
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Search in this board for an algorithm I posted a week ago or so to recurse a directory. This uses SetCurrentDirectory() and uses minimal stack.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I tried this for almost an hour yesterday because I knew I had just recently seen an example. All that I could find was a post from coremn.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
It's pretty easy. Something like:
<br />
CStringList dirs, files;<br />
CString dir;<br />
CFileFind ff;<br />
BOOL ok;<br />
<br />
dirs.AddTail("c:\\work\\lisp");<br />
<br />
while (!dirs.IsEmpty())<br />
{<br />
dir = dirs.RemoveHead();<br />
if (ff.FindFile( dir + "\\*.*" ))<br />
{<br />
do<br />
{<br />
ok = ff.FindNextFile();<br />
if (ff.IsDots()) continue;<br />
if (ff.IsDirectory())<br />
{<br />
dirs.AddTail( ff.GetFilePath() );<br />
continue;<br />
}<br />
files.AddTail( ff.GetFilePath() );<br />
}while (ok);<br />
}<br />
}<br />
--
Joel Lucsy
|
|
|
|
|
Hi, I have a question.
Is there some mode in MFC to use the class CFileDialog inside a CPropertySheet ?
The goal can be extended to other CDialog classes that is necessary to use as CDialog but also as CPropertyPage without duplicate the code inside.
Thanks
Bye from Maxer
|
|
|
|
|
Maxer wrote:
Is there some mode in MFC to use the class CFileDialog inside a CPropertySheet ?
Do you mean from a CPropertyPage? If so, this should work:
CFileDialog fd(TRUE);
if (fd.DoModal() == IDOK)
{
...
}
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
No, what I would want is to see the CFileDialog in a tab of a CPropertySheet.
Is it possible?
Bye from Maxer
|
|
|
|
|
Maxer wrote:
No, what I would want is to see the CFileDialog in a tab of a CPropertySheet.
What do you think the tabs are? They are CPropertyPage objects. A CPropertySheet is comprised of two or more (yes, you can have one but that makes no sense) CPropertyPages.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Do you have try to add the CFileDialog object to a CPropertySheet object ?
CFileDialog is a CDialog derived class and not a CPropertyPage derived class.
Bye from Maxer
|
|
|
|
|
Maxer wrote:
Do you have try to add the CFileDialog object to a CPropertySheet object ?
No, the CFileDialog object is instantiated and used in one of the CPropertyPages.
Maxer wrote:
CFileDialog is a CDialog derived class and not a CPropertyPage derived class.
Of course. Did I imply otherwise?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Maybe that I'm not explained in the right way 
I know that a CFileDialog object can be created and used inside a CPropertyPage (for example when a button is pressed), but what I would want is to have a tab of the CPropertySheet that is a file browser (CFileDialog is a file browser so I would want to use it without to rewrite a new custom CPropertyPage class).
My question can be extended to all the times that is necessary to use a custom dialog that do something, but also to do the same things in a CPropertySheet tab. Is it possible to use a CDialog as CPropertyPage or a CPropertyPage as a CDialog ? My goal is to reuse all the code that is possible for fast maintenance of my project.
Bye from Maxer
|
|
|
|
|
What you are after cannot be achieved, at least that I know of. Each CPropertyPage object is "connected to" a dialog template in the project's resources. CFileDialog has its own dialog template in some other DLL (dialogs 1547 and 1552 of comdlg32.dll).
I don't see anything wrong with, on one of the tabs, having an edit control and a Browse button where, when clicked, would bring create a CFileDialog object. When a valid file is selected from that dialog, the edit control would reflect the selected file.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I want to code the Status Bar so that it displays the co-ordinates of mouse when i move the mouse. i created a pane for it and tried to handle the onmousemove event in the CMainFrame class but it didnt work.
Plz help me with it
|
|
|
|
|
|
hi:maybe ,i can help you some:the program i have run well,
void CMainFrame::OnViewStatusBar()
{
m_wndStatusBar.ShowWindow((m_wndStatusBar.GetStyle()&WS_VISIBLE)==0);
RecalcLayout();
}
void CMainFrame::OnUpdateViewStatusBar(CCmdUI* pCmdUI)
{
pCmdUI->SetCheck((m_wndStatusBar.GetStyle()&WS_VISIBLE)!=0);
}
void CMainFrame::OnUpdateLeft(CCmdUI* pCmdUI)
{pCmdUI->Enable(::GetKeyState(VK_LBUTTON)<0);
}
void CMainFrame::OnUpdateRight(CCmdUI* pCmdUI)
{
pCmdUI->Enable(::GetKeyState(VK_RBUTTON)<0);
}
void CStatusbool514View::OnMouseMove(UINT nFlags, CPoint point)
{
//CView::OnMouseMove(nFlags, point);
CString str;
CMainFrame* pFrame=(CMainFrame*)AfxGetApp()->m_pMainWnd;
CStatusBar* pStatus=&pFrame->m_wndStatusBar;
if(pStatus)
{
str.Format("x=%d",point.x);
pStatus->SetPaneText(0,str);
str.Format("y=%d",point.y);
pStatus->SetPaneText(1,str);
}
}
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{.......
if (!m_wndStatusBar.Create(this,
WS_CHILD|WS_VISIBLE|CBRS_BOTTOM,ID_MY_STATUS_BAR)||
!m_wndStatusBar.SetIndicators(indicators, sizeof(indicators)/sizeof(UINT)))
{
TRACE0("Failed to create status bar\n");
return -1; // fail to create
}
}
static UINT indicators[] =
{
ID_SEPARATOR,
ID_SEPARATOR,
ID_INDICATOR_LEFT,//(3)(4)you yourself define in string table
ID_INDICATOR_RIGHT,// status line indicator
};
|
|
|
|
|
Hi
In the past thread, i asked about C++ exception handling using __try, __except and _try __finally blocks to safeguard my codes against carelessness programming as well as unforeseen events... I am using on a embedded WinCE platform
after almost completing my module, i find that the size of the programs grows a lot, from the initial 10k to abt 100k. Is there anyway to minimise the size and at the same time without compromise reliably.
The size is critical as my program may need to upgrade through IR and if it is huge, time is a factor but i can't sacrifice for a reliable program
any help pls??
thanx
|
|
|
|
|
IceBerG71 wrote:
...the size of the programs grows a lot, from the initial 10k to abt 100k
Are you relating the growth directly to the inclusion of exception handling?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
Yes, the size was a result of adding the excpetion blocks, maybe i use too extensive, every functions i use the exception to protect the codes in case there is any errors resulting in unforseen cases. initially, it helps me in debugging, after solving the bugs, so far, the exception was never resulted but frankly speaking, it is hard to predict what user can do to it since there is user entry portion.
I checked MS website, it was indicated that the __try __ except is WIN32 exception handling. and they also indicated not all cases can be captured by the __try block.
|
|
|
|
|
If size is critical, don't use exceptions for careless programming, only to actually catch critical errors outside your control. You could also drop C++ exception handling entirely and use only Win32 structured exception handling.
(My opinion may be unpopular, but C++ exception handling itself does not ensure a reliable program. It helps clean up the stack, but in the end, is just another error handling mechanism. I use exceptions very sparingly; mainly where other error handling techniques grow more cumbersome than if I had used exceptions.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
FWIW '__try/__except/__finally' aren't C++ exception handling, it's (AFAIK) an MS enhancement to their C and C++ compilers that allows code to be generated for Win32 Structured Exception Handling. In the Windows world C++ exceptions are built on top of this.
This obviously doesn't help you, but getting the terminology right cannot hurt...
Paul
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
