|
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
|
|
|
|
|
Thanks for your effort Richard. Probably you are right. I'll be thinking about some different solution, but meanwhile I'll try to implement something you suggested.
Thank you very much for your time and advices!
|
|
|
|
|
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++?????????
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
