Differences in window handling between Carbon and Cocoa?

[Andre]

I have a main (background) window for my project, which uses the "borderless" window flag. Smaller windows on top of this main window are created with standard flag "systemmenu"... This smaller windows can be moved around, can be minimized or can be activated by clicking on it. So far this should be the "standard working method" of regular windows...

After compiling my project now with PB5.00 using the Cocoa framework I noticed the following:
1) If a smaller window is behind of an other one, I can click on the window and it gets the focus, but it will stay behind the other one...
2) If I move a smaller window to a new position, and then use my "window selector" (which is nothing more than a combobox in the main window with all opened but maybe minimized smaller windows, for selecting the requested window and bringing it back to the display using the 3 commands HideWindow(WinID, 0), SetWindowState(WinID, #PB_Window_Normal) and SetActiveWindow(WinID), then it will not just be maximized / brought to the top. No it will also be moved back to its initial position.

This behaviour didn't happen until PB4.61 and also not with the current PB5.00 beta8 and '/Carbon' switch.

So there must be something different on Cocoa. Any ideas, what's going on here?

Thanks

[Andre]

I come back to this topic after trying to find a workaround, but nothing...

Anyone more who noticed a change in window handling after switching to PB5.00 and Cocoa framework?

In addition to the described problems I've just a very "simple thing" to check out:
I've a main window (always in the background) and several more smaller windows opened on top of the main window.
When I switch from one small window to the other one (by clicking on it, when it's in the background...), this will get the focus, but is not put to the foreground.

When I do the same on MS Windows (XP) it works as expected and even with the /Carbon switch...

So is this an issue with PB5.00 or with the Cocoa framework itself?

(My try of a workaround using "Case #PB_Event_ActivateWindow" in the event loop, and then doing a "SetActiveWindow(EventWindow)" doesn't help here. This should also not be needed, as each window (of the actual program) which get the focus, should also be shown in the foreground, or?)

[Andre]

No one noticed the described problems yet?

To illustrate it I've made a screenshot about the 1st problem:


As you can see I have 2 smaller windows in front of the main background window. From the 2 smaller windows I have opened the window about "Afghanistan" (see window title) at first, and then the window about "Algerien".
Now I've clicked on the first opened window (Afghanistan) again - as you can see, it has got the focus but is not put to the foreground.

Is that normal? On MS Windows this works without any problems...

About the 2nd problem there would be need a video to illustrate it, but I hope it can be checked/confirmed also without this additional effort.

[Shardik]

André,

I am sure your problem would get much more attention if you could provide us with a small demo code which demonstrates this problem. Often when trying to reproduce what appears to be a bug by stripping down the code to the essential code lines, I often detected the error in my own code. By only describing your problem (and even by providing a screen shot which makes it at least easier to understand your problem) it's much more difficult for others to help. They have to start trying to reproduce your posted errror which is often more difficult and time consuming for us than to strip down the code to a few lines for you...

Perhaps you may take my example code (which doesn't show your reported error) as a starting point and modify it in a way that your problem will be demonstrated.

Code: Select all

OpenWindow(0, 0, 0, 1, 1, "Background window", #PB_Window_SystemMenu | #PB_Window_MaximizeGadget | #PB_Window_MinimizeGadget)
SetWindowState(0, #PB_Window_Maximize)

OpenWindow(1, 270, 100, 200, 170, "Child window 1")
OpenWindow(2, 370, 200, 200, 170, "Child window 2")

Repeat
Until WaitWindowEvent() = #PB_Event_CloseWindow

[Andre]

Hi Shardik,

yes I know about the "provide a code example, and you will get help much faster..."

But my problem here is: I've a large project, in which I wasn't able to track down the reason for the described problem. Especially why it happens on MacOS, but not on Windows.

And I couldn't find any MacOS-only code (having only a few CompilerIf sections), which could cause something like a (not wanted) "put the window to the background"....

On the other side, I already tried with a small code example based on window/event handling examples in the PB manuel, in which the described problem doesn't occur.... so I have to investigate this further

Anyway - do you have any ideas, for which things I should be aware of? Or does exist any MacOS-specific window handling issues?

Thanks for any help!

[Shardik]

André,

you should try the following code line to bring your partially hidden active window to the front relative to all your other windows:

Code: Select all

CocoaMessage(0, WindowID(x), "orderWindow:", 1, "relativeTo:", 0)

In PB 5.10 Beta 1 you may replace CocoaMessage() with the new CocoaMessage() statement. Wilbert's CocoaMessage userlib isn't necessary anymore in PB 5.10 because Fred has integrated it in PB 5.10 and changed the name to the more PureBasic-like CocoaMessage().

With WindowID(x) you designate the window you want to appear on top of the other ones. You have to replace x with the number of your want-to-be top window.

The value 1 following "orderWindow:" is the value of the Cocoa constant NSWindowAbove. This value determines the position of your window in relation to other windows. You may declare that constant at the top of your program with

Code: Select all

#NSWindowAbove = 1

and use #NSWindowAbove instead of the value 1 for a better readability.

The value 0 following "relativeTo:" places your want-to-be top window above all your other windows. You may also use WindowID(y) instead of 0 to place your want-to-be top window only above window y.

[Andre]

Hi Shardik,

thanks a lot for your help. I will try it out as soon as possible...

But beside that "workaround" - do you know about any MacOS / Cocoa "issues", which could cause this behaviour (which isn't on Windows..)? Thanks again!

[Andre]

I just came back to this topic and I'm still trying to reproduce the described behavoir in my project (= windows not coming to front, if clicking on a child window...)... still with no success, even with the mentioned CocoaMessage().

The related part of my main event loop is looking like this:

Code: Select all

        If EventWindow > 0    ; not the MainWin
          CompilerIf #PB_Compiler_OS = #PB_OS_MacOS  ; unsucessful workaround  according to this problem: http://www.purebasic.fr/english/viewtopic.php?f=19&t=51970
            Debug "PB_Event_ActivateWindow received:"
            Debug "  EventWindow = " + EventWindow
            Debug "  WindowID(EventWindow) = " + WindowID(EventWindow)
            Debug "  WindowTitle = " + GetWindowTitle(EventWindow)
            CocoaMessage(0, WindowID(EventWindow), "orderWindow:", 1, "relativeTo:", 0)
          ;  SetActiveWindow(EventWindow)
          CompilerEndIf
          WinSelector_Update(EventWindow)
          ;While WindowEvent() : Wend
        EndIf

As the debug output is working correctly (even confirming that the right window was detected, by printing its window title), I'm sure that CocoaMessage command is executed. And it should be correct, or?


By the way, I found out by extending shardik's example code, that using ParentWindowID is causing the child windows to ignore the given x + y coordinates.... an Cocoa limitation or a PB bug?

Here is the code:

Code: Select all

OpenWindow(0, 0, 0, 1000, 800, "Background window", #PB_Window_BorderLess)
SetWindowState(0, #PB_Window_Maximize)
ButtonGadget(0, 0, 2, 30, 22, ".")
             
OpenWindow(1, 270, 100, 200, 170, "Child window 1", WindowID(0))
OpenWindow(2, 370, 200, 200, 170, "Child window 2", WindowID(0))

Repeat
  event = WaitWindowEvent()
  If event = #PB_Event_Gadget
    If EventGadget() = 0
      End
    EndIf
  EndIf
Until event = #PB_Event_CloseWindow

[wilbert]

I just came back to this topic and I'm still trying to reproduce the described behavoir in my project (= windows not coming to front, if clicking on a child window...)... still with no success, even with the mentioned CocoaMessage().

You could try one of the following two lines to see if it makes a difference.

CocoaMessage(0, WindowID(MyWindow), "orderFront:", #nil)

CocoaMessage(0, WindowID(MyWindow), "makeKeyAndOrderFront:", #nil)

[Andre]

@wilbert: thanks for your suggestion, but sorry none of the two works. Still the same, the already opened child window get the focus, but don't come to the front when clicking on it... :-/

Just in case, anyone think that I do something conflicting with this wanted behavior in my code, here is the code of the WinSelector_Update() function (handling a combobox containing all opened child windows):

Code: Select all

Procedure WinSelector_Update(WindowID)
  Protected position = 0, ID
  Protected number_items
  number_items = CountGadgetItems(#Gadget_WindowSelector)
  While position < number_items And ID <> WindowID
    ID = GetGadgetItemData(#Gadget_WindowSelector, position)
    position + 1
  Wend
  
  If ID = WindowID
    position - 1
    SetGadgetState(#Gadget_WindowSelector, position)
  EndIf
EndProcedure

As you can see, there is nothing special affecting the windows.... even commenting this function call doesn't help.

[Andre]

I tested further modifications of the CocoaMessage() calls like the following. All didn't work...

Code: Select all

            CocoaMessage(0, WindowID(EventWindow), "orderWindow:", 1, "relativeTo:", 0)
            ;CocoaMessage(0, WindowID(EventWindow), "orderWindow:", 1, "relativeTo:", WindowID(0))
            ;CocoaMessage(0, WindowID(EventWindow), "orderFront:", #nil)
            ;CocoaMessage(0, WindowID(EventWindow), "makeKeyAndOrderFront:", #nil)
            ;CocoaMessage(0, WindowID(EventWindow), "orderFront:", WindowID(0))
            ;CocoaMessage(0, WindowID(EventWindow), "makeKeyAndOrderFront:", 0)

(Note: main window has WindowID = 0, and all child windows are #PB_Any-created windows with high and unique ID number, which we got in the EventWindow variable here)

Any more ideas, which MacOS API calls I can test? Thanks in advance!

[Andre]

As there was no real solution to my problem (I still think it's a PB and/or Cocoa issue with a main borderless parent window in the background, and several child windows with borders in the foreground), I'm now hiding / displaying again the ChildWindows using HideWindow() if they got the focus as a workaround.