Author |
Topic: List Box Notification (Read 1509 times) |
|
Matt
Developer
member is offline
Gender: 
Posts: 210
|
 |
List Box Notification
« Thread started on: Aug 2nd, 2013, 2:43pm » |
|
Hi,
Is there some setting that might restrict the return of a notification? This is a routine that I've been using and until now has been reporting all notifications. However, it has now stopped returning all but LBN_SETFOCUS and LBN_DBLCLK.
Code: DEF FN_clickp(RETURN H%, RETURN L%, RETURN P%)
LOCAL c%(), d%()
DIM c%(1), d%(1)
ON SYS LOCAL c%() = @wparam%, @lparam% : RETURN
c%() = 0
REPEAT
d%() = 0
WAIT 1
SWAP c%(), d%()
UNTIL d%(0) <> 0 OR d%(1) <> 0
H% = d%(0) DIV &10000 : L% = d%(0) MOD &10000 : P% = d%(1)
PRINT H%, L% : REM to test the notifications
= FALSE
While selecting a list box, I cannot get LBN_SELCHANGE.
I use this routine in other programs and it seems to work fine. I cannot find a difference in the set up of the list boxes or use of the procedure in any of the programs.
Matt
|
|
 Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Box Notification
« Reply #1 on: Aug 2nd, 2013, 4:22pm » |
|
on Aug 2nd, 2013, 2:43pm, Matt wrote:| I use this routine in other programs and it seems to work fine. |
|
The flaw with the routine is that it doesn't guarantee that every notification will be seen. If two or more notifications arrive in quick succession (which is common with some controls) it is likely that you will miss one of them - usually the first. What's worse is that it may be highly variable - you may see both events when run on a fast machine but not on a slower one. Or you may see both events when no other process is running but only one if another process is occupying some CPU time.
If two or more notifications can arrive in quick succession, and it's essential that you see both of them, then you need to use a different technique. One way is to call a procedure:
Code: ON SYS LOCAL PROChandler(@wparam%, @lparam%) : RETURN
Alternatively you can implement an event queue:
http://bb4w.wikispaces.com/Queueing+event+interrupts
(note the comment at the top about using the EVENTLIB library).
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: List Box Notification
« Reply #2 on: Aug 2nd, 2013, 7:50pm » |
|
on Aug 2nd, 2013, 4:22pm, Richard Russell wrote:One way is to call a procedure:
Alternatively you can implement an event queue:
|
|
No matter how I do it, I can't get all the notifications. When I call the procedure, I get SET and KILL focus, but not SELCHANGE or DBLCLK
Quote:(note the comment at the top about using the EVENTLIB library).
|
|
I don't get a link to this. There doesn't seem to be a link on the wiki page, and EVENTLIB is not in the BB4W LIBs.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Box Notification
« Reply #3 on: Aug 2nd, 2013, 8:49pm » |
|
on Aug 2nd, 2013, 7:50pm, Matt wrote:| No matter how I do it, I can't get all the notifications. When I call the procedure, I get SET and KILL focus, but not SELCHANGE or DBLCLK |
|
I can think of one possible explanation. WINLIB2 automatically sets the LBS_NOTIFY style bit, but the documentation doesn't tell you that. So if, not knowing that the bit is set by default, you specify LBS_NOTIFY in your PROC_listbox() call the two will 'cancel out' and the bit will end up not being set - the opposite of what you intended!
Check the final parameter of your PROC_listbox() call and if you've included LBS_NOTIFY in the style value, remove it.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: List Box Notification
« Reply #4 on: Aug 3rd, 2013, 05:17am » |
|
Hi, Richard,
Thanks for all your help.
I have finally figured out what the problem was. As many of the other controls cause other actions to take place, I added a 'global' (within the proc) PROC_setfocus to the main dialog box. Removing this allowed all the notifications to be sent. (This isn't the best way of explaining, and I'm sure you could explain it better. I'd be interested to know exactly what is happening, as I'm not fully aware of what's actually going on - only that it now works.)
It now means that I have to add more setfocusses to each diversion.
Thanks again.
Matt.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Box Notification
« Reply #5 on: Aug 3rd, 2013, 09:29am » |
|
on Aug 3rd, 2013, 05:17am, Matt wrote:| I'd be interested to know exactly what is happening |
|
I don't know, but I do know that you should never use SetFocus with a dialogue box. There's a special message provided WM_NEXTDLGCTL which you should use instead:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms645432.aspx
"This message performs additional dialog box management operations beyond those performed by the SetFocus function".
So it's probable that missing out on the "additional management functions" is the cause of your problem.
I would additionally point out that, of course, the dialogue box itself (i.e. the parent window of the controls) never has input focus - there is nothing to receive input - and if you attempt to SetFocus to such a window you are likely to break all sorts of things.
Richard.
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: List Box Notification
« Reply #6 on: Aug 3rd, 2013, 8:07pm » |
|
on Aug 3rd, 2013, 09:29am, Richard Russell wrote:I do know that you should never use SetFocus with a dialogue box. There's a special message provided WM_NEXTDLGCTL which you should use instead...
I would additionally point out that, of course, the dialogue box itself (i.e. the parent window of the controls) never has input focus - there is nothing to receive input - and if you attempt to SetFocus to such a window you are likely to break all sorts of things. |
|
When the user clicks on one of the buttons in the dialog box, a message box may appear. When they dismiss it, the focus returns to the main window, not the dialog box. I've always used PROC_setfocus(!dlg%) to return focus to the dialog box. If you're telling me that this could cause problems and I should use WM_NEXTDLGCTL instead, I'll have to find out where and how to use it, as I'm not used to using WM_ commands.
Thanks.
Matt
|
|
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: List Box Notification
« Reply #7 on: Aug 3rd, 2013, 8:52pm » |
|
In place of a setfocus command, which immediately followed the close of the message box, I tried putting
SYS "PostMessage", dlg%, WM_NEXTDLGCTL, 0, 0
which seemed to me to be what the MSDN page was suggesting. Using PostMessage rather than SendMessage (although I tried both), and 0, 0 as this should force the focus to be on the next tabstop.
I think!
However, it didn't work. I'm obviously missing something.
I also tried using a different approach with the setfocus.
SYS "GetDlgItem", !dlg%, id% TO focus%
PROC_setfocus(focus%)
As the control, id%, can receive input, it should be able to have focus. No? Is this still a potential for problems?
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Box Notification
« Reply #8 on: Aug 3rd, 2013, 8:55pm » |
|
on Aug 3rd, 2013, 8:07pm, Matt wrote:| When the user clicks on one of the buttons in the dialog box, a message box may appear. When they dismiss it, the focus returns to the main window, not the dialog box |
|
I'm somewhat surprised. What owner window are you specifying for the MessageBox? It's important that you pass the window handle of the dialogue box as the owner, not (for example) @hwnd% or zero:
Code: SYS "MessageBox", !myDlg%, message$, title$, type%
Quote:| I'm not used to using WM_ commands. |
|
This same issue came up only recently in the thread Changing the style of a dialog control when you wanted to send the EM_SETREADONLY message. The answer is exactly the same: you need to call SendMessage or PostMessage (arguably the most important functions in the entire Windows API).
Richard.
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Box Notification
« Reply #9 on: Aug 3rd, 2013, 11:20pm » |
|
on Aug 3rd, 2013, 8:52pm, Matt wrote:| SYS "PostMessage", dlg%, WM_NEXTDLGCTL, 0, 0 |
|
Without seeing the rest of your code I can't be sure, but shouldn't dlg% be !dlg% here?
Quote:| Is this still a potential for problems? |
|
Did you miss my earlier message? I answered that, and even linked to the MSDN page which explains why it is.
But I still worry that you've rather lost the plot. I wouldn't have expected dismissing a Message Box to cause the focus to be lost. I think you should be attempting to fix that, rather than working around it.
Richard.
|
| « Last Edit: Aug 3rd, 2013, 11:29pm by admin » |
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: List Box Notification
« Reply #10 on: Aug 4th, 2013, 06:29am » |
|
Quote:| It's important that you pass the window handle of the dialogue box as the owner, not (for example) @hwnd% or zero. |
|
I've always assumed that 'handle of owner window' was the main window, i.e. @hwnd%. I didn't realise that 'owner' was the window directly from which the message box was produced. Without going through the entire BB4W help, it always states @hwnd% without specifying anything different, and I've always assumed it to be for all messages, etc. My lack of understanding, I think. This changes all.
Quote:| Did you miss my earlier message? I answered that, and even linked to the MSDN page which explains why it is. |
|
I did read it, but you stated that I shouldn't use the dialog box to set the focus to, as "there is nothing to receive input". However, using one of the dialog controls that does receive input seemed to be a logical step from your statement.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Box Notification
« Reply #11 on: Aug 4th, 2013, 09:48am » |
|
on Aug 4th, 2013, 06:29am, Matt wrote:| I've always assumed that 'handle of owner window' was the main window, i.e. @hwnd%. I didn't realise that 'owner' was the window directly from which the message box was produced. |
|
Think about why the MessageBox API would need to know what the owner window is. There are basically two reasons:
- So it knows where in the Z-order the message box should be displayed. If you specify @hwnd% rather than the dialogue box handle it's entirely possible that Windows will display the message box (invisibly) behind the dialogue box - I've seen it happen.
- So it knows what window should receive the input focus when the message box is dismissed.
Quote:| Without going through the entire BB4W help, it always states @hwnd% without specifying anything different |
|
Well, yes, because @hwnd% is the only window created by BB4W. It's the one window you know will always exist, and in the great majority of programs it's the only window which does exist. It would be unwieldy and confusing to add after every reference to @hwnd% "substitute the handle of your dialogue box if any". Edit: but I have now added a comment to the MessageBox section.
More generally, if you call the Windows API it is assumed that you will have a reasonable understanding of the internal workings of Windows itself, especially things like how windows are created, how they are identified (e.g. handles) and how they communicate (e.g. messages).
Quote:| I did read it, but you stated that I shouldn't use the dialog box to set the focus to, as "there is nothing to receive input". However, using one of the dialog controls that does receive input seemed to be a logical step from your statement. |
|
I also said "There's a special message provided WM_NEXTDLGCTL which you should use instead" and, quoting from MSDN, "This message performs additional dialog box management operations beyond those performed by the SetFocus function". From those comments it should have been clear that calling PROC_setfocus on a dialogue control is not safe.
Richard.
|
| « Last Edit: Aug 4th, 2013, 10:02am by admin » |
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: List Box Notification
« Reply #12 on: Aug 4th, 2013, 12:55pm » |
|
on Aug 4th, 2013, 09:48am, Richard Russell wrote:| So it knows where in the Z-order the message box should be displayed. If you specify @hwnd% rather than the dialogue box handle it's entirely possible that Windows will display the message box (invisibly) behind the dialogue box - I've seen it happen. |
|
That answers a big question.
Quote:| More generally, if you call the Windows API it is assumed that you will have a reasonable understanding of the internal workings of Windows itself, especially things like how windows are created, how they are identified (e.g. handles) and how they communicate (e.g. messages). |
|
Perhaps. But the more I find out about calling the Windows API, the more I realise how little I know about Windows itself.
Quote:| I also said "There's a special message provided WM_NEXTDLGCTL which you should use instead" and, quoting from MSDN, "This message performs additional dialog box management operations beyond those performed by the SetFocus function". From those comments it should have been clear that calling PROC_setfocus on a dialogue control is not safe. |
|
May it should have, but to me all it says is that using WM_NEXTDLGCTL is better than SetFocus, not that it should be used instead of.
But thanks for clarifying.
Matt
|
|
Logged
|
|
|
|
admin
Administrator
member is offline
Posts: 1145
|
|
Re: List Box Notification
« Reply #13 on: Aug 4th, 2013, 4:40pm » |
|
on Aug 4th, 2013, 12:55pm, Matt wrote:| to me all it says is that using WM_NEXTDLGCTL is better than SetFocus, not that it should be used instead of. |
|
If it's better that can only mean that the alternative is for it not to work correctly in some fashion or other. Since when is software that doesn't work correctly acceptable? You almost seem to be saying that you don't mind your software failing, so long as it fails only a little bit!
Richard.
|
| « Last Edit: Aug 4th, 2013, 4:42pm by admin » |
Logged
|
|
|
|
Matt
Developer
member is offline
Gender:
Posts: 210
|
|
Re: List Box Notification
« Reply #14 on: Aug 5th, 2013, 04:49am » |
|
on Aug 4th, 2013, 4:40pm, Richard Russell wrote:| If it's better that can only mean that the alternative is for it not to work correctly in some fashion or other. Since when is software that doesn't work correctly acceptable? You almost seem to be saying that you don't mind your software failing, so long as it fails only a little bit! |
|
On the contrary, on both accounts.
MDSN states 'This message performs additional dialog box management operations beyond those performed by the SetFocus function' (emphasis added). This means that whereas SetFocus works, WM_NEXTDLGCTL does more!
I definitely do mind my software failing, but I'm also happy to use a method that is simple and does the job. If another method that does more but is more complicated (not that I'm saying in this case that WM_NEXTDLGCTL is more complicated) then why use it?
Matt
|
|
Logged
|
|
|
|
|
