|
yes .....
(class CFormView : public CScrollView
class CScrollView : public CView)
in our application we are deriving the class from the CView like below.
class CCommonEDM_AVitarView : public CView
in above derived call i have handled the OnMouseWheel function. but it's not hitting the code while scrolling the mouse wheel.
code :
Header file:
class CCommonEDM_AVitarView : public CView
{
protected: // create from serialization only
CCommonEDM_AVitarView();
DECLARE_DYNCREATE(CCommonEDM_AVitarView)
public:
afx_msg BOOL OnMouseWheel(UINT nFlags, short zDelta, CPoint pt);
};
source file :
IMPLEMENT_DYNCREATE(CCommonEDM_AVitarView, CView)
BEGIN_MESSAGE_MAP(CCommonEDM_AVitarView, CView)
ON_WM_MOUSEWHEEL()
END_MESSAGE_MAP()
BOOL CCommonEDM_AVitarView::OnMouseWheel(UINT fFlags, short zDelta, CPoint point)
{
TRACE0("in CCommonEDM_AVitarView:: OnMouseWheel function");
return CView :: OnMouseWheel(fFlags, zDelta, point);
}
i am not understanding how internal child windows are working with mouse wheel scrolling. but main window is not working..
|
|
|
|
|
The MFC document - view concept is a little bit complicated regarding the parent and child windows and their interaction.
But the message is sent to the control / window that has the focus. If your view contains controls then one of them probably has the focus and gets the message.
It is still unclear to which window your scroll bars belong. If they are for the view: why is your view not CScrollView based? If your view contains a single control: handle the message there.
|
|
|
|
|
Hello sir,
i have written the below code for my each child frame. this class is derived from the CScrollView. my mouse wheel is working fine for each individual window class. but i am trying to implement same support from my main window class.but mouse wheel is not working. could you please give me your valuable inputs.
My intention is instead of writing mouse wheel code for all the child class. if i implement mouse wheel function for my main frame. i would have been worth to all child classes.
my individual window class code :
mouse while is working with below code with below class..
Header file:
class CAboutView : public CFormView
{
-----------
afx_msg BOOL OnMouseWheel(UINT nFlags, short zDelta, CPoint pt);
}
Source file :
BEGIN_MESSAGE_MAP(CAboutView, CFormView)
//ON_WM_MOUSEWHEEL()
END_MESSAGE_MAP()
BOOL CAboutView::OnMouseWheel(UINT nFlags, short zDelta, CPoint pt)
{
return DoMouseWheel(nFlags, zDelta, pt);
}
This is my main frame:
with the below code my mouse wheel not working.
Header file :
class CMainFrame : public CFrameWndEx
{
-----------
afx_msg BOOL OnMouseWheel(UINT nFlags, short zDelta, CPoint pt);
}
Source file :
BEGIN_MESSAGE_MAP(CMainFrame, CFrameWndEx)
ON_WM_MOUSEWHEEL()
END_MESSAGE_MAP()
BOOL CMainFrame::OnMouseWheel(UINT fFlags, short zDelta, CPoint point)
{
CScrollView *wnd = NULL;
BOOL mValue;
mValue = wnd->DoMouseWheel(fFlags, zDelta, point);
return mValue;
}
|
|
|
|
|
|
I have a CData derived from CObject. In my CDocument, I have a CMap, with key as int, and values as CData*.
In a CMyDocument method I have:
void CMyDocument::GetData(int nItemData, CData* pData)
{
m_MapData.Lookup(nItemData, pData);
TRACE("Inside doc method: pData is not NULL: %d\n", NULL != pData);
}
and in my CMyView:
int nItemData = 1;
CData* pData = NULL;
GetDocument()->GetData(nItemData, pData));
TRACE("In MyView: pData is not NULL: %d\n", NULL != pData);
and here is the result:
Inside doc method: pData is not NULL: 1
In MyView: pData is not NULL: 0
Why inside CMyDocument I have a valid pData, but outside not ?
modified 8-Jul-18 10:17am.
|
|
|
|
|
In case 1 you have not shown the value of pData. In case 2 you have explicitly set its value to NULL.
|
|
|
|
|
In case 1, the trace show me that pData is not NULL, and after GetData call, I set up nothing, I only display if pData is NULL or not ... but is NULL ...
|
|
|
|
|
Your test does not show what you think. It shows the values that you set in pData before the call to GetData, which does not change it. You need to reread the documentation, and understand the difference between a pointer and a reference.
|
|
|
|
|
Because the CData pointer is passed by value. If you need to modify the pointer then you have to pass it by reference (or use a double pointer).
|
|
|
|
|
I used double pointer and goes perfectly. Kindly thank you all of you (including Richard)!
|
|
|
|
|
In VS 2017, is it possible to create a static library project that exports classes the same way an MFC Extension DLL does?
I know I can create a regular static library project, but how would I make it possible to use MFC classes like CString inside that project?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
Thank you for your response!
I just figured out how to do it.
First, create a static library project, then include all of the MFC headers in the stdafx.h file.
Thanks again. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hello everyone,
I'm kinda new to writing application programs for a PC, a Linux one at that, so I hope this isn't a stupid question. 
I am rather experienced at writing C programs for Microchip PICs. I need a PC application to interface with a PIC project, it will up load information to the PIC from the PC using a pair of Wixel modules. They are basically a USB to RF or RF to Serial bridge. I have them working (one connected to the PC, one connected to the PIC) using a terminal program. I can send data back and forth just fine.
I am now trying to send and receive data using a C++ application. The sending from the PC to the PIC works just fine also. The problem I am having is getting data from the PIC to the PC Application.
This is the application code ..
#include <cstdlib>
#include <iostream>
#include <fstream>
#include <sstream>
using namespace std;
int main(int argc, char** argv)
{
fstream COMPORT;
char line[256];
streamsize lim = 256;
char c;
COMPORT.open("/dev/ttyACM0");
while(1)
{
if (COMPORT.is_open())
{
cout << "Hit <Enter> to send command, <S> to Stop .." << endl;
cin.get(c);
if ((c == 's' || c == 'S'))
{
COMPORT.close();
return 0;
}
COMPORT << "UPLOAD NEW MAP\n";
COMPORT.getline(line, lim);
cout << "Line =" << line;
cout << "Response=" << c;
cout << endl;
}
}
COMPORT.close();
return 0;
}
The PIC code, if that helps ..
void APP_Wixel_IO_Test_Tasks(void)
{
APP_ESUART_Tasks();
if (CmdReady == 1)
{
CmdReady = 0;
RXBufCnt = 0;
utoa(TXBuf, Cnt, 10);
strcat(TXBuf, "\n");
WriteESUARTDataMsg(TXBuf, strlen(RXBuf));
Cnt++;
}
}
Basically all the PIC code does is send back the 'cnt' variable when it gets data from the PC.
The
COMPORT.getline(line, lim); doesn't work right. The first time I run it, it kinda works, but resending the data back to the PIC gets no response ..
Hit <Enter> to send command, <S> to Stop ..
Response=4
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
I've tried everything I can think of. Like I said, data out
COMPORT << "UPLOAD NEW MAP\n"; works fine. Data in does not.
Thanks
OtG
|
|
|
|
|
WriteESUARTDataMsg(TXBuf, strlen(RXBuf));
Should that not be strlen(TXBuf) ?
|
|
|
|
|
Yes, it should. I changed that but I get the same response from the application ..
Response=�
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
Response=
Hit <Enter> to send command, <S> to Stop ..
^C
RUN FINISHED; Interrupt; real time: 11s; user: 0ms; system: 0ms
I am pretty sure the PIC is doing it's job and replying to the message from the application (PC) correctly.
Thanks for spotting that error.
OdlG
|
|
|
|
|
I have never tried to read a serial port via a stream class. Serial ports tend to be slow, and are really character oriented. You could try just using a basic file handle and reading as many characters as you can, gradually filling a buffer until you see a newline character. I know the ifstream should work that way but ...
|
|
|
|
|
Thanks for the reply. I did try using get(c); but that didn't seem to work either. I will look at that some more.
OdlG
|
|
|
|
|
Any advise on how to do that?
Thanks.
Richard MacCutchan wrote: You could try just using a basic file handle and reading as many characters as you can, gradually filling a buffer until you see a newline character
|
|
|
|
|
I am not familiar with Linux but I have done some programming with usb to rs232 dongles in Windows and your symptom is familiar. For what it's worth, are you sure your serial port parameters match?
If not, you may get partial data and the port on the computer can error. Can you check for error
conditions like parity error? I do not know if you are sending a lot of data, but if you are,
you will have to consider serial handshaking as well or you will get buffer overruns.
|
|
|
|
|
speedbump99 wrote: For what it's worth, are you sure your serial port parameters match?
Yes. I can send data back and forth with a terminal program.
I have modified the programs like this ..
void APP_Wixel_IO_Test_Tasks(void)
{
APP_ESUART_Tasks();
if (CmdReady == 1)
{
CmdReady = 0;
RXBufCnt = 0;
utoa(TXBuf, Cnt, 10);
strcat(TXBuf, "\n");
WriteESUARTDataMsg(TXBuf, strlen(TXBuf));
Cnt++;
}
}
and this ..
int main(int argc, char** argv)
{
fstream COMPORT;
int number;
int x = 0;
char c;
while(1)
{
COMPORT.open("/dev/ttyACM0");
if (COMPORT.is_open())
{
cout << "Hit <Enter> to send command, <S> to Stop .." << endl;
cin.get(c);
if ((c == 's' || c == 'S'))
{
COMPORT.close();
return 0;
}
COMPORT << "UPLOAD NEW MAP\n";
COMPORT >> number;
cout << "number = " << number;
cout << endl;
}
COMPORT.close();
}
return 0;
}
I get this response ..
Hit <Enter> to send command, <S> to Stop ..
number = 0
Hit <Enter> to send command, <S> to Stop ..
number = 2
Hit <Enter> to send command, <S> to Stop ..
number = 4
Hit <Enter> to send command, <S> to Stop ..
number = 6
Hit <Enter> to send command, <S> to Stop ..
number = 8
Hit <Enter> to send command, <S> to Stop ..
s
I cannot figure why the cnt goes to two times instead of one.
I would like to not be limited to just sending numbers back from the PIC.
I think I am doing things "pretty' much correctly, but??
Any thoughts?
OdlG
|
|
|
|
|
If it works in a terminal program I really don't have any help for you except this.
I don't know if it is this issue but these lines could be a potential problem
depending on how COMPORT functions:
COMPORT << "UPLOAD NEW MAP\n";
COMPORT >> number;
There might be a timing issue if all data has not been received from the pic when
COMPORT >> number; is called. As a test you might want to put a delay in to give it time.
COMPORT << "UPLOAD NEW MAP\n";
delay?
COMPORT >> number;
|
|
|
|
|
Thanks for the reply and suggestion.
I think that a delay might help if I am trying to get a string from the PIC to the PC app.
I would HOPE that the Getline function would do the waiting, but ??
speedbump99 wrote: As a test you might want to put a delay in to give it time.
I've thought about trying that, I don't see a delay function in C++ though. Is there one?
In PIC C there is a __delay_us(10); function that would delay, in this case 10 microseconds based on the current clock speed.
Seems that C++ ought to have one. Maybe have to just do a loop?
OdlG
|
|
|
|
|
I kind of doubt that getline will wait for data as it has no way of knowing how
much data to expect.
A quick search for Linux and Delay turned up a sleep() command that may be what you need.
Also a search of "Linux synchronous serial port PIC" showed several of examples where they went through the process of setting the parameters for the serial port and running a loop to retrieve data.
Something like (pseudo code):
while (1)
{
read(1 char);
if char == "\n"
break;
}
You would probably read the text and convert back to integer.
You might try that search.
Hope this helps.
|
|
|
|
|
Thanks for the reply,
speedbump99 wrote: I kind of doubt that getline will wait for data as it has no way of knowing how
much data to expect.
I think it will. In fact there are several versions of the getline function. In one you can specify a char array, max number of chars and a delimiter char. The default delim is '\n'.
I have tried doing it char by char and didn't have any better results. I may try that again as it seems the operator >> only inputs numbers (of various types) and not strings. I think getline must be used for that.
For right now I'm going to get my scope out and see why my reply jumps by two's instead of one with each command sent to the PIC.
I will keep this thread updated.
Thanks all,
OdlG
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
