|
Win32
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
See the example here.
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Brandon T. H. wrote: How do you get a list of all files and folders
Not too difficult to find some suggestions[^].
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
You could use FindFirstFile and FindNextFile to enumerate files/folders in a specified directory/drive. Listing the Files in a Directory[^] shows an example using these two functions. You will also get file/folder attributes when the functions successfully return.
Write a recursive function so it will enumerate subdirectories.
An alternative is using Shell interfaces such as IShellFolder and IEnumIDList combined with some Shell functions like SHGetDataFromIDList and SHGetDesktopFolder. It's bit more complicated than the other one, but it's more flexible. Consider this approach if FindFirstFile/FindNextFile method doesn't fit your need.
Also, you mentioned that you need to put the list of files/folders into a box. Loading this kind of huge list of items takes a long long time using default Windows control settings. Take a look at Virtual List Control at About List-View Controls[^]. You will happy to see your executable run more smoothly than the others at the end.
You can also try to google your concerns as suggested by Richard MacCutchan. Appending your keywords with "MSDN" or "Codeproject" will normally show good results. 
|
|
|
|
|
You can use WMI class CIM_DirectoryContainsFile to list all the files and all information you need including compression type, last date accessed, date created type, size, path and much more; all 33 different items describing each file on all the drives on local or remote computer.
JohnCz
|
|
|
|
|
i'd wrote an active control that have a dialog.but i cann't to move it as mfc controls.Anyone to help!! thank you 
|
|
|
|
|
mir5465 wrote: ...active control that have a dialog.
Do you mean that you have an ActiveX control that is on a dialog?
mir5465 wrote: but i cann't to move it as mfc controls
Meaning what exactly?
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
int *pi;
{
int i = 3;
pi = &i;
}
std::cout << *pi << std::endl;
I figure that the *pi value in std:cout can not be trusted since i goes out of scope and the address of i can be used for other stuff. Is that correct?
Thank
|
|
|
|
|
Yep, that's right. It's also why you should never return references to local variables - what they're based on disappears at the end of the block they're declared in.
Cheers,
Ash
|
|
|
|
|
It depends on stack usage.
If you return a local var thats now out of scope to a func that eats the stack it will get munged. If not, it is still there, but its is risky of course.
Actually we found a windows bug that did just this. It returned a local var. This was OK till we hooked the func, and thus increased its tack usage.
In your case i is out of scope at code level, but is still on the stack since you havent returned from your func yet (your code is actually compiled with i on the stack just after pi).
--edit--
I see no one has responded. I guess an understanding of assembler (ie, the way code actually compiles) is totally foreign territory to todays 3G coders.
==============================
Nothing to say.
modified 19-Apr-12 2:43am.
|
|
|
|
|
Erudite_Eric wrote: It depends on stack usage.
AFAIK it doesn't so much depend on stack, but on the runtime libraries used: if they choose to invalidate a memory address as soon as it goes out of scope, then code like this will crash with an access violation. It may depend on compiler settings, but I've never seen code like that actually work on Windows XP or 7.
Then again I never deliberately tried 
|
|
|
|
|
No, it isnt to do with libraries, but the very way local variables are allocated, ie, on the stack. This is only unwound, upwards dont forget, when the func the variables are declared in returns. Thats when the memory can be reused, by calling another func that declares its own variables.
So if you look at assembler you will see stuff like ebp+4 being set to a value. This is a local variable. At the end you see a ret 4. This returns from the func and winds the stack back by the same number as the size of the local variables declared.
==============================
Nothing to say.
|
|
|
|
|
hello guys... I have this dialogbox whose name I am trying to get. I have added a new dialogbox to the project using Add->Resource, so this gets an ID automatically, in the resource.h file. But when I use MAKEINTRESOURCE macro by providing resource id to get its name, it does not return it. It gives an assertion. What can be wrong here? thnx for any input.
This world is going to explode due to international politics, SOON.
modified 18-Apr-12 1:11am.
|
|
|
|
|
overloaded Name wrote: It gives an assertion.
Which is? 
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
plz refer to my answer below 
This world is going to explode due to international politics, SOON.
|
|
|
|
|
MAKEINTRESOURCE does not get the name, it merely casts the integer value to a pointer. However, that is neither here nor there, the important question is what assertion you get and which line of code does it occur on.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
Assertion Shown: Debug Assertion Failed
Context of the program: actually I am adding CPropertyPages to CPropertySheet. Now when I pass the property page's IDD to CPropertyPage's constructor, there this macro can not cast this integer value to LPCTSTR (the resource type). Here is what the constructor looks like
CString1Dlg::CString1Dlg(CWnd* pParent ): CPropertyPage(CString1Dlg::IDD)
{
}
Now the point where it shows this assertion, looks like this.
CPropertyPage::CPropertyPage(UINT nIDTemplate, UINT nIDCaption, DWORD dwSize)
{
ASSERT(nIDTemplate != 0);
AllocPSP(dwSize);
CommonConstruct(MAKEINTRESOURCE(nIDTemplate), nIDCaption);
}
I debugged the application and know that nIDTemplate contains the ResourceId. Now MAKEINTRESOURCE here, does not convert this ID to corresponding resource type. Thats why I asked this question. During debuggin I came to know that MAKEINTRESOURCE is not working but in the first place, the assertion is shown in afxwin1.inl - line 24, where code looks like this.
_AFXWIN_INLINE HINSTANCE AFXAPI AfxGetResourceHandle()
{
ASSERT(afxCurrentResourceHandle != NULL);
return afxCurrentResourceHandle;
}
I hope I was able to clear the picture.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
overloaded Name wrote: Context of the program: actually I am adding CPropertyPages to CPropertySheet.
Which you should probably be doing in the sheet's constructor. Something like:
CMySheet::CMySheet(CWnd* pParentWnd , UINT iSelectPage )
:CPropertySheet(IDS_CAPTION_FRUITS, pParentWnd, iSelectPage)
{
AddPage(&m_page1);
AddPage(&m_page2);
AddPage(&m_page3);
AddPage(&m_page4);
}
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
DavidCrow wrote: Which you should probably be doing in the sheet's constructor
Yes. I have done that too. But eventually, the assertion is shown using that method too.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Then something else is fundamentally wrong. Other than calling AddPage() in the sheet's constructor, and creating a dialog template for each page, that's all there is to it. Since you are not getting a compiler/linker error, we can assume there is a CPropertyPage-derived object in the sheet's .h file for each page you want added.
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
class CString1Dlg : public CPropertyPage
{
public:
CString1Dlg(CWnd* pParent = NULL);
enum { IDD = IDD_STRING1_DLG };
Comparison of this code with previous one can be done here.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Are you working with a DLL or EXE?
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
EXE . This is solved now. As I said in earlier posts, Resource was missing. I was instantiating my CPropertySheet class in the wrong place. I was doing so in the constructor of my APP file like this.
CxyzApp::CxyzApp()
{
MySheet sheet = new MySheet(_T("My Sheet"));
}
But this was wrong. Controls are not loaded until InitInstance() is called. I should have instantiated my sheet class in the InitInstance() of APP like this
BOOL CxyzApp::InitInstance()
{
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
MySheet = new CEmplSheet(_T("My Sheet"));
if(MySheet != NULL)
m_pMainWnd = MySheet;
}
Thank you for you time.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
overloaded Name wrote: I should have instantiated my sheet class in the InitInstance() of APP like this
Or you could have waited to construct the sheet object until it was actually called for. For example:
void CxyzApp::SomeFunction( void )
{
CEmplSheet sheet(_T("My Sheet"));
sheet.DoModal();
}
"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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
overloaded Name wrote: Now MAKEINTRESOURCE here, does not convert this ID to corresponding resource type.
It's not supposed to convert it to anything, it merely casts its type to the appropriate LPSTR so that the receiving function's definition is satisfied. The key issue is whether the value is correct and identifies a valid dialog template.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
