|
Hi. I have a simple app, explorer type, with treeview in left side, and listview in right side. On both of them, I handled OnRClick menu, and they are working fine. It is a possibility to fire them using [^]menu key from keyboard ?
|
|
|
|
|
What happens when you try it?
|
|
|
|
|
Nothing  ... obviously that I have tried, but the popup menu fired on right click, does nothing when I hit menu key from keyboard ...
|
|
|
|
|
|
Yes, that is possible. You have to handle the appropriate message which is the WM_CONTEXTMENU message (Windows)[^].
That message will be send upon the context menu key press, Shift+F10, and when releasing the right mouse button.
|
|
|
|
|
Perfect ! I have just tested, and is working !! Thank you !
|
|
|
|
|
Hello,
In the list control, we have the function to get the top index in MFC, GetTopIndex(), but how can we have the index of the visible last row of the list control whether we scroll it or not? I am asking this question because I have to put a design on the bottom of the last row, even if I scroll it should stay on the last row's bottom. How should I refer to the last visible row programmatically?
Thanks in advance.
modified 23-Apr-17 7:52am.
|
|
|
|
|
If there's not a method for it loop from the first to the last item and when ItemIsVisible returns false break the loop the previous item was at the bottom.
|
|
|
|
|
Thanks, but this is not serving my purpose! Thanks anyways
|
|
|
|
|
The CListCtrl class provides the function GetCountPerPage()[^]:
Quote: Calculates the number of items that can fit vertically in the visible area of a list view control when in list view or report view.
Use that to calculate the index of the item visible on the bottom:
int MyListCtrl::GetBottomIndex() const
{
int n = GetTopIndex() + GetCountPerPage() - 1;
if (n >= GetItemCount())
n = GetItemCount() - 1;
return n;
}
|
|
|
|
|
Many thanks, i will try this one out!
|
|
|
|
|
|
|
Well, do you know what the Eigenvalues and Eigenvectors are?
|
|
|
|
|
|
I read a demo code from a semiconductor producer, in cpu.h, there are some typedef structs for registers.
typedef struct {
u32_T asid;
struct {
u32_T ASID:10,
rsvd1:22;
};
} ASID_T;
According to the comments, I think the writer thought he defined a struct to represent the asid register, and the struct can be accessed in 32 bit pattern or bit-field way.
But, is this struct can do that, I mean, are the U32_T asid and the anonymous struct share a same memory location? I think it can't work. just want to hear some other opinions.
modified 21-Apr-17 15:42pm.
|
|
|
|
|
They don't share the same memory location. To do that the outer struct must be a union (see Union declaration - cppreference.com[^] ).
From my point of view you are right that it looks like a definition for shared access and that is an error in the documentation. To verify this have a look at the register specifications in the data sheet.
|
|
|
|
|
How about this struct:
typedef struct {
struct {
u32_T ASID:10,
rsvd1:22;
} asid;
} ASID_T;
it can implement the 32-bit access and bit access, right?
|
|
|
|
|
With that you have no access to the 32-bit value.
Use a union instead:
typedef union {
u32_T asid;
struct {
u32_T ASID:10,
rsvd1:22;
};
} ASID_T;
|
|
|
|
|
can't use union, MISRA-C rule 18.4, forbid to use union.
|
|
|
|
|
Then use what you need in your code (struct or u32_T).
As last resort you can also use casting:
ASID_T *asid = ASID_REG_ADDR;
u32_T *asidReg = (u32_T*)asid;
|
|
|
|
|
From memory that breaks several other MISRA-C rules under section 11 ... 11.1 through 11.6 restrict what you can do with C casts.
Hardware related implementations usually involve coding that MISRA rules see as "dangerous". I can tell you from experience the easiest way around them is drag it down to included assembler blocks. The assembler blocks fall outside the scope of MISRA.
You could define two different extern's in a .h file to the same register with assembler which would essentially restore the use of the union yet be MISRA compliant 
In vino veritas
modified 25-Apr-17 10:57am.
|
|
|
|
|
I suspected that casting may be limited too.
I don't know MISRA rules well but when macros - or better - inline functions are allowed those can be used to split the 32-bit value into bits fields or vice versa.
|
|
|
|
|
No those are still technically C and hence under MISRA rules.
It's a really weird standard adopted by some automobile manufacturers and a few telco's as some sort of we will get better code think-tank. The reality is all studies have shown it has almost zero improvement on software bug numbers or severity.
As I said, the few times I have run across it, I do what most do ... drop to assembler and go around the rubbish. That in itself tells you how good the standard is.
Other than that you can go thru the process to raise a deviation (section 5.3.2) but that means documenting and getting approval for the variation which is far more red tape than most can handle.
The standard libraries are also exempt from MISRA under a special rule 6.6 and so you can implement your own special standard library function to get around it. Think about it memcpy and memmove take void* and you have a specific register address target
In vino veritas
modified 25-Apr-17 12:34pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
