|
By the if...loop you mean the following?
if (lastFileOpenPath.GetLength() > 0)
{
openDlg.m_ofn.lpstrInitialDir = lastFileOpenPath;
}
If so, yes. I did a step over and I was able to see it being executed. After it comes out of the if then the DoModal function throws and assert error.
About lastFileOpenPath, yes is pointing to a directory in the machine. I'm able to open the file selected by the open file dialog. But I have to click Ignore when I get the assert error.
Thanks,
Luis E. Cuadrado
 )
|
|
|
|
|
wait a minute ! u r assigning a CString to a LPCTSTR (openDlg.m_ofn.lpstrInitialDir = lastFileOpenPath)..i guess u have to do a casting to do that ??
There are no failures; there are only extended learning opportunities.
|
|
|
|
|
What is it ASSERTing on?
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
It is ASSERTing in the DoModal function in the DLGFILE.CPP. The ASSERT comes out after selecting a file from the Open Dialog.
This is where is ASSERTing on in the DLGFILE.CPP:
if (nResult)
ASSERT(pThreadState->m_pAlternateWndInit == NULL); <-- HERE
pThreadState->m_pAlternateWndInit = NULL;
when I check the Developer Studio's call stack, it's comming from here:
if (lastFileOpenPath.GetLength() > 0)<br />
{<br />
openDlg.m_ofn.lpstrInitialDir = lastFileOpenPath;<br />
}
int nResult = openDlg.DoModal(); <--- HERE
I hope this helps.
Thanks,
Luis E. Cuadrado
 )
|
|
|
|
|
This is probably a dumb request, but can you post the declaration of the openDlg variable?
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
No problem. This is pretty much how the source file looks like:
CFileDialog openDlg;<br />
.<br />
.<br />
.<br />
if (lastFileOpenPath.GetLength() > 0)<br />
{<br />
openDlg.m_ofn.lpstrInitialDir = (LPCTSTR)lastFileOpenPath;<br />
}<br />
int nResult = openDlg.DoModal();
Thanks,
Luis E. Cuadrado
)
|
|
|
|
|
I'm not familiar with the code that's failing the assertion but I read through it a bit and it seems like pThreadState->m_pAlternateWndInit is not NULL whenever the OFN_EXPLORER flag is set in the m_ofn member. Are you setting that flag yourself, by any chance? If so, try not setting it and see if it makes a difference.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
I checked and I found out that the person that wrote the code, was setting the OFN_EXPLORER tag. I commented that part out and it doesn't make a diference. It still fails the assertion.
Thanks for your help!!
Best regards,
Luis E. Cuadrado
)
|
|
|
|
|
OK, here's one last stab at this issue.
Is the dialog box being created in a separate thread? If so, is it using a parent window which was created in a different thread? This may be the problem. MFC does not support related windows being created accross different threads -- I forgot exactly why, but someone here may shed some light.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Hi All !
I have this piece of code working fine on NT but drwas nothing on Windows 2000, any idea. Basically, it draws a rectangle on a dialog.
<br />
CClientDC dc (dlg);
dlg->GetClientRect (&rect);
CBrush brush (RGB (192,192,192));<br />
dc.SelectObject(&brush);<br />
<br />
dc.Rectangle(x_base+(d*20),y_base+(c*30),x_base+20+(<br />
|
|
|
|
|
i just ran that piece of code on Win2k and works fine..i tested with coordinates (0,0,100,100)..
just check ur co-ordinates ie [dc.Rectangle(x_base+(d*20),y_base+(c*30),x_base+20+(]
may the co-ordinates are just not "inside" the dialog..
There are no failures; there are only extended learning opportunities.
|
|
|
|
|
They are inside because when I run the same code on NT, I see them, so this is funny...
Thank you anyways !
|
|
|
|
|
wait a minute ! hope i am not confusing u here..its been a long time since i had worked on such stuff..
could it be due to screen resolution..because of things like screen co-ordinates or client co-ordinates..ohhhh i am so forgetful...
There are no failures; there are only extended learning opportunities.
|
|
|
|
|
In that case using ScreenToClient() should solve it.
Regards,
Griffith
Everything you say will be misquoted, ripped out of context and used against you.
|
|
|
|
|
I wrote this dialog app and after it runs for awhile it just stops updating all the objects on the screen. What I mean by not updating is that some of the object just stop appearing or are only drawn partially. I have many pages in this dialog and they mostly just have large buttons on them. I'm not calling wm_paint or messing with any of the draw functions, I have just let Windows handle that.
Also, I noticed that some of the drop downs instead of having a down arrow it will display a "6".
Any idea on how I can make sure that everything gets drawn on the screen?
|
|
|
|
|
i am not really sure of the answer..just a guess..
Could you check if ur app is leaking memory..could u check the taskmanager to see ur app's mem utilization ?
There are no failures; there are only extended learning opportunities.
|
|
|
|
|
Make sure that the application is not storing huge amount of data in memory and continue adding more data. The program could have memory leaks.
Check task manager and make sure the size of the process in more is consistant and does not increase dramatically.
Kuphryn
|
|
|
|
|
It looks to me like a resource leak, but you say you're not using the GDI functions. Are you sure about this? Maybe it's not your code but someone else could have added drawing functionality in there you don't know about.
Another idea that comes to mind is if your app opens and closes the dialog but does not properly destroy it whenever it gets closed. In other words, it may look like it's gone, but it remains hidden and the resources are not released.
That's all I can offer. Good luck!
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
These all sound like good suggestions. I have been running some test to see if memory changes significantly, but haven't seen this happen.
On all of the dialogs that are called I do a delete() when I close them. I've check and every page is done this way.
Is a particular area I can look at in the debugger to see what is going on?
Thanks...
|
|
|
|
|
Well, MFC has a built-in mechanism for reporting memory leaks when the app exits from the debugger. In other words, run the app inside the debugger (F5), use it for a while, and the exit out of it. If there are memory leaks, you'll get a listing on the Output window showing you the locations of where memory was allocated which was never freed.
Also, you say you do a delete() when you close your dialog boxes. Why? Can you show some sample code of how you're creating/destroying your dialog boxes?
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Hello,
I posted a question yesterday about loggin a text fle from with in a UI Thread.. Anyway, I started logging all the threads actions all the way up to ExitThread and found no problems at all.. I think my problem is that I create the thread and some times the ResumeThread doesn't really resume the thread. It gets created then it sits there. Which causes a bunch of extra threads that are on my process doing nothing.. Is there anyway to ensure that the thread has resumed and if not just kill it?
Heres an example of how I am starting up the threads...
n = 10;
while(n > 0)
{
CConnectThread* thread = (CConnectThread*)AfxBeginThread(RUNTIME_CLASS(CConnectThread),
THREAD_PRIORITY_NORMAL,
0,
CREATE_SUSPENDED);
thread->m_strMessage = strMessage;
thread->m_strDns = strDns;
thread->m_iPort = iPort;
thread->m_bAutoDelete = TRUE;
thread->ResumeThread();
n --;
}
Thanks,
Rob
|
|
|
|
|
Check the return value from ResumeThread!
DWORD ResumeThread( );
Return Value
The thread’s previous suspend count if successful; 0xFFFFFFFF otherwise. If the return value is zero, the current thread was not suspended. If the return value is one, the thread was suspended, but is now restarted. Any return value greater than one means the thread remains suspended.
van padoea
|
|
|
|
|
Thanks for the fast reply.. I should have looked for a return value before posting..
Thanks again,
Rob
|
|
|
|
|
How can I get the current line of a xml element / node ?
What I mean is the current line of a xml node / element in the xml file, like the get_line() function of the IXMLDOMParseError return.
I read some attributes of a xml node / element and check if they are in the possible range (eg. - 100 < attribute < +100). If the attribute is not in the range I want to display an error with the line, where I read the attribute / node / element!
I am working with the MSXML DOM parser!
Daniel 
---------------------------
Never change a running system!
|
|
|
|
|
No you cannot do that (or at least I think you cannot). Basically the XML is just a string. It may or may not have carriage returns. Both are valid. The well formatted XML you see in your editor is a display and not necessarily the actual XML text.
So:
<SAMPLE>
<BLAH>jhgjsdgf<BLAH/>
<BLAH2>jhgjsdgf<BLAH2/>
</SAMPLE>
Is the same as
<SAMPLE><BLAH>jhgjsdgf<BLAH/><BLAH2>jhgjsdgf<BLAH2/></SAMPLE>
You can get position() but that will simply tell you the element position within the current collection. If you nodes/elements have any form of an ID then you can log the XPATH. This way a user could use some XML editor and apply the XPATH. Or put line numbers as an attribute to your elements/nodes and then report that attribute.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
