|
You'll need to post your code as I have several examples of doing this and it works fine.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom
Please tell me what I'm doing wrong.
Thanks
void CDlgListboxTest::OnBtnRemove()
{
int nSelectedItem = m_lbTest.GetCurSel();
if (nSelectedItem != LB_ERR)
m_lbTest.DeleteString(nSelectedItem);
UpdateControls();
}
void CDlgListboxTest::UpdateControls()
{
BOOL bEnable = FALSE;
int nSelectedItem = m_lbTest.GetCurSel();
if (nSelectedItem != LB_ERR)
bEnable = TRUE;
m_btnModify.EnableWindow(bEnable);
m_btnRemove.EnableWindow(bEnable);
}
|
|
|
|
|
I've got to go to a meeting with a client now, but if someone hasn't helped you by this evening, I'll see if I can.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
[d3m0n] wrote:
BOOL bEnable = FALSE; int nSelectedItem = m_lbTest.GetCurSel();
Here is the error! after Deleting the item from LIST,
The current selection of list is LB_ERR. So bEnable is always FALSE
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
Thanks for the reply but I think you may have misunderstood.
After removing the item, the button SHOULD be disabled, because there is no item to remove (so I don't want the Remove button enabled).
My issue is that after I disable the button, the dialog has lost the focus and I cannot tab or cancel the dialog.
This problem is quite strange I think 
Cheers
|
|
|
|
|
The problem isn't the bEnable state for the buttons but the focus of the list box, right?
If so, maybe this will help:
This code sets the selection to a new item (since the one that was previously selected was removed) and sets the focus on the list box/control:
LVITEM lvItem;<br />
::ZeroMemory(&lvItem,sizeof(LVITEM));<br />
lvItem.stateMask = LVIS_SELECTED;<br />
lvItem.mask = LVIF_STATE;<br />
lvItem.state = LVIS_SELECTED; <br />
m_TaskList.SetItemState(nItem,&lvItem);<br />
m_TaskList.SetFocus();
|
|
|
|
|
I whipped up a quick project and experienced the same thing.
It did work for me however if I set the focus to the add button prior to disable:
<br />
void CTestDlg::UpdateControls()<br />
{<br />
BOOL bEnable = FALSE;<br />
<br />
int nSelectedItem = m_listBox.GetCurSel();<br />
if (nSelectedItem != LB_ERR)<br />
bEnable = TRUE;<br />
<br />
if (!bEnable)<br />
m_btnAdd.SetFocus();<br />
<br />
<br />
m_btnModify.EnableWindow(bEnable);<br />
m_btnRemove.EnableWindow(bEnable);<br />
}<br />
I also tried using UpdateDialogControls w/command handlers, which worked, (autoset focus to list box when last item was removed) but it requires more work:
to the .h add
<br />
afx_msg LRESULT OnKickIdle(WPARAM wParam, LPARAM lParam);<br />
to the .cpp add
<br />
ON_MESSAGE(WM_KICKIDLE, OnKickIdle)<br />
<br />
LRESULT CTestDlg::OnKickIdle(WPARAM wParam, LPARAM lParam)<br />
{<br />
UNREFERENCED_PARAMETER(wParam);<br />
UNREFERENCED_PARAMETER(lParam);<br />
UpdateDialogControls(this, FALSE);<br />
return (0);<br />
}<br />
<br />
* For each button that needs to be enabled/disabled:
in .h, add:
<br />
afx_msg void OnUpdatexxxButton(CCmdUI* pCmdUI);<br />
in .cpp add:
<br />
ON_UPDATE_COMMAND_UI(IDC_xxx_BUTTON, OnUpdatexxxButton)<br />
<br />
void CTestDlg::OnUpdatexxxButton(CCmdUI* pCmdUI)<br />
{<br />
pCmdUI->Enable(m_listBox.GetCurSel() != LB_ERR);<br />
}<br />
* You could also group their IDs if you wanted using ON_UPDATE_COMMAND_UI_RANGE
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Thanks Jack, I added loads of m_btnAdd.SetFocus() calls everywhere and now it works. I'm sure I did this before but obviously not...
Anyway thanks everyone for replying. Wicked. 
Cheers
d3m0n
|
|
|
|
|
So why not just set the focus to one of the other controls, namely the listbox?
[d3m0n] wrote:
I tried adding a m_pbtnAdd->SetFocus() to the OnBtnRemove function, but it makes no difference.
Why would you put focus on a control that has been disabled?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
The Add button is never disabled. As I said, I already tried setting the focus to the Add button however this didn't work before. I've got it working this way now though.
Cheers
|
|
|
|
|
I made no reference to the Add button.
When I remove an item from a list, I expect the "next" item in the list to be selected, but the Remove button to retain focus. That way I can click the Remove button quickly from the keyboard. If there are no more items in the list, the Remove button should be disabled and the focus should go to some other control (e.g., the listbox or the Add button).
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
You did refer to the Add button, when you quoted me:
[d3m0n] wrote:
I tried adding a m_pbtnAdd->SetFocus() to the OnBtnRemove function, but it makes no difference.
Why would you put focus on a control that has been disabled?
So I was just saying that the Add button is not disabled
However I do agree with what you say about the focus remaining on the Remove button until there are no more items left in the listbox. I will try and implement this. Good idea.
Cheers
d3m0n
|
|
|
|
|
You're right. The indirect reference was my bad.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hi,
Does anybody know how to receive an SMS on PocketPC in C++?
Thanks
Good coding...
|
|
|
|
|
I'm designing a system that will interoperate with a Unix system. The Unix system is responsible for getting information to a Windows Service that I'll write. So far, we've whittled our choices down to two obvious options: sockets and file-drop-off.
Both scenarios have their advantanges and disadvanages. I'm leaning towards th file drop off as time is of the essense and it's much easier to simply set up a filesystem event to fire on a new file being created than to create a sockets server. I also believe that security is easier with files as Windows security will inherently be used as opposed to having a port open for anyone to try and use.
Anyway, opinions are greatly appreciated.....
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
It's Sound something like NMS (Network Management software) .
My personel choice will be Sockets, But would like to know how are you implementing File-Drop-Off method?.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
I'm just starting this project today and the client wants to use one of these techniques. The file-drop-off technique would be either setting a time and looking for a file in the drop-off folder or creating an event with the OS to tell the app when a new file has been dropped (I know this works with .NET, but have never tried it with native code.)
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
The file-drop-off technique would be either setting a time and looking for a file in the drop-off folder or creating an event with the OS to tell the app when a new file has been dropped
For that you have to constantly watch the DROPOFF folder for file.Directory operation always be slower then that of Sockets.
Secondly, you will got instant notification for data arrival and data request in case of Sockets.
But I would like to mention in End, Every thing depends upon client !
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
Agreed with respect to split second response. However, the advantages of file-drop-off are easier implementation and security. Especially with the latter, it's much better to tell the client that security is inherent with their Windows security model as opposed to telling them that they'll have to leave a port open for our modules to talk to one another.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
the advantages of file-drop-off are easier implementation and security.
But You are atleast sharing a common folder to implement FILE-DROP-OFF feature!. this can bring trouble in long run when you implement it on site!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
Tom Archer wrote:
I know this works with .NET, but have never tried it with native code
It's a bit different but not too difficult. The main difference is that the FindFirstChangeNotification() function returns a handle that can be waited on with WaitForSingleObject() or WaitForMultipleObjects(). When the handle is signalled, you call ReadDirectoryChanges() to get the changes that have been made. Generally you would run this in a separate thread and signal your main thread when a change has been made.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thanks for the info, Ryan. We're going to implement a sockets server, but this info is good to know.
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
|
Tom Archer wrote:
We're going to implement a sockets server
It's Nice to know that you are implementing Socket server!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
|
|
|
|
The file drop-off will probably be easier to implement at this stage than a sockets-based system, although it then limits communication to unidirectional - are you certain you won't need to talk back to the Unix system in the future? If so, sockets might be easier in the long term.
Another option is to setup a web server on the Unix system and connect to it from your service. That way you can use the Win32 Internet functions to make life simple, and the security is built in to the webserver already. The only problem with that is that the server generally can't signal the client when new data is available.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I met with my new team today. It's definitely gotta be sockets as the server is going to make dozens of requests within the context of a logical "conversation" and it would be seriously kludgy for us to continually interact via files (as I also have to return information regarding the work performed on Windows).
Cheers,
Tom Archer - Archer Consulting Group
"So look up ahead at times to come, despair is not for us. We have a world and more to see, while this remains behind." - James N. Rowe
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
