Known Bugs

[tperry2x]

Another menu bug in linux.
As per this gif, I've done this for comparison, so you can see the same bug exists in LCC9.

menubug-linux.gif (365.05 KiB) Viewed 1701 times

If you click a menu and keep your mouse held down,
with the mouse still down, move onto the next menu, the menu will display incorrectly.

This is in LCC and subsequently OXT.
However, it's not as straightforward - the menu won't necessarily be invisible like on the first gif.
It's dependent on what the system theme is doing.

with-alt-theme.gif (121.45 KiB) Viewed 1701 times

For example, this is the same machine, just a different theme selected. You can see how while the menu hilite displays differently, it's still incorrect.

It should just be a matter of fixing the hilite behavior when the mouse leaves the button - so the fact this behaves differently when different themes are applied, stems from the fact that it's the hilite not being reset correctly.

[tperry2x]

Known bugs (bug ID: 23713 in LCC)
If you popup a button via script, straight after dismissing an answer dialog, you get a script error that the button wasn't found.
This is the workaround for that. The solution is 2-part (the cursor needs to also be over an IDE window).

answer-then-popup.png (11.45 KiB) Viewed 640 times

[axwald]

Well,

Another menu bug in linux.

Anybody ever noticed that the LC IDE on Win, since ages, had a quite "unique menu behavior"?
Quite often you need to click twice to get a menu. But not always, for sure.
Sometimes LC takes ages to recognize a menuChoice. Often, it responds immediately.

Quite sure there's about 100 bugreports. In any case, if menus ever worked as was to be expected from a well-written program, it was on Macs. And only Macs, as usual.

May your cat never carry ticks to your bed!

[tperry2x]

May your cat never carry ticks to your bed!

I had found that instead of using switch case statements in the menus, if you use if else statements, these seem to be a bit faster.

As far as I can tell, switch case seems slower than else if (if you are dealing with complex statements). The other thing I found is in a switch statement, MacOS is very sensitive. By that I mean, you have to keep your switch statements very brief and pass to another handler, as in:

Code: Select all

case "Edit Group"
   revIDEActionEditGroup
      break
case "Select Grouped"
   revIDEToggle "Select Grouped Controls"
      break
case "Messages"
   revIDEToggle "Suppress Messages"
      break
... -- and so on

Notice how they all break off to other handlers and functions as soon as possible.

If you did:

Code: Select all

case "Edit Group"
   set the defaultStack to the topStack
   if word 1 of pGroup is "group" then
      if revMenuManagerGroup(pGroup) then
         answer error "Can't edit group that is in use by the Menu Manager.  To edit this group close the Menu Manager."
         exit revIDEEditGroup
      end if
      start editing pGroup
...-- and so on

You crash the engine on MacOS.
This is what I inadvertently caused here (took me a while to find the previous post again)


All three platforms have their own issues with menus.

• Microsoft Windows has the occasional "click-twice" one you mentioned (Seems to be worse on Windows 7 and 10 by the way - seemed fine when I last tested in Windows 11)

• Linux occasionally has a huge delay (memory trap error) but then will correct itself at random and re-release the memory.

• MacOS has this issue with the switch case. MacOS also has an error with the menu class being changed (as Paul rightly points out here), and causing an execution (SIGSEGV "KERN_INVALID_ADDRESS") error in Sonoma+.

Menus seem to be a real issue for the IDE. So much so, I was looking at alternative ways to draw them.

Neville is spot on here - producing a custom menu behaviour for Mac users would be frowned on. Even worse in a standalone. If someone is reading this who's a skilled C++ programmer, I'm all ears.

I also want to rule out the idea of having a "microsoft-style office 'ribbon' thing" to replace menus. I don't like ribbon menus in the slightest. (I'm quite picky really aren't I)
I think I should do another mockup. Something that perhaps Mac user's won't instantly frown at, but something that avoids using the menubar would be an idea I think.

The thing is, it's really easy to completely mess up the revMenubar stack (as I did above and caused that spectacular system crash on MacOS) and Richmond knows how easy it is to confuse it. I have made myself a mantra: "Thou must not mess with the revMenubar stack".
Messing about with it = lots of headaches, because of how interwoven it is with the rest of the IDE. When I make a change to the menus, I test and test and test... and then test - purely because I don't want a repeat of that screenshot above. It's a bit embarrassing, and a pain in the bum for everyone else.

[OpenXTalkPaul]

This is in LCC and subsequently OXT.
However, it's not as straightforward - the menu won't necessarily be invisible like on the first gif.

just a different theme selected. You can see how while the menu hilite displays differently, it's still incorrect.

I think on Linux that is mostly due to all of the UI themes floating around the net that do not fully implement every aspect of a the desktop theme standards. I say that because I've seen this sort of issue happen with other Linux apps (like file managers) with certain themes. As I've mentioned at one point, and as far as I can tell unlike the Windows and Mac engines, you can manually style the menu buttons which would overriding the system's theme. I did that on OXT DPE RC4 .appimage package so that disabled menu-items would still be somewhat readable on a dark-theme styled menu. On Windows you can effect a menus style only partially, and on macOS you cannot override the system theme, (without some xTension Builder FFI hackery that is).