|
Use SetExtendedStyle:
CListCtrl m_list;
m_list.SetExtendedStyle(LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES);
|
|
|
|
|
Using
SendMessage(LVM_SETEXTENDEDLISTVIEWSTYLE,
LVS_EX_TRACKSELECT | LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES,
LVS_EX_TRACKSELECT | LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES);
in "OnUpdate" works.
It also activates editing!
(cs.style |= LVS_REPORT | LVS_EDITLABELS;)
So what is cs.dwExstyle good for in PreCreateWindow ???
(cs.dwExStyle |= LVS_EX_TRACKSELECT| LVS_EX_FULLROWSELECT | LVS_EX_GRIDLINES;)
Thanks for your help.
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: So what is cs.dwExstyle good for in PreCreateWindow ???
For the most part, that would be the correct place to set an extended style.
Some controls have special requirements though, as you've seen.
Consistent, huh? 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Don't you love this MS "binary" logic?
"Yes No .... Maybe"
I guess using transistors is the whole problem, if MS stuck with diodes we would be OK.
Have a great day anyway. Nice to hear from you.
Vaclav
|
|
|
|
|
I have a small bit of code that looks something like the example here. It's just a small example I wrote to illustrate to myself how to properly pass arrays of objects around... The node object just contains an integer.
<br />
#include "node.h"<br />
<br />
node** makeArray();<br />
<br />
using namespace std;<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
node** myArray;<br />
myArray = makeArray();<br />
<br />
cout << "The array contains..." << endl;<br />
<br />
cout << (*myArray)->toString() << endl;<br />
myArray++;<br />
cout << (*myArray)->toString() << endl;<br />
myArray++;<br />
cout << (*myArray)->toString() << endl;<br />
}<br />
<br />
node** makeArray()<br />
{<br />
node* out = new node*[3];
<br />
node* test1 = new node(7);
node* test2 = new node(3);<br />
node* test3 = new node(9);<br />
<br />
out[0] = test1;
out[1] = test2;<br />
out[2] = test3;<br />
<br />
cout << out[0]->toString() << endl;<br />
cout << out[1]->toString() << endl;<br />
cout << out[2]->toString() << endl;<br />
<br />
return out;<br />
}<br />
So the makeArray() function passes back a pointer to an array of nodes. Then I can do things to each node in the array by moving around in it with myArray++ or myArray--.
The question is this (or, I guess, questions)... the array has to be dynamically allocated in makeArray() so it won't go out of scope when the function returns. So when I'm done using the array, I should delete it somehow... what is the preferred way? Would it suffice to simply do "delete myArray" after I use it in main? Do I need to decrement it twice first? Should I use delete[]? Do I need to delete twice since it's a double pointer? Do I need to delete each node individually as well? What is the proper procedure in this case?
Thanks!
|
|
|
|
|
|
MALDATA wrote: Then I can do things to each node in the array by moving around in it with myArray++ or myArray--.
Which will cause problems if you ever want to delete that pointer.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I assume that means that I need to go back to the initial value of the pointer (the one that was returned from the function) before deleting it... is that correct?
What I'm getting from these responses it that I should do a "delete" for each node pointer in the array first, then a "delete[]" on the array pointer itself as opposed to "delete"...
Let me know if that's all ok. Thanks!
|
|
|
|
|
MALDATA wrote: I assume that means that I need to go back to the initial value of the pointer (the one that was returned from the function) before deleting it... is that correct?
Yes.
MALDATA wrote: What I'm getting from these responses it that I should do a "delete" for each node pointer in the array first, then a "delete[]" on the array pointer itself as opposed to "delete"...
Yes, that's because new goes with delete, and new[] goes with delete[].
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
what I'm trying to so is set up my complete Dialog before it is shown to the user.
Hence, I want to populate some CStatic's and a CEdit. However, I keep getting an Assert error when I populate the CStatic with text. (haven't gotten to the other CStatic's and CEdit yet).
To summarize what I've got and to pick on the first Assert error
the Dialog Editor shows that the static text ID is: IDC_FW_VERSION
within the Dialog's .h file, the static text is listed as:
public: CStatic m_staticFwVersion;
within the Dialog's .cpp file, ::DoDataExchange():
DDX_Control(pDX, IDC_FW_VERSION, m_staticFwVersion);
However, this code (within OnInitDialog) fails every time with the Assert error:
<br />
CString strVersion;<br />
strVersion.Format("FW Ver %x.%02x, CheckSum = %03x, POST %x %s%s", <br />
(Attributes.VersionNumber >> 8) & 0xff,<br />
(Attributes.VersionNumber >> 0) & 0xff,<br />
nChecksum, nPostResult,(!nPostResult) ? "PASS" : "FAIL",PostResults);<br />
m_staticFwVersion.SetWindowText(strVersion);<br />
the CString comes out to be a typical null terminated string.
The debugger shows me the failure point:
void CWnd::SetWindowText(LPCTSTR lpszString)<br />
{<br />
ENSURE(this);<br />
ENSURE(::IsWindow(m_hWnd) || (m_pCtrlSite != NULL));
both, m_hWnd and m_pCtrlSite are 0
so where should I initialize the static texts ?
|
|
|
|
|
OnInitDialog is the right place to do this. try stepping into that DDX_Control call, to make sure it's really linking the control to that variable.
|
|
|
|
|
I've put a breakpoint at :
void S2000_CP_DLG::DoDataExchange(CDataExchange* pDX)<br />
{<br />
CDialog::DoDataExchange(pDX);<br />
DDX_Control(pDX, IDC_FW_VERSION, m_staticFwVersion);
DDX_Control(pDX, IDC_MESSAGES, m_editMessages);
}
and it doesn't hit after :
m_staticFwVersion.SetWindowText(strVersion);
|
|
|
|
|
make sure you're calling UpdateData
|
|
|
|
|
That worked 
BOOL MY_DLG::OnInitDialog()<br />
{<br />
BOOL bSuccess;<br />
bSuccess = UpdateData(FALSE);<br />
.<br />
.<br />
.<br />
}
|
|
|
|
|
Hi..
If u want to diplay 'strVersion' on Static Control, just go with SetDlgItemText.
|
|
|
|
|
As has been said, SetDlgItemText is the way to go if you only want to set the static's text once.
But your current problem is probably that DoDataExchange hasn't been called yet.
CDialog::OnInitDialog calls UpdateData (FALSE) which in turn calls DoDataExchange. I bet you've added your code before the CDialog::OnInitDialog that the MFC wizards put in for you.
Iain.
|
|
|
|
|
abiemann wrote: However, I keep getting an Assert error when I populate the CStatic with text.
Most likely because the control does not yet exist.
abiemann wrote: However, this code (within OnInitDialog) fails every time with the Assert error:
Does this code get called after CDialog::OnInitDialog() is called?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
this code:
#include "myDlg.h"
....
BOOL CSistemaPOSDlg::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message==WM_KEYDOWN
{
switch ( pMsg->wParam )
{
case 106: // '*' was pressed - Asterisc numeric keyboard
CallMyDlg();
break;
case VK_RETURN:
.........
break;
default:
break;
}
}
return CDialog::PreTranslateMessage(pMsg);
}
BOOL CSistemaPOSDlg::CallMyDlg()
{
CmyDlg pDlg;
pDlg.DoModal()
}
Pretranslate return me an Assertion failed when return from myDlg!! Way??
|
|
|
|
|
What is the reason for the assertion? Where does it occur?
Is there a reason you need to handle messages in PreTranslateMessage()
instead of handling them the usual MFC way?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Just try to call the CDialog::PreTranslateMessage(pMsg) before the CallMyDlg(). I think the problem is because the DoModal will initiate a different message loop, thus the current message may be handled by this second message loop. So when the CDialog::PreTranslateMessage is called, the current message will be different or none. (Only a guess  ) )
- NS -
|
|
|
|
|
Does Exist a way to release, or kill the loop from myDlg before return to the parent?
|
|
|
|
|
You mean exit from the application?
Or simply skip the current loop of PreTranslateMsg?
- NS -
|
|
|
|
|
the current loop, may be only with return;
|
|
|
|
|
I think you need to skip the * key hit, right? If so you can just assign pMsg->message = WM_NULL. Then the allowing the current loop to continue.
- NS -
|
|
|
|
|
I have an application where we display the image from a framegrabber. Before it used to work fine, but last week I reinstalled XP since my RAID0 has failed. Now, whenever I run the SAME applicaiton it shows the video fine, but freezes briefly whenever I use any drop down menus on the application's interface and then runs fine again. THis happens only for drop down menus while it works fine when I use any other scroll bars and slide bars, buttons on the interface.
Has anyone came across such a problem before?? The only difference is new XP installation.
thanks
Pavan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
