|
No problem with VS6. Are you using VS2005 perhaps?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
|
Then the function's prototype has apparently changed.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
then how should i do this? this ON_MESSAGE is for CWnd class, but my bass class is CWinApp
my worker thread need send a message and some function in the dialog class will do something, where should i implement the message?
|
|
|
|
|
Does the app or the window need to handle the messages? I suspect it's the window, but that's ultimately for you to decide.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
since i need to access the GUI object, or a sliderctrl on the dialog, my worker thread have to post a message so some function in the dialog class will do something about the slider ctrl,should i send the message to the dialog? isn't that gonna cause deadlock(something mention in a article)?
|
|
|
|
|
alberthyc wrote: ...should i send the message to the dialog?
Of course.
alberthyc wrote: isn't that gonna cause deadlock(something mention in a article)?
If the message is posted to the window's message queue, why would it? It's when you bypass the window's message queue and send directly to its window procedure that can cause problems.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
http://www.flounder.com/workerthreads.htm[^]
in the "Worker threads and the GUI II: Don't touch the GUI" section , it mentioned something:
"In my case, the list box sent a notification, via SendMessage, to its parent. This means the message went to its parent thread. But the parent thread was blocked, waiting for the thread to complete. But the thread couldn't complete until it could run, and guess what: the SendMessage was a cross-thread SendMessage, which would not return until it was processed. But the only thread that could process it was blocked, and couldn't run until the thread completed. Welcome to the world of deadlock."
and
"The FindWindow problem was quite similar. The programmer had specified finding a window with a particular caption. This meant that the thread running FindWindow had to SendMessage a WM_GETTEXT message to the window whose handle it had just found via EnumWindows. This message could not be processed until the thread that owned the window could execute. But it couldn't, because it was blocked waiting for the thread to finish. Deadlock. So note that although you should not touch the GUI thread explicitly, you must also not touch it implicitly, through such innocuous-seeming operations such as FindWindow, or you can, and will, experience deadlock. Under these conditions, by the way, there is no recovery. You can kill the process, which explicitly terminates all threads, but this is neither elegant nor, as the warning box tells us, necessarily safe"
i'm wondering that if i send a message to the dialog box, which is the parent thread supposedly, isn't that the samething as mentioned above?
Maybe i'm misunderstanding...
|
|
|
|
|
alberthyc wrote: i'm wondering that if i send a message to the dialog box...
Which is what you don't want to do, because the dialog owns the UI. Secondary threads should not communicate directly with UI components, thus posting a message is the solution.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
sorry, should i post the message handler between
BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
....
END_MESSAGE_MAP()
or not?
|
|
|
|
|
Yes, for the mapping of the message handler. The handler itself can be anywhere just like any other class method.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
The problems mentioned were a result of using SendMessage. You usually use PostMessage when communicating from a worker thread to a GUI thread. PostMessage does not pause the worker thread.
Also, <pet peeve alert>, use WM_APP as the base for your internal messages, not WM_USER. WM_USER is used internally by some controls - may not bite you, but it may if you're doing "interesting" stuff with some of your controls. </pet peeve alert>
Judy
|
|
|
|
|
Your handler method should have the following prototype:
LRESULT OnMyMessage(WPARAM wp, LPARAM lp);
*EDIT* Never mind. I see you have the right prototype but you're trying to handle a window message in the app class.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
yeah, i'm not fully understand the message stuff yet, but i know that I should touch the GUI object from worker thread because the GUI object send some message to the parent thread and parent thread is blocked somehow and DEADLOCK.
that's why i implemented the message in the app class or the dialog class.
tell me if i'm misunderstanding
|
|
|
|
|
alberthyc wrote: because the GUI object send some message to the parent thread
It posts a thread message or sends (or posts) a window message?
It's important to differentiate the target of the message and whether it's being sent or posted.
If you have a worker thread that needs to get a message to a window, you should use PostMessage();
That message should be received in the window class.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
thx, that's pretty clear now
|
|
|
|
|
Hi all,
I am writing a program that has a dialog box with a logging window. Since the dialog is resizeable, I want my text to wrap. However, I do not want to use the windows wrapping, since I indent certain lines, and the indentation should be kept for the wrapped parts of the lines.
I am currently using the following code for this:
CDC * pDC = m_ctrlLog.getDC ();
CSize Size = pDC->GetTextExtent (m_strLine); // the line that needs to be displayed
m_ctrlLog.GetClientRect (&Rect);
pDC->DPtoLP (&Rect);
m_ctrlLog.ReleaseDC (pDC);
if (Size.cx > Rect.right) // we need to wrap
-------------------------------------
However, this does not do the job! If I let the font be the default font, then it starts wrapping much too soon. If I set the font to Courier (which I do, since I am working with 3 letter tags that then get nicely lined-up) then it starts wrapping when the line already exceeds the windows width by some 12 characters. I think it has to do with the units that are used in the different routines, but I do not seem to be able to get this right!
Anybody any bright ideas please?
Thanks in advance,
William
|
|
|
|
|
|
Hi,
I am writing few programs which generate some data that needs to be plotted. I am currently using MS EXCEL to plot the graphs. I would like to know if there is a way to call the EXCEL application from C++ programs and make them generate the plots. I heard that using DLLs and Marcos its possible I dont know much about it. so can anyone help me.... pls
I am a new to this subject and any kind of help would be very much appreciated
Jyothi
|
|
|
|
|
What you mean by calling excel application from c++ ?
you mean the Excel activex control ? It is possible create excel activex.
If u can Dream... U can do it
|
|
|
|
|
Hi,
I am writing few programs which generate some data that needs to be plotted. I am currently using MS EXCEL to plot the graphs. I would like to know if there is a way to call the EXCEL application from C++ programs and make them generate the plots. I heard that using DLLs and Marcos its possible I dont know much abou t it. so can anyone help me.... pls
I am a new to this subject and any kind of help would be very much appreciated
Jyothi
|
|
|
|
|
Hi Jyothi,
I am not quite sure about excel, but I know that it is possible to control word and outlook from a C++ program, using what is called "office automation". In the directory where the Excel executable is stored, you should look for a file called "Excel9.olb" If you can find this, then you can import it in your Studio environment, which will give you all the functions you need to control excel. You will need to look for descriptions of the necessary functions on the inetrnet. Microsoft does have a number of usefull documents, but these are usually hard to find!
Good luck.
William
|
|
|
|
|
Hi William
Thank you very much for the reply.
I ll get back to u once I am done with it.
Jyothi
|
|
|
|
|
William Engberts wrote: but these are usually hard to find!
*sigh*[^]
|
|
|
|
|
Can you simply generate a text file that contains the data numbers in ASCII format, saving it with the XLS extension and then open it with excell (also programmatically using ShellExecute)and then plot that data manually?
Or you need to prepare the graphs automatically?
Russell
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
