What I want to do is be able to tab though those windows. I read something about CreateDialongIndirect, is that how I have to create the windows? This is going in a window, not a dialog box.
Not tabs, tab, as in that button right above Caps Lock. I want to press that, and change the focus from IDE_AW to IDE_AA. Just like you do in a form in a browser, except this isn't a browser. :)
Subclassing all the controls on the form will definitely work (which allows you to capture all keypresses to the control in question), but might not be the most elegant solution.
IsDialogMessage() might be a better solution, and is used in your message pump.
Then how do I create the controls? Or do I leave them as they are, and then simple adding the IsDialogMessage check to message loop will cause tab to work between them?
I tried adding this:
if(!IsDialogMessage(glbWin.hScrollContent, &msg))
All that did was make it not beep when I pressed [Tab], however, it still doesn't change to the next edit box.
I show the proper use of IsDialogMessage in the message pump to allow tabbing between controls. Another thing that must be done to get this to work is add the tab stop style to the child window controls, and tabbing will occur in the order the controls are created.
I imagine you are still working on that scrolling pane program of yours, and I have to say I've never tried that IsDialogMessage with that program architecture. I imagine it should work, but what should work and what actually does isn't always the same, for me at least.
If that works its the better solution. If it doesn't I'd recommend you go to subclassing the child window controls, because I guarantee that WILL work. That's what I've always done in my Windows CE programs under that scrolling pane scenerio. That example I referenced above shows both techniques, and has a lot of explanation in it. And its in C++; not PowerBASIC. Actually, there is a PowerBASIC version of it there too, now that I think of it. Anyway, I frequently use the subclassing option because I oftentimes want to trap other keystrokes besides TAB, such as [ENTER], etc., and subclassing gives you the actual address of the child control's Window Procedure within Windows, and you get to take a crack at the messages even before the default Window Procedure for the control does.
Ahh, I tried the horse, and I tried the carriage, but it wasn't till I put them together that they went so well... I'm feeling metaphoric. :)
I had tried WS_TABSTOP before, and I'd tried IsDialogMessage, but you must use them together for them to work.
On a double side note, I'd gotten the scrolling to work quite well, with help in another thread, I even have it working for the mouse to be able to scroll. However, what's the easiest way to make it scroll when the cursor goes out of view when using [Tab]?
Oh, BTW, I didn't read the full tutorial you posted, (It looked long and boring) but as I half skimmed it, I did like the method of using a DWORD to store the styles.
Ahhh! You're catching on and asking all the right questions! I'm in unknown territory there though. I wouldn't know how to do that myself without experimenting with it. I suppose that's why I always used the subclassing technique on my apps where I have a scrolling pane window, as I'd use a switch construct in the sub class proc that would select on the ctrl id of the control, about which I'd know the location on the form. For example, if someone would hit the tab key or enter key or cursor down key when focus would be in the bottom control presently visible, I'd
SendMessage() a SB_PAGEDOWN message to the window which would then show the next virtual pane.