I am using GetLastInputInfo in my MFC app to find the idle time for the app, but in my testing i found that it's giving system wide idle time.
The reason i found that out is, i opened my app and let it stay on the background, and opened the outlook and started playing around with it. My app was supposed to be timed out after 1 min, but it didn't.
Then i stopped playing with outlook for a minute, and then my app timed out.
My take on GetLastInputInfo is that it's per user session not per application. To do what you need? I'm not sure. Maybe create a thread that listens for user input events sent to you app, and sends notification to your app to close after the specified time?
I am a beginner for Metro app development and trying to use the keydown event but not the keyup event with a text box element on the XAML. I have created two key event functions (up and down) from the text box, which are the below. The problem is the keydown function works only when the key is up but not down. If I hold the key press down, the event does not come out until the key up, which is the same as the keyup function.
I am working to get keyboard input from the touch softkeyboard. For example, after invoking the touch keyboard with the text box element, I like to play a unique sound only when a key (e.g., 'Q' or 'K') is pressed.
Anyone knows how to fix this problem? I also appreciate that you can help me know the alternative way with an example source code. Thank you a lot in advance.
Here comes the tricky part. I want to print out the specific information hidden in the 8 bytes. I can define the structures for every msg ID and compile the program with this "special" header file, but I want to do it during runtime of the program, loading the information regarding the msgs, because i can have different projects where the information for different msg IDs can differ.
I've a non-C file, where basically all the information is written. Lets stay frame named
bit 0 - 7 width
bit 8 - 15 height
How to read it on runtime and decode the messages? On runtime I'm not able to create variables and structures anymore!
Any advices? Is some sort of scripting language the solution? Which, how?
With that information it is just a matter of decoding the structure and processing each element of the message. in pseudocode form something like:
string title := structure_header
while NOT end_of_structure
int field_start := next_word // the starting field position
int field_end := next_word // the ending field position
int field_width := (field_end + 1) - field_start
string field_name := next_word // the field's name
// add code to extract the data and print according to the above variables
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).
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.
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.
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.
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?
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:
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.
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.
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.