C / C++ / MFC

Re: CFileDialog in an own thread -> Access violation

28-Oct-09 3:36

Hey guys,

I got a weird problem with a CFileDialog in an own thread.

It looks like the following:

static UINT Thread(LPVOID pParam)
{
    CFileDialog dlg(true);
    dlg.DoModal();
    return 0;
}

...

AfxBeginThread(Thread, this);

When I c+p files or delete files in the file dialog I will get an Access Violation, as soon as the thread ends.

I told the debugger to break on Access Violations and this is the position where he stops:

At the file "threadex.c" in the function "void __cdecl _endthreadex (unsigned retcode)" at

ExitThread(retcode);
} // Here he the debugger breaks

Anybody there, who can help me? ^^

There is nothing else in the code. Just a single dialog box with a button, which starts the thread in its OnButtonPressed() routine.

I am using VS2k8 SP1. I also already tried to use a gui thread instead of a worker thread, no changes.

Greets,

Cedric Moonen28-Oct-09 3:42

Cedric Moonen

28-Oct-09 3:42

You shouldn't touch the GUI (opening a modal dialog for instance) in a different thread than the main thread. Why do you want to open the CFileDialog in a separate thread ?

Cédric Moonen
Software developer

Charting control [v2.0]
OpenGL game tutorial in C++

Re: CFileDialog in an own thread -> Access violation

slaindevil28-Oct-09 4:25

Re: CFileDialog in an own thread -> Access violation

28-Oct-09 4:25

I need to initialize COM objects in the main thread with a multithreaded apartment.
This deactivates things like D+D, C+P, Deletion of files, custom context menu and file type changing in file dialogs.

The only workaround I know, is to start the file dialog in a different thread.

Randor 28-Oct-09 5:05

Randor

28-Oct-09 5:05

Hi,

Just so I understand correctly you have called CoInitializeEx(COINIT_MULTITHREADED) in your main thread and therefore cannot use the CFileDialog because of the issue described in:

INFO: Calling Shell Functions and Interfaces from a Multithreaded Apartment[^]

Have you tried deriving the second thread from CWinThread and explicitly switching to single-threaded apartment?

Best Wishes,
-David Delaune

Re: CFileDialog in an own thread -> Access violation

slaindevil1-Nov-09 21:53

Re: CFileDialog in an own thread -> Access violation

1-Nov-09 21:53

This solved my problem. Thanks...

I cant image, why I never tried this up till now Frown | :(

Randor 2-Nov-09 10:36

Randor

2-Nov-09 10:36

slaindevil wrote:
This solved my problem. Thanks...

No problem. I believe your thread was inheriting the threading model of the thread that created it.

Best Wishes,
-David Delaune

Re: CFileDialog in an own thread -> Access violation

Roger Stoltz28-Oct-09 7:52

Roger Stoltz

28-Oct-09 7:52

slaindevil wrote:

The only workaround I know, is to start the file dialog in a different thread.

Why not do the opposite - spawn a UI-thread that creates the MTA?
All you need is a message pump and something, e.g. a user defined message, that tells the thread to create the server that should reside in the MTA.

If your post is about the issue Randor mentions, you won't pull the rug for the main thread and all calls to shell functions will not fail because if the MTA at least.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Re: CFileDialog in an own thread -> Access violation

slaindevil1-Nov-09 22:02

GDI+ Bitmap::FromHICON problem

1-Nov-09 22:02

Thanks for your idea, but Randors post solved my problem and it fits better into the program code. But really, thanks anyway!

Evil.Ghost28-Oct-09 1:42

Evil.Ghost

28-Oct-09 1:42

I created a Gdiplus::Bitmap by Gdiplus::Bitmap::FromHICON(), but the alpha channels lost. Is there any solutions?

Evil.Ghost

Re: GDI+ Bitmap::FromHICON problem

CPallini28-Oct-09 2:02

Guidelines say avoid standard integer types

28-Oct-09 2:02

Yes.

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

RedSonja28-Oct-09 0:31

RedSonja

28-Oct-09 0:31

The project style guidelines say this:

"Unless portability and reusability is not a concern, the use of standard integral types is forbidden (exception: enum) and the types from a standard project header must be used."

I can remember the days when we used to do this, but it has fallen into disuse. Are integers more portable now? I remember it being a problem with DEC machines, but we don't use them anymore. It seems I am not following the guidelines right now, I need a good reason in case the code inspectors ask.

In help all it says is that integer size is machine dependent.

------------------<;,><-------------------

CPallini28-Oct-09 0:51

28-Oct-09 0:51

RedSonja wrote:
In help all it says is that integer size is machine dependent.

Well, that's an hint.
Smile | :)

RedSonja28-Oct-09 2:23

RedSonja

28-Oct-09 2:23

I am aware that different machines have different sizes for integer. I was hoping to hear something like - compilers are so clever nowadays they can handle this.

It seems there is no way out and I will have to make a header file with standard types in it. I might have one left from 10 years ago. I was just hoping this kind of stuff was no longer necessary.

(I just surprised the new graduate, who wanted to know what an unsigned character is good for. Apart from using it as an unsigned character, in the old days when size mattered we used to use unsigned char to get an 8-bit integer. That was in image processing, with one integer for each pixel, etc.)

------------------<;,><-------------------

CPallini28-Oct-09 2:44

28-Oct-09 2:44

RedSonja wrote:
compilers are so clever nowadays they can handle this.

Well, they are compilers after all (i.e. How 'the fresh Hell' a compiler would handle that?). Smile | :)

RedSonja wrote:
(I just surprised the new graduate, who wanted to know what an unsigned character is good for. Apart from using it as an unsigned character, in the old days when size mattered we used to use unsigned char to get an 8-bit integer. That was in image processing, with one integer for each pixel, etc.)

Since there is a rather general agreement among different machines about the size of a byte, then it may be indeed a good starting point.
Smile | :)

RedSonja28-Oct-09 3:13

RedSonja

28-Oct-09 3:13

I think your determination to be amusing at my expense just exceeded my determination to find help here.

Perhaps among the other readers there are some who understand what my problem is and have dealt with it themselves in the recent past.

The problem is not the code, or the size of integers. The problem is handling the code auditors.

------------------<;,><-------------------

Richard MacCutchan28-Oct-09 3:31

Richard MacCutchan

28-Oct-09 3:31

RedSonja wrote:
I think your determination to be amusing at my expense just exceeded my determination to find help here.

Perhaps your question led you to this situation.

You have some rules which, for some reason, you are uhappy with and you expect someone here to give you a technical solution to a non-technical issue.

RedSonja wrote:
The problem is not the code, or the size of integers. The problem is handling the code auditors.

And what has that to do with C/C++/MFC?

codedgn28-Oct-09 4:06

codedgn

28-Oct-09 4:06

If you don't have solution for the question, PLEASE DON'T REPLY.

CPallini28-Oct-09 4:26

28-Oct-09 4:26

codedgn wrote:
If you don't have solution for the question, PLEASE DON'T REPLY.

Your statement does NOT compile, error message: missing 'then'. Poke tongue | ;-P

Richard MacCutchan28-Oct-09 4:43

Richard MacCutchan

28-Oct-09 4:43

codedgn wrote:
If you don't have solution for the question, PLEASE DON'T REPLY.

FWIW I was giving advice, there is no solution to the OP's question.

As someone who only joined the Code Project today, I don't think your opinion on this subject has any merit. May I suggest you read the guidelines[^], and then spend a few months reading some of the questions and answers, before telling others what to do.

codedgn28-Oct-09 7:55

codedgn

28-Oct-09 7:55

The purpose why people post questions here is to seek solution not advice. The advice they can get from anywhere.

They have adviser in school.

Richard MacCutchan28-Oct-09 8:48

Richard MacCutchan

28-Oct-09 8:48

codedgn wrote:
The purpose why people post questions here is to seek solution not advice.

You must either be particularly dense, or you know absolutely nothing about computing! As I stated before there is no solution to this problem, as is the case with many of the questions here. All we can do is advise the OP of that fact and make suggestions as to what other course of action they may take. The fact that the questioner does not like the answer makes no difference to the outcome.

CPallini28-Oct-09 4:03

28-Oct-09 4:03

RedSonja wrote:
I think your determination to be amusing at my expense just exceeded my determination to find help here.

My question, actually, was serious: how could you expect a compiler will handle it? Compilers simply cannot.

RedSonja wrote:
Perhaps among the other readers there are some who understand what my problem is and have dealt with it themselves in the recent past.

Again, my suggestion was serious: unsigned char is actually one of the most portable data type.

RedSonja wrote:
The problem is not the code, or the size of integers. The problem is handling the code auditors.

If there aren't problems with the size of the integers, then shouldn't be problems with the auditors. Well, actually here I can understand your point, anyway is portability really a concern, there? If it is then I suppose you've already solved the problem and can boldly argue with the auditors. On the other hand, if portability isn't really a concern, why ('the fresh hell' again) should auditors worry about (holding this point is more troublesome).

Smile | :)