Problem with the ListView control [modified]

Ankit Rajpoot

Hello everybody, My application uses a ListView control to display a list of files. Everything works fine except that when I set the View property of the ListView to View.List, the list appears but, here's[^] a screenshot of how it looks. I can't understand, why the filenames are condensed and appended with a "...". I've searched google and msdn, but couldn't found a solution for the problem. The Large Icon[^] and Details Views[^] are working perfectly. Just the list view is misbehaving. My second problem is regarding a BackgroundWorker. I have a BGWKR that I'm using to perform a database transaction. Now the problem is that the user may close the form while the transaction is in progress. To handle this, I added code to the form's closing event handler, to inform the user that a transaction is active and ask him/her, whether to cancel it. If the user affirms, then a call to BGWKR.CancelAsync() is made. Here's the form_closing event.

private void WndSearchResults_FormClosing(object sender, FormClosingEventArgs e)
{
if (bgDatabaseSearcher.IsBusy)
{
if (MessageBox.Show(Resources.msgSearchActive_WindowClosing, "Question",
MessageBoxButtons.YesNo, MessageBoxIcon.Question) == DialogResult.No)
{
e.Cancel = true;
return;
}
else
{
bgDatabaseSearcher.CancelAsync();
while (bgDatabaseSearcher.IsBusy)
Thread.Sleep(500);
}
}
}

Here's the BGWKR's Do_Work event

private void bgDatabaseSearcher_DoWork(object sender, DoWorkEventArgs e)
{
VFS virtualFS = new VFS();

        foreach (ListEntry entry in imagesToSearch)
        {
            try
            {
                virtualFS.OpenConnection(Path.Combine(AppSettingsManager.ImagesDirectory, entry.imageDbPath));
                foreach (VFSSearchTerm searchTerm in termsToSearch)
                {

Luc Pattyn

Hi, 1. there seems to be no easy solution. This article[^] is probably the best approach, however I never tried it. 2. I did not understand the problem; also the post is too wide for easy reading. :)

Luc Pattyn [Forum Guidelines] [My Articles]

- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets

Ankit Rajpoot

My apologies for the post being too much wide. I've reformatted it now.

Excuse me for buttin' in, but I'm interrupt driven.

Luc Pattyn

Hi, much better now. I still don't see what your problem #2 is, you say it works?? I do have 3 comments: 1. assuming lViewSResultsBrowser is a ListView, you are not allowed to perform a Groups.Add() operation (or any other Control operation) on it since Controls are not thread-safe. Without an InvokeRequired/Invoke construct it may hang your GUI temporarily or forever. 2. IMO all that is required for the cancellation is a simple if (bgDatabaseSearcher.CancellationPending) break; since that will bring you in the finally block, hence close the connection and return. 3. I don't particularly like the loop while (bgDatabaseSearcher.IsBusy) Thread.Sleep(500); since it makes your GUI hang for as long as the BGW takes; you have made your GUI thread a slave of your background worker now, so if the BGW never terminates, your app is stuck while the user wanted it to exit. The minimum I would do is impose an upper limit. :)

Luc Pattyn [Forum Guidelines] [My Articles]

- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets

Ankit Rajpoot

Hi, Thanks for your response. Well, my problem is not that the BGWKR is not working. Infact, it's working perfectly. My problem is that if I call CancelAsync() from FormClosing event, the Do_Work method never stops execution and the .IsBusy property never becomes false. At the same time, the code inside the Do_Work event seems to be jammed. I can say this as the if(CancellationPending) condition in the Do_Work event is never hit. The very same architecture works flawlessely, it CancelAsync() is called from a button's click event handler. Your 1st comment: That Groups.Add() call is nothing. I added it for testing purposes while debugging. So don't worry about that. I know it's not a thread-safe operation and will remove it. Your 2nd comment: Doing so will only get me out of the inner foreach loop. What about the outer one? Your 3rd comment: That i'll replace with code to hide the form and then wait till the BGWKR finishes or a deadline is met.

Excuse me for buttin' in, but I'm interrupt driven.

Luc Pattyn

OK, here is an hypothesis: maybe CancelAsync does not get forwarded to the BGW (or has no net effect) as long as the GUI thread is still busy; when inside a Button_Click handler, it is free right away; in your Form_Closing handler, you keep the GUI thread occupied with the sleep loop. suggested experiment: rather than the while-sleep loop, set e.Handled true and see if the CancelAsync now works; if it does, it confirms the hypothesis; I then suggest you don't use CancelAsync, instead create your own boolean variable to communicate from Form_Closing to DoWork. :)

Luc Pattyn [Forum Guidelines] [My Articles]

- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets

Ankit Rajpoot

Thanks, Your hypothesis was perfectly correct. When I removed the while(...)...; loop from the form_closing event, it started working perfectly.

Excuse me for buttin' in, but I'm interrupt driven.