 |
|
Hi Richard, thanks for your reply.
I've considered this option, but I'm afraid of computation time. Suppose you have to do this every time for every message you receive.
Step 1: Read the info about msg frames from pre-defined file and store it in some array - "Look-up table"
Step 2: On receive message use LOT and then read bit for bit to decode the message. - This step is in my opinion very time expensive for computation.
Sure, you can skip messages, when there is no change, but you have to check with previous result, which can add some additional computation.
Maybe I'm to careful, but I want to pick the right way, before coding myself to dead just to get an unsatisfactory result.
|
|
|
|
|
If you know all the message types and their structures then the best option would be to build those structures into your code. If you cannot do this, and have to rely on this data file, then you could always build your tables at the start of the program. In either case the only time overhead is the extraction of the different fields from the messages, and that is something you have to live with (unless you know how to change the laws of physics).
Use the best guess
|
|
|
|
|
You are right, I can prepare an *.h file where all the structs will be defined and compile the whole program with this h-file. The problem is, when I hava a different project, where the message names differ and even their content, then I had to create new h-file and compile the whole application again with this h-file.
If some other user wants to use this bus monitor for his own project, he won't be able, because he had to prepare this h-file first and then compile it.
So I need to "compile" this file at runtime and add it to the application somehow. Or this is my idea. How this is implemented in real I don't have a clue. 
|
|
|
|
|
HellMaster[cz] wrote: How this is implemented in real I don't have a clue.
I explained how in my earlier message. Read the file at the beginning of the program and create a table containing information about the different message types and their structures. You then use the appropriate entry in the table to decode each message as it arrives.
Use the best guess
|
|
|
|
|
|
Sorry to butt in, but you mentioned this is a bus monitor. I bought a CANbus, rather than LINbus, monitor (CANalyzer) where the whole point was that, yes, you had to write a script to decode and display the messages because as you say, they can be different depending on the application. Though I've seen other low end monitors that simply displayed the bits.
|
|
|
|
|
Hi,
Your fields remind me of dealing with things like CANbus messages, but then the possible structures were known before hand. Is there a common structure you could define that you could copy each instance of input data into putting bits in appropriate places and padding out, or marking fields as empty if not needed?
|
|
|
|
|
Hi Jonathan,
you are right. But insted of handling CANbus messages I'm handling LINbus messages. The frames are really known and are specified in a file called LIN description file *.ldf (the format of file is defined in the specification). But how do I create structs from this file at runtime to use it for decoding a message? Or what would be the best approach?
Basically I would be able to define some struct like:
struct
{
bit0 :1
bit1 :1
bit2 :1
bit3 :1
.
.
.
bit64 :1
}
and then assign all 8 bytes to this struct and decode it bit-by-bit. But seems to me to be still clumsy and slow. Or this is just the only one solution.
Maybe the solution is really clear and simple, but I'm missing something.
|
|
|
|
|
Hi,
I read LINbus is the cheaper alternatic to CANbus used by various car manufacturers, so I doubt it would get there without being easy to interface to.
You can design a system, module, program etc if you know what the messages and interactions are: it's inputs and outputs and the behaviour expected. If you don't know such things, you're in trouble: by that design rule anyway. So I'd check, are these messages really as randomly organized as you think? It could be there are only three of four possibilities, not ten or fifty.
Is there someone writing the code to send these messages that doesn't understand the LINbus spec? I was put off by someones CANbus coding when they said 'it's too complicated, you wouldn't understand'. Their code failed, I got a copy of the CANbus spec, read it, understood it, and we produced a great system.
You can't be the first to have done this. Get in touch with manufacturers of the kit you're using to try and het their demo code and base what you're doing on that. Much easier than starting from scratch.
Or try using Unions, pre-define them for the possible message formats then apply the correct one based on the ID.
|
|
|
|
|
Whatever you do you have to know the structure of every message. You can either create a load of structures in the code before you compile or you can write code that at run time pulls the data apart, which is more work.
If you really have an idf file that defines the data why not write a program that can read the idf file and produce a header file from it? That is if writing the header file yourself is too much.
==============================
Nothing to say.
|
|
|
|
|
Let's say I have a window created and I'm interested on certain region in that window (say rect(10,10,300,300)) and want to somehow crop it and save as an image file.
May I know how can I do this?
|
|
|
|
|
You can copy part of the Window to a new device context using the BitBlt function[^]. This article[^] shows how to save it to a file.
Use the best guess
|
|
|
|
|
Hello all,
Can someone post some sample code on using GetLastInputInfo?
i.e., how to calculate the idle time of the application in MINUTES?
Thanks in advance.
|
|
|
|
|
Hi,
The LASTINPUTINFO structure contains the tick count when the last input event occurred. You would use the [^] GetTickCount function[^] function to get current tick count and then subtract the value obtained from LASTINPUTINFO.dwTime to obtain the number of milliseconds since the last input event. This value divided by 1000 would obviously be the number of seconds since the last input event occurred.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks
This thread is done.
|
|
|
|
|
Hello
I am using GetLastInputInfo() function in my MFC app developed on VS 6.0
For some reason the compiler is saying -
GetLastInputInfo - undeclared idetifier
I have added both windows.h and winuser.h in file.
Also when i place the cursor on top of the function, it actually shows the declaration.
So the editor definitly is able to identify the function.
But the compiler is complaining
Why's this happening?
How to resolve this?
Thanks in advance.
|
|
|
|
|
Maybe this[^] link will help.
|
|
|
|
|
|
Thanks all
I got this fixed.
|
|
|
|
|
Dear all,
I want to write a program in which the main form will transparent to mouse, but the requirement is: when I click on the form, it will turn transparent and let the mouse click through it, but when I drag the mouse, the form will not be transparent so that I can draw on it.
I found many articles teaching how to make a transparent form to mouse by using layered window with ModifyStyleEx and WS_EX_TRANSPARENT bit turned on. But when I press the mouse down, the form looses focus so I cannot catch whenever the mouse is clicked or dragged.
Does anyone have an idea?
Thanks in advance.
|
|
|
|
|
Here is a tip, I haven't tried it! Maybe you should play around by handling the WM_NCHITTEST window message in your program. You can return HTTTRANSPARENT or whatever you want, can pass the message handling to the default window proc, whatever you want. Whit this you may manage to handle mouse messages. Making the form opaque/transparent is another task on top of input handling, you can find lots of tutorials on how to do that correctly.
|
|
|
|
|
Thank you very much for your hint. I played around with WM_NCHITTEST and HTTTRANSPARENT but the form will only avoid my mouse click and does not pass the click event to the beneath window of it
|
|
|
|
|
|
Thank you for finding this for me. I read this before posting my question, but my problem is: When I click through my window, I don't have anyway to get my form receive mouse messages.
|
|
|
|
|
I found a solution: Use a global mouse hook to capture all mouse down event on the screen, and depend on the condition, I can pass this message to the beneath application or destroy it.
|
|
|
|
|
I do not no how to create graph in c++?????????
|
|
|
|
|
Have you tried doing any research for samples or articles?
Use the best guess
|
|
|
|
|
Skinning cats comes to mind.
Steve
|
|
|
|
|
You have several options. Two of them are:
- (The hard way) Use graphics primitives (provided, for instance by
GDI or GDI+) to draw yourself the graph on the screen. - Use a graph control (or a graph library).
Veni, vidi, vici.
|
|
|
|
|
u have two ways to create graph in C++
u can use windows api,SDK(firstly,register window class,then create the window)to create
or u can use MFC to create graph
|
|
|
|
|
In my project, a batch file should be first started to launch cmd windows, as well as initializing some parameters and some background processes. in the cmd windows,my own calculation processes could be started by typing the exe name directly. Now, i've written a MFC application program, and want to implement my calculaiton processes in a dialog button. I want to use ShellExecute where the first paramter is the cmd window handle i've got. Can anybody tell me how to write the shellexexute to post a command line to an existing cmd windows.
many thanks.
|
|
|
|
|
The only method I know is creating a child process with redirected input and output. An example can be found in the MSDN: Creating a Child Process with Redirected Input and Output[^]. But I'm not sure if this can be also done with the command shell itself.
Another option is changing your design to use a master application instead of the batch file that starts all necessary processes where the master application and the processes use some kind of Interprocess Communications[^].
|
|
|
|
|
many thanks, i'll try it.
|
|
|
|
|
Why I can't catch CMainFrame::OnLButtonDblClk in CMainFrame ?
void CMainFrame::OnLButtonDblClk(UINT nFlags, CPoint point)
{
TRACE("Hello\n");
CMDIFrameWnd::OnLButtonDblClk(nFlags, point);
}
I can't see any trace ... Why ?
Thank you.
|
|
|
|
|
From the WM_LBUTTONDBLCLICK entry in the MSDN:
Quote: Posted when the user double-clicks the left mouse button while the cursor is in the client area of a window. If the mouse is not captured, the message is posted to the window beneath the cursor. Otherwise, the message is posted to the window that has captured the mouse.
The message is probably send to a child window of your main frame window (e.g. a view window).
|
|
|
|
|
Well, I would like to catch double-click message on CMainFrame when I haven't any childs open, and on non-child area of CMainFrame.
modified 10-Apr-13 3:00am.
|
|
|
|
|
Does your child view class include CS_DBLCLKS in its specification?
Use the best guess
|
|
|
|
|
No, I think he hasn't, because I had tried that on a default MDI application ...
|
|
|
|
|
U can catch the click in view class
because the message is posted to the CView class by the framework ,not the CMainFrame class
|
|
|
|
|
And when I didn't have any child open ?
|
|
|
|
|
Hello Friends
I am creating a mfc based application which is working fine on WinXP But If I run same application on Win7 then while Starting,a whilte image is appearing and disappearing[ like a white flash image].
But,If I Disable "Enable desktop Composition" option under system dialog named performance Options.Then it is not showing any white flash image.
After that I tried to Disable this option programmatically even,it does but then it fluctuating the screen while startup of application as we are disabling on initializing of application.
So, Any ideas to get rid of this white flash image.
Regards
Y
|
|
|
|
|
Which tools(IDE) did u used created the MFC Application?
applications that created by vc6.0 is not compatible to win7.
I Guess.
|
|
|
|
|
Get the following run time error after making a few changes in my MFC application. Not been able to find where it occurs other than when I click on the OK button of the Main Dialog.
This may be due to a corruption of the heap, which indicates a bug in MFCTest.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while MFCTest.exe has focus.
The output window may have more diagnostic information.
HEAP[MFCTest.exe]: Invalid Address specified to RtlValidateHeap( 003C0000, 003C8E70 )
Windows has triggered a breakpoint in MFCTest.exe.
This may be due to a corruption of the heap, which indicates a bug in MFCTest.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while MFCTest.exe has focus.
The output window may have more diagnostic information.
Object dump complete.
Any suggestions to how to locate this heap problem?
I think I deleted the OK button and then tryied to undo the changes.
grahamfff
|
|
|
|
|
Do you have a handler for the OK button? If so, what's in it?
Does the problem happen when you click the Cancel button?
You mentioned "Main Dialog." Are other dialogs involved?
Does this happen with a basic application, or only after you add other code to it?
Are you linking with other libraries?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
It happens after all the code in the OnBnClose() has run.
I deleted the Cancel button a long time ago.
The are other modal dialogs but they are OK. I think I got confused when I deleted the OnOK() routine and tried to reinstate it. It is using IDOK as a resourse.
Its a big MFC application and I deleted some controls and control variables but seemed to have got in a mess. I can usually sort things out, but this time because its at the program termination phase I am a bit lost as nothing to bebug.
grahamfff
|
|
|
|
|
It's possible the memory corruption is happening way before your OnOK handler is being called; it's just being detected there.
Calling this: http://msdn.microsoft.com/en-us/library/y1132dee%28v=vs.80%29.aspx[^]
at various times will help to localize where this is happening.
Another approach is the Binary Chop Debugging Pattern: Comment out portions of your program and rerun. If the problem remains, the bug isn't in the removed code. This debugging pattern can sometimes localize the bug orders of magnitude faster than trying to find it logically.
Visual Studio 6 had a way to invoke afxCheckMemory () after each operation, which is slow but will find the memory bug when it happens. I haven't seen this facility on later VS versions, though.
|
|
|
|
|
Try enabling the "page heap" for the process. Remember to turn it off when you're done debugging.
Steve
modified 9-Apr-13 2:31am.
|
|
|
|
|
Not done the heap page (as dont know how)
But with the AfxCheckMemory() I get the following, puting the statement in InitDlg() routine.
Again do not understand.
ntdll.dll!7c90120e()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7c96ee31()
ntdll.dll!7c95f8f4()
ntdll.dll!7c96e94d()
ntdll.dll!7c96f586()
ntdll.dll!7c962fcf()
user32.dll!7e418bd9()
user32.dll!7e41885a()
user32.dll!7e42a013()
user32.dll!7e43e577()
user32.dll!7e42a998()
user32.dll!7e43e577()
> mfc90d.dll!CWnd::DefWindowProcA(unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 1043 + 0x20 bytes C++
mfc90d.dll!CWnd::Default() Line 274 C++
mfc90d.dll!CDialog::HandleInitDialog(unsigned int __formal=723394, unsigned int __formal=723394) Line 673 + 0x8 bytes C++
mfc90d.dll!CWnd::OnWndMsg(unsigned int message=272, unsigned int wParam=723394, long lParam=0, long * pResult=0x0013e2dc) Line 2018 + 0x11 bytes C++
mfc90d.dll!CWnd::WindowProc(unsigned int message=272, unsigned int wParam=723394, long lParam=0) Line 1755 + 0x20 bytes C++
mfc90d.dll!AfxCallWndProc(CWnd * pWnd=0x0013e7b4, HWND__ * hWnd=0x00070a0c, unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 240 + 0x1c bytes C++
mfc90d.dll!AfxWndProc(HWND__ * hWnd=0x00070a0c, unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 403 C++
mfc90d.dll!AfxWndProcBase(HWND__ * hWnd=0x00070a0c, unsigned int nMsg=272, unsigned int wParam=723394, long lParam=0) Line 441 + 0x15 bytes C++
user32.dll!7e418734()
user32.dll!7e418816()
user32.dll!7e42927b()
user32.dll!7e42651a()
user32.dll!7e42683e()
user32.dll!7e439b43()
mfc90d.dll!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate=0x00480aa0, CWnd * pParentWnd=0x00000000, HINSTANCE__ * hInst=0x00400000) Line 312 + 0x2a bytes C++
mfc90d.dll!CDialog::DoModal() Line 576 + 0x20 bytes C++
MFCTest.exe!CMFCTestApp::InitInstance() Line 63 + 0xb bytes C++
mfc90d.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00161f0a, int nCmdShow=1) Line 37 + 0xd bytes C++
MFCTest.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00161f0a, int nCmdShow=1) Line 30 C++
MFCTest.exe!__tmainCRTStartup() Line 574 + 0x35 bytes C
MFCTest.exe!WinMainCRTStartup() Line 399 C
kernel32.dll!7c81776f()
grahamfff
|
|
|
|
|
The problem has already occurred before your app explodes. The page heap will tell you more, but it probably happens in CMFCTestApp::InitInstance (or something called from there) but before the call to DoModal.
B
Steve
modified 9-Apr-13 17:08pm.
|
|
|
|
|
Thanks for all who posted.
But as I cannot get a handle on the problem which may be due to using an existing MFC application for a simular one. I deleteled some controls and renamed some of the dialogus and classes (including files names) and seem to have done something that has resulted in the basic framework failing.
Perhaps the Close button problem was a 'red herring' and perhaps best to start again and copy over code snipps as could spend ages on this problem and get nowhere. I always found it difficult to reuse an MFC application.
I have checked butons, textboxes dropdown lists etc and the resourses and event handlers but still the problem remains.
grahamfff
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
Submit an article or tip
Post your Blog
