|
|
Anonymous wrote:
it finds one occurance of (even though there are also several of them).
Be aware that CString::Find only searches for the _first_ occurence of the substring, so you need to shrink the searched string (file in your example) after having found the first occurence. Could you post some more code ?
Anonymous wrote:
even though I know that there are several occurances of it (I checked the file),
And did you check the string you have read in with the debugger ?
~RaGE();
|
|
|
|
|
Anonymous wrote:
...my program is set to work with unicode with a _T() macro used to declare the string.
Which means nothing if you have not defined UNICODE and _UNICODE.
Anonymous wrote:
Can someone tell me if this is indeed the case...
No, that is not the case, unless you explicitly supply a second parameter.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hello,
In the InitInstance of my CWinApp, I simply create an CPropertyPage by
just simply
CPropertyPage p(SOME_RESOURCE_ID);
just after finished creation, I make a call on SetWindowTile by
p.SetWindowTitle(_T("Opps"))
Whenever the SetWindowTitle code being executed, an illegal operation
will be thrown. I can avoid this problem if I place the SetWindowTitle
in InitDialog of the property page. But that is not I want.
May I know why calling the SetWindowTitle just after the creation of
dialog/ property page will cause illegal operation. How I can solve
this?
Thanks.
|
|
|
|
|
Property pages do not exist until that are "activated" for the first time. The documentation for CPropertySheet::AddPage() states:
"AddPage adds the CPropertyPage object to the CPropertySheet object’s list of pages but does not actually create the window for the page. The framework postpones creation of the window for the page until the user selects that page."
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
p.m_psp.dwFlags|=PSP_USETITLE;
strcpy(p.m_psp.pszTitle,"Opps");
or even
p.m_psp.dwFlags|=PSP_USETITLE;
p.m_psp.pszTitle="Opps";
Could this solve the problem ? I think it crashes only because the window does not exists, and SetWindowTitle asserts the window handle somewhere.
~RaGE();
|
|
|
|
|
The property page has to be created first... the constructor just initializes the class, but not the window itself -> without window, no window title change!
Don't try it, just do it! 
|
|
|
|
|
Hi all,
I have this tiny dll which exports a single function (as extern "C")
looking like this:
<br />
void test123(int *t)<br />
{<br />
*t = _open("c:\\feedback.xml", _O_RDONLY | _O_TEXT);<br />
}<br />
Now the problem is: if I use this in a test program like this:
<br />
test123(&fd);<br />
FILE* fp = _fdopen(fd, "rt");<br />
I get a pretty weird crash in _fdopen(). I also tried to use the fopen call in the test123 function and let it return the FILE*. Now it won't crash but I can't read from it either. Any body got an idea what's going on?
(what I'm actually trying is to read from a buffer through a FILE*. I'm creating a pipe, write the contents of the file to it, pass on the filedescriptor of the read end and transform it to a FILE* with _fdopen. So if anybody can provide me with another way to do this, plz let me know. But it is very important that I can use a FILE* to read from the buffer. Has to do with a porting job...)
I used to have a life ... now I have a computer
|
|
|
|
|
Shouldn't you be checking the value of fd to make sure it is not -1? This would indicate that _open() failed.
To eliminate the DLL as part of the problem, put the calls to _open() and _fdopen() in the same spot. Does it work then?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
If i put the calls in the same location, it works perfectly well. I did check the return value. It was 3, as one would expect.
I used to have a life ... now I have a computer
|
|
|
|
|
bisserke wrote:
I did check the return value. It was 3, as one would expect.
Why would you expect the return value of _open() to be 3? Since when do handles have known values?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
because 0,1,2 are default so normally, in this little app, the first one free is 3.
I used to have a life ... now I have a computer
|
|
|
|
|
IIRC, file handles are local to the instance of the C-runtimes in which they are created. if your DLL and your calling program are not using the same instance of the C-runtimes, they cannot share file handles.
this applies to memory too: malloc/new across DLL boundaries = bad, if the DLL and EXE use different CRT instances.
so.. are your DLL and EXE statically linking to the CRT or, using dynamic linking ?
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Well they are dynamically linked. So I'm gonna look into this. Looks like a good lead.
(I'm actually pretty new to Windows environments...)
thx
I used to have a life ... now I have a computer
|
|
|
|
|
bisserke wrote:
Has to do with a porting job.
If you're going for portability, then you should probably just put the functionality in a standard library (which has to be staticaly linked).
If you are putting the functionality into a DLL then the DLL should be handling all the file I/O. That is it should export the functions for reading/writing and any other file related activity required.
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
I have an application that launches a wizard based property page that contains N property sheets. All of the pages are added to the property sheet at initialization.
At one point in the wizard, it has a group of radio buttons that determine which sheet should be shown next. I am able to get to the next page without a problem. However, when I press back, it should skip all the pages in between and go back to the radio button selection page. I am using the following code to go back:
LRESULT CPropPageOptions::OnWizardBack() <br />
{<br />
CPropSheet* pParent = (CPropSheet*)GetParent();<br />
ASSERT_KINDOF(CPropSheet, pParent); <br />
<br />
switch(pParent->m_nScheduleType)<br />
{<br />
case 1:<br />
return pParent->SetActivePage(&pParent->m_pageWeekly);<br />
case 2:<br />
return pParent->SetActivePage(&pParent->m_pageMonthly);<br />
case 3:<br />
return pParent->SetActivePage(&pParent->m_pageOneTime);<br />
default:<br />
return pParent->SetActivePage(&pParent->m_pageDaily);<br />
}<br />
return TRUE;<br />
<br />
}
This doesn't seem to work correctly. It goes back through all the pages one at a time. Is there any way to make this work correctly, short of redesigning this so the pages are added as they are needed?
Brigg Thorp
Senior Software Engineer
Timex Corporation
EDITED - the returns in the switch statement are now present.
|
|
|
|
|
You forgot to break. If that's exactly what you wrote, cut-and-pasted, it will always drop through the bottom of each case, meaning that m_pageDaily is the page shown.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
Actually, I had returns in there...don't know why they didn't show up. This is how it actually is.
LRESULT CPropPageOptions::OnWizardBack()
{
CPropSheet* pParent = (CPropSheet*)GetParent();
ASSERT_KINDOF(CPropSheet, pParent);
switch(pParent->m_nScheduleType)
{
case 1:
return pParent->SetActivePage(&pParent->m_pageWeekly);
case 2:
return pParent->SetActivePage(&pParent->m_pageMonthly);
case 3:
return pParent->SetActivePage(&pParent->m_pageOneTime);
default:
return pParent->SetActivePage(&pParent->m_pageDaily);
}
return TRUE;
Brigg Thorp
Senior Software Engineer
Timex Corporation
|
|
|
|
|
Brigg Thorp wrote:
It goes back through all the pages one at a time
Are you aware of that :
Returned Value (of OnWizardBack):
0 to automatically advance to the next page; –1 to prevent the page from changing. To jump to a page other than the next one, return the identifier of the dialog to be displayed.
So be careful to what you actually return, because pParent->SetActivePage(); is always a BOOL.
~RaGE();
|
|
|
|
|
I figured out what the problem was. I needed to set the active page first, then return -1 to tell the base class to not change the page, since I already did. Code as follows:
LRESULT CPropPageOptions::OnWizardBack() <br />
{<br />
CPropSheet* pParent = (CPropSheet*)GetParent();<br />
ASSERT_KINDOF(CPropSheet, pParent); <br />
<br />
switch(pParent->m_nScheduleType)<br />
{<br />
case 1:<br />
pParent->SetActivePage(3);
break;<br />
case 2:<br />
pParent->SetActivePage(4);
break;<br />
case 3:<br />
pParent->SetActivePage(5);
break;<br />
default:<br />
pParent->SetActivePage(2);
}<br />
<br />
return -1;<br />
}
Regards,
Brigg Thorp
Senior Software Engineer
Timex Corporation
|
|
|
|
|
I had some trouble with my app because it allocates a lot of memory. The longer you use it the more memory was eaten away. After searching for a reason I endet up with CFindFile as the only reason for that.
I have a loop and after deleting all but the CFileFind calls it is the only think that keeps running and allocating memory. Unfortunately CFileFind seems to not release the memory it uses. I tried everything:
CFindFile* findfile=new CFindFile();<br />
findfile->Close();<br />
delete findfile;
doesn't release any of the allocated memory. Can someone help me? How can I free the allocated memory. Is there a alternate way to search for files in a directory?
|
|
|
|
|
There is no reason to use a heap variable here. Use a stack variable and your memory-related problems will stop.
ryuki wrote:
doesn't release any of the allocated memory.
Actually it does, but you are confused as to what happens with memory once it is freed. If you are using Task Manager to watch your program's memory drop after each call to free, you will surely be disappointed.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I work under Win98 and use the systemmonitor for viewing allocated memory. Its not easy to say but there seems to be more to the memory issue than expected. I managed to find another source of consuming memory. It is a little part including SHGetFileInfo. And that small codebit causes much more trouble than all other together. It seems that SHGetFileInfo allocates memory too. But you can't see it at the systemmonitor. It eats all of it with time and at a single point I can't create threads anymore or some functions like StretchDIBits doesn't work properly because there is no memory anymore. I get a lot of "Not enough memory" errors allthough all ressourceviewers say there are more than 100 MB of free memory still there.
I can give you the small code example:
<br />
SHFILEINFO sfi;<br />
UINT uFlags = SHGFI_SYSICONINDEX | SHGFI_DISPLAYNAME | SHGFI_ICON | SHGFI_SMALLICON;<br />
if ( SHGetFileInfo ( tmp, 0, &sfi, sizeof(SHFILEINFO), uFlags ))<br />
m_ctrPathFrom->InsertItem ( npos, sfi.szDisplayName, sfi.iIcon );<br />
Thats all. I looked at the documentation but it says nothing about freeing the structure or something. Does someone know what to do?
And you can be believe me, i traced the cause of the memory issue to that single if-line.
I hope someone can help.
|
|
|
|
|
From MSDN:
[quote]
Remarks
If SHGetFileInfo returns an icon handle in the hIcon member of the SHFILEINFO structure pointed to by psfi, you are responsible for freeing it with DestroyIcon when you no longer need it.
[/quote]
sig test
|
|
|
|
|
Thank you for the hint. I use the standart documentation, the msdn library coming with VC++ 6. Next Time I will check the online docu too.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
