|
simoncoul wrote: unsigned char myclase::makesendbuffer(Packet SendPacket, unsigned char sendbuf2[6])
{
unsigned char sendbuf2[6];
There's no way you could have gotten this to compile.
"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
|
|
|
|
|
int main(void){
unsigned char sendbuf[6];
myclass::makesendbuffer(SendPacket, sendbuf);
}
void myclass::makesendbuffer(Packet SendPacket, unsigned char sendbuf[6]){
if(SendPacket.data < 0){
SendPacket.data += 65536;
}
sendbuf[0] = SendPacket.data % 256;
sendbuf[1] = floor(double(SendPacket.data/256));
sendbuf[2] = SendPacket.address % 256;
sendbuf[3] = floor(double(SendPacket.address/256));
sendbuf[4] = SendPacket.command;
}
That was what I finally ended up with and it works, is there a problem with it that u can see?
|
|
|
|
|
simoncoul wrote: is there a problem with it that u can see?
No, assuming all of the values being assigned to sendbuf are between 0 and 255.
"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
|
|
|
|
|
Yeah they are!
Thanks for all the help guys!!
|
|
|
|
|
you are wellcome...
but
simoncoul wrote: unsigned char sendbuf2[6];
cut this line
and I think that is better if
void myclase::makesendbuffer(Packet SendPacket, unsigned char* sendbuf2)
Russell
|
|
|
|
|
ok Thanks I see what u mean doesn't make sense to say sendbuf[6].
Thanks again!
|
|
|
|
|
simoncoul wrote: Any ideas of what I'm doing wrong here would be great thanks!
You are programming in C. This might or might not be intended.
The C++-way would be a std::vector.
BTW: You can easily hand that over to C-Functions by getting the address of the first element: &vec[0].
I assume that you want to use C(ish) Code.
I see two errors:
1) You are allocating the sendbuf in your function on the stack. The memory will be freed on leaving the function. Later access to it will fail. When you don't expect it. Catastrophically.
You either need to allocate it outside and hand a pointer in, or you need to allocate it in the function on the heap and return the pointer you got (And delete it after use!).
2) Your code explicitly states that it is returning exactly one unsigned char.
What you want is returning the array of chars, I think.
So you need to return a pointer to the first element of the array and the length. Alternatively, when the length is always 6, you could define a datatype of 6 unsigned chars to be a sendbuf, and return only the sendbuf-pointer.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
How can I get a point to the document class. I tried copying from the view class header and body and putting it in myclass would not work (changing CControlView:: to myclass: and I got error C2143: syntax error : missing ';' before '*'
header:
public:
CControlDoc* GetDocument();
body:
CControlDoc* CControlView::GetDocument() // non-debug version is inline
{
ASSERT(m_pDocument->IsKindOf(RUNTIME_CLASS(CControlDoc)));
return (CControlDoc*)m_pDocument;
}
cwbenson
|
|
|
|
|
cwbenson wrote: and I got error C2143: syntax error : missing ';' before '*'
And did you remember to also include the doc's header file in myclass.h?
"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
|
|
|
|
|
cwbenson wrote: How can I get a point to the document class.
You probably need to give it to your class.
I have a FrameWnd creating a few Views in OnCreateClient, and it gets the Doc and the View in CCreateContext.
Most of the other classes that need Document-Access are somehow children of the view and can get its adress to ask it for the Document.
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal.
George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
I have made it in one project. Quite easy.
#include "CMyDoc.h"
CMyDoc* pMyDoc;
void CMyMainView::OnInitialUpdate()
{ CScrollView::OnInitialUpdate();
CMyDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
extern CMyDoc* pMyDoc;
pMyDoc = GetDocument ();
return;
}
#include "stdafx.h"
CMyDoc* pMyDoc_InSecondView;
CMySecondView::CMySecondView()
: CFormView(CMySecondView::IDD)
{
extern CFPSDoc* pMyDoc;
pMyDoc_InSecondView = pMyDoc;
}
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
hi, i createad a MFC dialog with a worker thread, my worker thread needs to communicate with the dialog, so i decide to use messages.
project name:MultithreadingTest
in MultithreadingTest.h, i defined 2 user message.
// MultithreadingTest.h : main header file for the PROJECT_NAME application
//
#define WM_USER_GET_DATA WM_USER+0x100
#define WM_USER_THREAD_ABORTED WM_USER+0x101
....
// Implementation
afx_msg LRESULT OnGetData(WPARAM wParam, LPARAM lParam);// WM_USER_GET_DATA handler
afx_msg LRESULT OnThreadAborted(WPARAM wParam, LPARAM lParam););// WM_USER_THREAD_ABORTED handler
DECLARE_MESSAGE_MAP()
then in MultithreadingTest.cpp,
// MultithreadingTest.cpp : Defines the class behaviors for the application.
//
// CMultithreadingTestApp
BEGIN_MESSAGE_MAP(CMultithreadingTestApp, CWinApp)
ON_COMMAND(ID_HELP, &CWinApp::OnHelp)
ON_MESSAGE (WM_USER_GET_DATA, OnGetData)//<-ERROR hee
ON_MESSAGE (WM_USER_THREAD_ABORTED, OnThreadAborted)//<-ERROR thee
END_MESSAGE_MAP()
I got some error at ON_MESSAGE(...)
error C2440: 'static_cast' : cannot convert from 'LRESULT (__thiscall CMultithreadingTestApp::* )(WPARAM,LPARAM)' to 'LRESULT (__thiscall CWnd::* )(WPARAM,LPARAM)' None of the functions with this name in scope match the target type
what's the cause??
|
|
|
|
|
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)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
