Focus Handle of Multiwin Output Window

[MattC]

Hi (again).

The program I'm writing uses multiple output windows using the MULTIWIN library. The function FN_createwin returns the handle of the created window. I am using a mouse to access items on the output screen but I need to know that the output window is selected. All the 'window focus' routines only return the main output window, returning @hwnd% . As much as this is, to some extent, useful, it would be good to have the current child window's handle, to guarantee the focus. Is there a routine available.

I tried using either:

Code: Select all

      SYS "GetForegroundWindow" TO hwnd%

and

Code: Select all

      DEF FN_getfocus(hwnd%)
      LOCAL H%, O%, W%
      SYS "GetWindowThreadProcessId", hwnd%, 0 TO W%
      SYS "GetCurrentThreadId" TO O%
      SYS "AttachThreadInput", O%, W%, TRUE
      SYS "GetFocus" TO H%
      SYS "AttachThreadInput", O%, W%, FALSE
      = H%

Neither of which gives me the current child output window's handle.

(Not sure where I got the second one from, but I've been using it on and off for ages.)

Thanks

Matt

[KenDown]

Hmmm. I have multiple windows and although I don't need to ensure that one of them has the focus, I do need to know which one is being accessed by the program, which I guess comes down to the same thing.

SYS"GetForegroundWindow"TOhw%
IFhw%=hw1%ORhw%=hw2%ORhw%=hw3%ORhw%=hw5%ORhw%=hw6%ELSEENDPROC

hw1% hw2% etc are the handles of the windows that are created with FN_createwin. I can only suggest that perhaps it is the hwnd%, which is perhaps too similar to @hwnd%? You haven't used it more than once, have you?

[MattC]

I tried so many variations of different things that I may have just overlooked 'GetForegroundWindow'. Thanks.

I would be surprised if BB4W got confused with hwnd% and @hwnd%. Particularly as @... is a system variable. But I will investigate what you have brought up.

Thanks.

Matt

[RichardRussell]

As much as this is, to some extent, useful, it would be good to have the current child window's handle, to guarantee the focus. Is there a routine available?

Possibly I'm missing the point entirely, but surely the current (child) window's handle is, by definition, @hwnd%? If you need to test whether the currently-selected window is the main output window, I would have expected that it would be as simple as comparing the current value of @hwnd% with the value it had when the program started. Something like:

Code: Select all

      REM At the start of the program:
      HwndOrig% = @hwnd%
      ...
      REM When you want to perform the test:
      IF @hwnd% = HwndOrig% THEN ....

If I've got the wrong end of the stick, sorry.

[MattC]

Thank you, Richard, for responding to this. It's been many months since I worked on this one, and I seem to remember tackling the problem from a different direction. If I get chance I'll have a look again.

Thanks again,

Matt

[RichardRussell]

Thank you, Richard, for responding to this. It's been many months since I worked on this one

I know it's a late reply, but I have only recently rejoined the forum, and I am shortly going to leave again, so I'm trying to work through as many outstanding issues as possible before then. It's all rather unfortunate really, because the very fact that I am bombarding the forum with messages (for what I think is a justifiable reason) is really winding up those who complain about me - it's one of my 'habits' that they don't like - making my early departure even more certain.

I'm surprised you didn't receive the same suggestion when you first asked the question. BB4W and BBCSDL users should be familiar with @hwnd% being the handle of the 'current' window, and with it changing as you switch windows when using the Multiwin library. It doesn't take much thought to realise that @hwnd% must change like that, for example suppose you want to set the window title with:

Code: Select all

      SYS "SetWindowText", @hwnd%, "New title"
or
      SYS "SDL_SetWindowTitle", @hwnd%, "New title", @memhdc%

If @hwnd% wasn't the handle of the 'current' window the wrong title would be changed!

[MattC]

Thanks Richard,

I will definitely look at this when I get round to it. The issue will undoubtedly come up in another program.

As to your first comment, and I know this isn't the right thread, but I for one will be very sorry to see you go. If that is your decision, then I wish you all the very best.

Matt

[KenDown]

Hmmmm. I've only just come across this thread and I am assuming that the comments apply to BB4W? The Help states "@hwnd% The 'window handle' for BASIC's program (output) window" which I have always understood to mean the window which opens when you start your program. Thus if you are using MultiWin it would be the equivalent of window 0.

Perhaps, to make the matter clearer to dimwits like me, the Help should read "@hwnd% The 'window handle' for BASIC's program current output window"?

[RichardRussell]

Perhaps, to make the matter clearer to dimwits like me, the Help should read "@hwnd% The 'window handle' for BASIC's program current output window"?

No, that would make the documentation less accurate, not more. @hwnd% is a system variable, and although the manual recommends that such variables should be considered read-only and not written to, there are circumstances when writing to them (with extreme care) is appropriate, and the multiwin library does. That is the only reason why @hwnd 'tracks' the currently-selected window when multiwin is in use.

But that behaviour is specific to multiwin, it's not a property of BB4W or BBCSDL. An alternative library could create additional windows but not write to @hwnd%, then the modification you propose would make the documentation incorrect. Such a library is WINLIB2x which creates a dialogue box: the dialogue box is clearly the 'current' output window, but @hwnd% is not its handle.

All one can say with confidence is that @hwnd% is the handle of the window to which BB4W or BBCSDL output text and graphics using the common built-in features of the language (PRINT, PLOT etc.) because that is what it is for. But whether that corresponds to the 'current' window or not (however you define that) will depend on the way that 'current' window has been created and how output is written to it.

So the phrase 'output window' is accurate without being more precise than can be justified given how different libraries behave.

[KenDown]

Ah. Thanks for the clarification.