OpenXTalk Forums

@tPerry2x, you can actually run v7 (by using v8 Engine with the v7 IDE), v8 and v9 (with Tom's patch) on all macOS versions 10.6/10.9 through 14.
I think the those compatibility problems come because the Engine/IDE hasn't always done everything in the normal / standard OS way. For example system-wide tab-able windows were added in macOS 10.12, but LC never supported that, instead the Engine remove those AppKit standard menus and then had issues with that they subsequently fixed (you can see system-tabbed-windows in the IDE by running LC CE v7.x or 8 on macOS 10.12+). I suspect they removed that OS provided feature (hidden really) simply because they could not (easily) support that feature across all three desktop platforms. The point is they've done some things in ways that go against the OS' the standard way of doing things.

OpenXTalkPaul wrote: ↑Fri Apr 26, 2024 10:58 pm I think the those compatibility problems come because the Engine/IDE hasn't always done everything in the normal / standard OS way...The point is they've done some things in ways that go against the OS' the standard way of doing things.

Yes, that's precisely it. The way the LCC menubar is drawn is very non standard, and without me mentioning hooks and API's, it can be better described as: other programs going from MacOS 11 to MacOS 14 don't need a menu patch to function.
The LCC menus are kind of drawn-in, by the engine and then attempts to hide the OS-provided menubar as a mask. (so you kind of draw 2 menus simultaneously on MacOS). There's a slight init delay when it does this, but seems like they used the standard method in the 9.7 source as it's changed quite a bit. If I'm interpreting the c++ correctly, it seems like they've conformed to the OS-method.

tperry2x wrote: ↑Fri Apr 26, 2024 11:12 pm

OpenXTalkPaul wrote: ↑Fri Apr 26, 2024 10:58 pm I think the those compatibility problems come because the Engine/IDE hasn't always done everything in the normal / standard OS way...The point is they've done some things in ways that go against the OS' the standard way of doing things.

Yes, that's precisely it. The way the LCC menubar is drawn is very non standard, and without me mentioning hooks and API's, it can be better described as: other programs going from MacOS 11 to MacOS 14 don't need a menu patch to function.
The LCC menus are kind of drawn-in, by the engine and then attempts to hide the OS-provided menubar as a mask. (so you kind of draw 2 menus simultaneously on MacOS). There's a slight init delay when it does this, but seems like they used the standard method in the 9.7 source as it's changed quite a bit. If I'm interpreting the c++ correctly, it seems like they've conformed to the OS-method.

Yes, to be a little more Objective C-ish: it creates its own sub-class of NSmenu bar, and swaps it in replacing the standard AppKit menubar. It does this subclassing with other objects such as NSWidows too, the objects the engine creates begin with MC (MetaCard) in the instance's subclass name (seen via ext.builder FFI handler). The Engine app does create the macOS standard NSApp singleton, NSResponder. etc., which can be used via Ext.Builder FFI for more control over the Engine ( at the risk of crashing the engine of course).
I'm pretty sure I could write an extension that creates the normal OS NSmenu bar, but I think such an extension would have to contend with the Engine trying to replace it again? Hmmm... I'll have to take look again at that Mac System Menubar Extension that came with LC CE 9.x (Trevor DeVore's work I think). I'm sure that menu persists across scripts that rebuild the menubar.