VoiceOfExperience

With VS2005/MFC in a dialog, I am using a file open common dialog to allow the user to select a file. The code for this is

char fileTypes[]=_T("My files (*.fil)|*.fil|All files|*.*||");

CFileDialog dlg(TRUE,_T("fil"),_T("*.fil"),OFN_CREATEPROMPT|OFN_HIDEREADONLY|OFN_EXPLORER,fileTypes);

dlg.m_ofn.lpstrTitle=title;

dlg.m_ofn.lpstrInitialDir=startPath;

int response=dlg.DoModal();

Preceding execution of this code, there is a single thread. Following the return from DoModal, there are 4 more threads.

1) How do I use the VS2005 interface to find out more about these threads All I can see in the Threads window is the address of the threads (7C0eb94 for all 4), and the thread ID, which means nothing to me.

2) Any ideas why these threads exist They are causing a memory allocation problem later on.



Re: Visual C++ General 4 threads created by CFileDialog::DoModal

VikasKumar

TO know more about these threads I belive you would need symbols that should help the debugger to translate the addresses into meaning full names.

You can configure your debugger to download Microsoft Symbols from http:\\msdl.microsoft.com/download/symbols

PLease note, you might see significant delay as the debugger would try to download the symbols to local drive and then make use of it.





Re: Visual C++ General 4 threads created by CFileDialog::DoModal

TilakGopi

Hi,

I may not give the info as much as u require.But i want to let u know few observations on these threads of CFileDialog,AFAIK.

Observations:

1)Ya, when the dialog is opened 3 more threads are being added to existing application's thread count.After closing also, count remains same for a maxmimum of 1 minute only, yes, observe, once the file dialog is closed, the thread count will be decreased by 2(in the duration of max 1 minute),if u don't launch the dialog again.And then the thread count reamins constant(i observed it for 5 minutes as so , but it still reamained same).

2)Ya, when the dialog is opened 3 more threads are being added to existing application's thread count.But if u might have observed , that(max) thread count is constant from that time onwards (till other window or dlg or control creates any other thread) , eventhough if u open the filedialog many times.

R u getting me What i mean to say is,

U have launched the file dialog, now thread count has become 4,close it ,launch it, do this closing and launching many number of times ,the max thread count is 4 only.So there are no threads created everytime the filedialog opened,they are created for the first time only.

So , what i can conclude from these observations is , there will be no no memory allocation problem since the threads are created ,maintained and destoyed by the application itself.

2) Any ideas why these threads exist They are causing a memory allocation problem later on.

These threads may be created for the internal use of the filedialog.We don't need to bother about them and i'm sure they won't create any memory allocation problem.

Thanx,

Ch.T.Gopi Kumar.






Re: Visual C++ General 4 threads created by CFileDialog::DoModal

VoiceOfExperience

Knowing that the symbols are available is useful in general, but I don't think it would help in this case. I want to know what the purpose of these threads is, and how long they will last. Also, the amount of memory and stack allocated to each.



Re: Visual C++ General 4 threads created by CFileDialog::DoModal

VikasKumar

You need not worry about the 3 additional threads being created when we show the FileOpen Dialog.

I cannot tell exactly what is the use but can defently provide my thought about the use.

Looking at the created threads one of them seems to be doing Timer Activity, another one loads SHLWAPI and browseui, and the third thread is a thread waiting on the IOCompletion port.

If i understand, The timer thread is to update the browser UI and the content of the browser UI, SHLWAP and BrowserUI probably keeps a watch on any modification dones outside this Opened Dialog and the third threads seems to be a helper thread used for syncronization.

Why is that you are so conserned about these threads, I doubt that these thread would cause any leaks or problem to the application.

Obviously these threads are resuable threads, so they do not die immediatly, as creating a thread is a costlier operation for optimization perpose it's good to keep the thread around for a while, may be you visit it again :)

Hope you have some answer now.