Known Bugs

[richmond62]

OK: re your new MenuBar livecodescript file you sent me off-list;

1. If I do a drag-select across multiple objects the GROUP item in the Mac drop-down menu is dimmed out (= no dice).

2. If I select each object with my SHIFT-key depressed the GROUP item in the Mac drop-down menu is visible, AND the things GROUP.

Subsequently (seems a lot of this crud has a lot to do with the order you do things):

Having UNGROUPED the group, and doing a drag-select the GROUP item in the Mac drop-down menu becomes visible, but does NOT function.

[tperry2x]

If I select each object with my SHIFT-key depressed the GROUP item in the Mac drop-down menu is visible, AND the things GROUP.

Moving forward then...
I wonder if you get the same result as I do here:
If you make two empty blank images by dragging them off the tools palette, shift-click them both and try to group them.
Will they then not group? That's what I'm getting here.

So much so, that I placed a 'put' command in strategically while I'm trying to track this bug down. This was so that if the menus registered something being clicked - they are supposed to refresh and it'll run through a list of the menus being generated in the message box. However, if you have two blank images selected - these messages don't even fire off - so no wonder the options aren't working. This also means that if you have two blank images selected, NONE of the menuitems seem to work!

selection-no-work.gif (353.03 KiB) Viewed 8986 times

BUT, without these two empty images selected - you can see the message fire off as expected:

menu-draw-after-OXTL.gif (379.51 KiB) Viewed 8985 times

[tperry2x]

To my primitive mind, surely this should fire WHEN the menubar is clicked, not AFTER the mouse is released on a menuitem otherwise what is generated for the menu is always out of date?


Meaning if you shift-selected a field and a button, then clicked the menubar.
Then, shift-select a button and a popup button - then click the menubar again - the information shown in the menubar relates to the field and a button you selected, not what your current selection is?

Does the same in LCC 9.6.3 too.

menu-draw-after-LCC.gif (275.91 KiB) Viewed 8980 times

[richmond62]

Those animated GIFs make my eyes go funny and confuse me.

If you make two empty blank images by dragging them off the tools palette, shift-click them both and try to group them.

No:
-

SShot 2024-06-28 at 14.06.02.png (29.94 KiB) Viewed 8974 times

-

[richmond62]

BUT: on shift selecting a graphic and a button the GROUP thing works:
-

SShot 2024-06-28 at 14.13.00.png (36.02 KiB) Viewed 8972 times

[tperry2x]

Those animated GIFs make my eyes go funny and confuse me

The gist of it is, the update message to the menus don't get sent when two empty graphics are selected.
No menuitems seem to work when two empty graphics are selected.
Also, the menu update message doesn't actually trigger until the menu is closed, so in theory it could always be out of date with what is actually selected.

In a nutshell.
Thanks for confirming in your tests about the two ungroupable images. That's what I'm getting here so it's consistent. Glad you are at least able to group things in some fashion now, improvements to follow soon (hopefully!)

[tperry2x]

If you check for updates now, you are aiming to be on 202406271556 after applying them.
Once that's done, please can you try and see if it's working.
Tested and working again here (MacOS 12.7.4)

[richmond62]

SShot 2024-06-28 at 16.49.34.png (10.71 KiB) Viewed 8958 times

-
Sadistic teacher gave kids an end-of-year-exit-test.

Oooer:
-

SShot 2024-06-28 at 16.52.14.png (28.17 KiB) Viewed 8958 times

-
Um:
-

SShot 2024-06-28 at 16.53.07.png (12.01 KiB) Viewed 8957 times

[richmond62]

SShot 2024-06-28 at 16.54.20.png (26.86 KiB) Viewed 8956 times

-
We shall see . . .

SHIFT-select.
On the money.
-

shift-select.png (26.41 KiB) Viewed 8956 times

-
ALSO works with a mouse-drag select.

Fantastic work!

[richmond62]

So: at home with my MacOS 12.7.* iMac and:
-

Screenshot 2024-06-29 at 11.35.00.png (55.64 KiB) Viewed 8938 times

-
Err: OXT Lite 1.05 update 3,456

and this 'confection' was groupable (there's another slightly dubious word) without a hitch:
-

Screenshot 2024-06-29 at 11.33.15.png (226.12 KiB) Viewed 8938 times

-
2 Vectors, 1 pull-down menu, one field.
-

up.jpg (8.37 KiB) Viewed 8938 times

[tperry2x]

That's great news. Think I can label this as fixed now.
That picture threw me for a moment, until I realised that both shapes were unfilled - otherwise I was about to wonder what had happened to the paths.

say-what.png (16.17 KiB) Viewed 8927 times

That's about as clear as mud: "The art or process of confecting".... As in "What have you confected lately?"
"Sorry, I didn't respond sooner. I was busy confecting something."

[richmond62]

So: "All Excited" now that you have sorted out the GROUP problem in OXT Lite on MacOS 12 & 15: so slightly black-afronted to find that

Code: Select all

on mouseDown
grab me
end mouseDown

STILL crashes the stack.

[tperry2x]

Just seen this.
I worked out a solution, but I don't know why it's an issue.
The crash happens because the engine doesn't know if you want to drag it or show the popup control. (it seemingly can't do both at the same time).
Edit: your stack crashes on Linux too, and it also crashes in LCC 9.6.3 on Linux - so it's not a bug specific to OXT Lite.
I can work around it by preventing the drag if the menus are active - as attached

Turtle Challenge.oxtstack

(108.23 KiB) Downloaded 130 times

edit: does the same in Windows 11 too when I tested this morning.
Instead of blocking the drag operation, if the popup is open, via individual script (like I have to do currently), it would be better to make the engine close any open popup menu before the grab happens. That would need changing in-engine though.

[tperry2x]

Edit 2: now changes the cursor to a grab / and releases the grab when it's dragged / let go of.

Turtle Challenge 2.oxtstack

(108.36 KiB) Downloaded 135 times

[tperry2x]

Menu bug (possibly), or at least inconsistent.

If you want to disable a menuitem, the menubuilder shows you can do this with a ( prefixed before the menuitem.
(Note - here the 'Open' menuitem is disabled).

menu.png (58.42 KiB) Viewed 8703 times

Fine, but applying the same thing to a button which displays a menu does not disable it.

nope.png (9.05 KiB) Viewed 8703 times

[OpenXTalkPaul]

Menu bug (possibly), or at least inconsistent.

If you want to disable a menuitem, the menubuilder shows you can do this with a ( prefixed before the menuitem.
(Note - here the 'Open' menuitem is disabled).
menu.png

Fine, but applying the same thing to a button which displays a menu does not disable it.
nope.png

Yeah this is annoyingly inconsistent, in the Font menu in pre-existing Property Inspector with those xTalk placeholder fake font names that have parenthesis around their names like '(Menu Font)'. These pseudo 'fonts' are greyed out because of the lead '(' character. I think that's an option-menu styled button. Has anyone ever actually use those placeholder font names to style their text?

[tperry2x]

Another one. Resizing a stack.
From the dictionary:

The resizeStack message is sent after the resizing is finished. This means that you cannot prevent a stack|stack's size from being changed by trap|trapping this message.

Not so for Linux. This is the case for MacOS though.
The resizeStack message is sent during a stack resize on linux, so this means that you can indeed prevent a stack's size from being changed by trapping this message.

I've yet to test this in Windows.

[OpenXTalkPaul]

prevent a stack's size from being changed by trapping this message.

I understand that you're pointing out an inconsistency in behavior on different platforms, but I just want to mention that you can always prevent a stack's size from being changed from any script by setting the stacks resizable property to false.

[tperry2x]

Yes, this is really to hilight the innacuracy in the dictionary and the inconsistency in the IDE.

[tperry2x]

In fact, I have another.
topRight.
Should actually be called rightTop, as item 1 is the horizontal and item 2 of the topRight is the vertical.
The same goes for topLeft, bottomRight and bottomLeft.

Again, from the dictionary:

The topRight of a stack is in absolute coordinates|absolute (screen) coordinates. The first item (the right) of a card|card's topRight property is always the width of the stack window; the second item (the top) is always zero. The topRight of a group or control is in relative coordinates|relative (window) coordinates.

But the naming convention would lead you to believe that item 1 is the Top and item 2 is the Right, or is that too logical?