Questions and Answers
Written by Larry Salomon, Jr.
Welcome to this month's "Q&A"! Each month, I collect various items that fit into this column sent to me via email. The ones that I feel contribute the most to developers, whether in terms of information or as a nifty trick to tuck into your cap, get published in this column.
To submit an item, send it via email to my address - email@example.com - and be sure to grant permission to publish it (those that forget will not be considered for publication). This month, we have the following:
Q?:Keith Murray (firstname.lastname@example.org) writes: Your book has given me a lot of help with a lot of things. It does a good job of talking about ownerdrawn listboxes. There is one omission however. How do you deal with horizontal scrolling? I've got to the point of being able to draw my graphic and measure everything correctly. Vertical scrolling works just great and the horizontal scroll bar seems scaled correctly. But I don't know what to do from there. How do I figure out where to draw my text relative to the scroll bar?
A:Since you seem to know how to draw the text, what you are really asking is how do you query the position of the horizontal scrollbar. In order to do this, you need to send the scrollbar an SBM_QUERYPOS message. But you don't have the handle of the scrollbar!
The code for the queryLbScroll() function, which will return what you want, you can find in horscroll.txt.
Thanks to Gordon Zeglinski (email@example.com) for this submission. He writes:
Comment: The documentation states that the WinSwitchToProgram() has no effect if the calling program does not have the focus. This apparently is not true, as my app will switch an app to the foreground regardless of whether it has the focus or not.
According to one of the original PM developers, who will remain nameless in case I get this wrong, code within a window procedure is only executing when it is the foreground process. This is related, I believe, to the synchronized system input queue, and a host of other design-of-PM related issues which I will not go into (mainly because I'm not entirely confident of the accuracy of my knowledge). Thus, if you are calling WinSwitchToProgram() from within your window procedure or any function (in)directly called by your window procedure, you must be the foreground process.
I am not sure what would happen if an application started a second thread which creates a message queue, does some processing, and calls this function without utilizing window procedures in any way, but I imagine the behavior described in the documentation would be observed.