Re: CFileDialog in Threads

It is impossible to pose an alternative without knowing details of the design space. But
the problems of user-interface objects in secondary threads are considerable, and I would
not consider an implementation that requires this as being a viable design. The point of
design is to also recognize solutions which have high risks and low payoff, and create
designs that do not have high risks. So one solution is "don't run the ActiveX control in
other than the main GUI thread".

Nobody said good solutions are easy. Bad solutions are often easy, and give the illusion
that they work, and until they start failing nobody questions them. Then, when they start
failing, the questions take the form of "I have a bad design, how can I kludge it to
work?" instead of "what's wrong with this solution?" A solution that involves trying to
manipulate a file open box in another thread represents a bad design. The trick is to
figure out how to make a viable design that avoids known problems.

It is not my responsibility to propose a solution for a poor design. I can, however,
identify a poor design. A design that requires user-visible components in a secondary
thread has such a high probability of failure that the heuristic is that this is a bad
design. If I were confronted with a such a problem, I would simply rule out solutions
that required popping up a dialog in a secondary thread. Once you rule out the problems,
you are then free to create problem-free solutions.

If the argument is "this is a prebuilt control, and that's how it works," then that is an
argument that says "I chose a component which is based on the fact that it runs in the
main GUI thread. I violated its fundamental assumptions, and now I need to know how I can
make it work in spite of that." When you violate key assumptions, be prepared to deal
with intractable problems.

Much of ActiveX is based on single-thread assumptions. Most ActiveX controls cannot work
at all if the container is in a different thread than the control. So for the typical
ActiveX control, any solution that implies cross-thread interaction between control and
container is doomed.

The illustrated code is so completely wrong that it cannot possibly work, and it is based
on premises that are faulty. It isn't just convoluted, it is nonsense. Furthermore, it
is based on a desire to accomplish something cross-thread that does not need to be done
cross-thread, such as setting the caption text. There are simpler ways. For example, a
simple hook function would handle this.

This is a typical question: "Tell me how to make my bad solution work" instead of "Here's
my problem, how can I solve it?"
joe
On Thu, 2 Feb 2006 13:48:48 +0100, "KMA" <kma@xxxxxxxxxxxxxxx> wrote:

Surely there are simpler solutions to the problem than this?

It's definitely convoluted and error prone, but how else can the result be
achieved? From the other branch of the discussion it seems that the dialog
is presented by an ActiveX component. So, reduced to the essentials the
question is "How can I influence a dialog box that is produced by code not
within my control?" With a subtext of "I have some information about the
dialog box, it's a File Open box (in File Save mode in this case)"

It's all very well to say abandon the design, but without offering an
alternative it rings a little hollow.



"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:vac3u1tmmft37f6ejg32nuqgfunh6h22c8@xxxxxxxxxx
I would abandon the whole design. Keep user interactions in the main GUI
thread, period.
Also, forget that the data type 'char' exists. The code you show is not
only not
Unicode-aware, it cannot even be localized. Put the filter as a string in
the
STRINGTABLE.

There is no reason to presume that GetForegroundWindow is going to return
anything
remotely useful, so you can forget it as a means of getting the file
dialog handle. It
would not have even occurred to me that such a solution could make sense.
Your thread2
assumes that the Thread1 has actually created the window, which is also
nonsensical. It
turther assumes that the window, once created, IS the foreground window,
an assumption
which has no justification whatsoever.

Any thread system that requires a Sleep() to function correctly has
fundamental design
errors and can be safely assumed to be erroneous.

There seems to be little reason to have a thread whose purpose is to
change the title of a
window in another thread. Surely there are simpler solutions to the
problem than this?
joe

On 1 Feb 2006 02:34:15 -0800, akshay4friend@xxxxxxxxx wrote:

I need to get handle of modal file dialog box. for that I am putting
CFileDialog in thread. I am creating 2 threads . In one thread i am
invoking CFileDialog and in another thread I am trying to get handle of
that dialog box using GetForegroundWindow().....but with code given
below I am not getting handle of file dialog box but getting my
CTestDlg dialog box handle.....


void CTestDlg::OnOK()
{
// TODO: Add extra validation here
CWinThread* pWThread1 = AfxBeginThread(Thread1, this);

CWinThread* pWThread2 = AfxBeginThread(Thread2, this);
.......
.......
}

UINT Thread1(LPVOID pParam)
{
static char szFilter[] = "COFF files (*.txt)|*.out|All Files
(*.*)|*.*||";
CFileDialog fileDlg(TRUE, NULL, NULL, OFN_HIDEREADONLY |
OFN_OVERWRITEPROMPT, szFilter);
fileDlg.DoModal();
return 1;
}

UINT Thread2(LPVOID pParam)
{
::SetWindowText(::GetForegroundWindow(),"Save Text File");
return 1;
}

**BUT... WHEN I CHANGE Thread2() FUNCTION LIKE BELOW I AM GETTING
HANDLE OF FILE DIALOG BOX AND ITS PROPERLY SETTING WINDOW TEXT...LIKE
THIS..

UINT Thread2(LPVOID pParam)
{
Sleep(100);
::SetWindowText(::GetForegroundWindow(),"Save Text File");
return 1;
}

but I think using Sleep() is not perfect way for doing this...because
100 factor for Sleep function is not fixed for every time...I am new to
thread programming. .. so I want to know which is other way to getting
handle of file dialog box... how can i know that my modal file dialog
box is become foreground window.....

Thanx in Advance
Akshay
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • English eBooks Engineering
    ... Adaptive Voltage Control in Power Systems Fusco, ... Advanced Design Techniques for RF Power Amplifiers Krizhanovski, ... Advanced Fuzzy Logic Technologies in Industrial Applications Bai, ... Bioinformatics Using Computational Intelligence Paradigms Jain, ...
    (sci.med.nutrition)
  • Re: Microchip programmer Sydney Aus
    ... schematic design, embedded firmware and pcb layout to finished product. ... possible through the use of advanced microcontroller products from Microchip ... microcontroller applications in Innovative Power and Control solutions. ... Resources cover a broad range of electronics ...
    (sci.electronics.design)
  • Ebooks Forum
    ... Analysis and Design of Advanced Multiservice Networks Supporting ... Control and Observer Design for Nonlinear Finite and Infinite ... IUTAM Symposium on Computational Approaches to Multiphase Flow ... Islamic Philosophy and Occidental Phenomenology on the Perennial Issue ...
    (sci.med.nutrition)
  • a forum for you
    ... Advances in High Performance Computing and Computational Sciences ... Analysis and Design of Advanced Multiservice Networks Supporting ... Control and Observer Design for Nonlinear Finite and Infinite ... IUTAM Symposium on Computational Approaches to Multiphase Flow ...
    (sci.med.nutrition)
  • English eBooks Engineering
    ... Advances in High Performance Computing and Computational Sciences ... Analysis and Design of Advanced Multiservice Networks Supporting ... Control and Observer Design for Nonlinear Finite and Infinite ... IUTAM Symposium on Computational Approaches to Multiphase Flow ...
    (sci.med.nutrition)
Loading