Known Bugs

Organizing tasks to work on, New Features Ideas, Building LCS & LCB Libraries & Widgets, Redecorating and Modifying the IDE, Hacking / Editing Tools, Compiling the Engine from Source, etc.
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

Nice! I love discovering stuff like that that's undocumented (or became lost to history as with the 'EPS control').

BTW, since we're on the subject of Property Inspector, the graphics effects editor has bug where the stack popup with the sliders that control the effects get all discombobulated after editing the FX settings and then reopening that editor stack again, until you click OK to close again and then reopen that pop-up stack which then displays the sliders normally again. I haven't investigated this properly yet, but I'm guessing probably something like not updating some custom property which effects that stack's layout in certain situations.

Are you supporting Widgets with your new Property Inspector?
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

Yes, I'd noticed that. It also really ramps up the cpu use like crazy when doing that.

I'm recreating it, so I'm sure I can work that out near the time. In fact, I did already make a stack that can do all the effects and drop shadows and stuff, without the high cpu use. I'll have to dig that out.

The reason I'm recreating the inspector is to:
  • unpick the ide and it's ties to the inspector
  • Simplifying it, and deobfusicating it
  • Making it faster and more efficient
  • Bug fixing (as there are quite a few)
  • Prevent the 'window focus juggling' once and for all on all linuxes
  • Squash the 'sliding effect' it displays occasionally.
...but it's early days. It's why I wanted to get v1.04 released before I started making sweeping changes to the core of the IDE. As you've very rightly mentioned before, it's so interwoven that this is bound to break a lot - so better to do that on a new point release I was thinking.

I'd love to support widgets - you mean for things the user might add, like the rotate text widget - something like that?

The inevitable question I would have would be how to support things like that.
I'm thinking of an addons / widget tab in my inspector that I could use to add widget support. I assume you are thinking about the built-in widgets and being able to support those initially, which I think it should do.
That tab (or at least the controls in the group on that card) are going to have to be fully dynamic I'm guessing, whereas the classic controls are easier as their properties which can be set are always the same.
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

tperry2x wrote: Tue May 07, 2024 4:33 pm I'd love to support widgets - you mean for things the user might add, like the rotate text widget - something like that?

The inevitable question I would have would be how to support things like that.
Yes, I mean like extension builder module widgets.

I'm working on newTools so I'm having too support them on the IDE object list/control level too.
They are just like the classic controls except that unlike classic controls they all have the same "widget" type property but have the additional property of 'kind' which returns the module's reverse-DNS identifier (org.openxtalk.widget.piano for ex.), so there is one extra layer identifying what sort of object/part/control the selectedControl or 'the target' is.
revIDEWidgets() returns an array containing everything about all of the loaded Widget extensions, the properties exposed, and it includes what property inspector editor to use for each property (text,integer, boolean, etc.).
To get the properties that are set on 'the selectedObject' if it's a widget type, you can use:
export widget "SVG Icon" to array tArray -- which contains it's 'kind' and its set properties, and also it's 'state' which is like the widget equivalent of getting 'the properties' for classic controls.
Here's a demo using the SVG Icon Widget:
WidgetInfos.oxtstack
(104.28 KiB) Downloaded 52 times
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

I just found a better (in that it's already part of the IDE) method in the revIDE library handlers for getting the widgets props list:
revIDEExtensionProperties takes a Widget rDNS ID 'kind' and returns an array for the kind's available properties.
Example:

Code: Select all

put the keys of (revIDEExtensionProperties("com.livecode.widget.treeView"))
Also for getting the available handlers in an extension module (Widgets or Libraries) which is what is contained in those .lci 'interface' files I found this snippet posted by Mark Wieder, UNTESTED:
Here's how I'm getting the handlers currently:

Code: Select all

/**
* find the extension interfaces folder
*/
private function modulesLocation
   return specialfolderpath("engine") & "/Toolchain/modules/lci/"
end modulesLocation

/**
* given a module name
* return a list of its public handlers
*/
function widgetAvailableHandlersOfModule pModule
   local tFile
   local tContents
   
   put modulesLocation() & "com.livecode." & pModule & ".lci" into tFile
   put url ("file:" & tFile) into tContents
   filter tContents with "*handler*"
   return tContents
end widgetAvailableHandlersOfModule
because note that revIDEspecialFolderpath("engine") returns nothing on linux.

mwieder
VIP Livecode Opensource Backer
For reading/editig a widget's 'defaultScripts' file I found this snippet from HH (R.I.P):
put "/Users/admin/Documents/My OpenXTalk/Extensions/community.livecode.hermann.graphicswidget.1.0.0" into tFolder
put revIDEExtensionFetchDefaultScript(tFolder)

So we can edit tFolder/support/defaultscript.livecodescript with a texteditor and revIDEExtensionFetchDefaultScript(tFolder) loads it.
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

That is great information, and I'll squirrel that away for future use. It will definitely be handy and I'll likely make some example stacks based on it - I have a few ideas of stuff I can add in the stack examples using some of this.

However, here's where I've probably made life harder for myself.
I'm scripting my new properties inspector to not only work with OXT Lite / OXT, but I also want it to work with my IDE (tIDE) where there is no revIDE stack, so I can't use revIDEExtensionProperties.

Not being deliberately difficult, but my version has to have no dependencies on the revIDE stack (because there's isn't a rev*[anything] stack, or an [anything].livecode stack either) :lol:

So a lot of it I'm having to write my own, but it's educational at the very least, and it does mean that I'm also able to unpick the IDE at the same time. Plus, I also find running through the revIDE stack quite a slow method because it has to traverse that function, pass the variables into the handler for each prop, look up the reverse identifier, read the file to see if it has that property, evaluate to see if the property can be set, read the status of the property, return it, send it back through the handler, then relay it to the inspector... That's a very round-the-houses method of checking if a property is set.

I'm also not entirely convinced if this jumping between various stacks, frontscripts and backscripts, is causing some of the window-palette-juggling I see on Linux.

Essentially I'm using a custom function to check the properties applied to the selected object, then return them directly to my inspector. This way I'm using about 3 steps instead of about 9.
It doesn't sound like a huge difference, but it results in a lightning-fast inspector which doesn't inter-link into any other stacks. It also doesn't depend on any reverse identifiers as it cycles through the selected object's properties. Example of button inspect function:

Code: Select all

function checkProp tBtn,tStack,tProp,tPropObj
   if there is a btn id tBtn of stack tStack then
      if tProp is "" then exit checkProp
      put the tProp of btn id tBtn of stack tStack into tIsTF
      if there is a btn tPropObj of cd 1 of this stack then enable btn tPropObj of cd 1 of this stack
      return tIsTF
   end if
end checkProp
*card 1 of this stack is tab 1 of the inspector
The tabs won't change, so this should be okay. This is probably for my own amusement, but I'm coding this to also work on my zig-compiled engine where there are no such thing as reverse-identifiers. (I'm not using that property identifier method at all. It's all pulled from the engine directly, which is faster, as it's all embedded in there already - I just reference it through xTalk script directly.)
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

tperry2x wrote: Tue May 07, 2024 9:32 pm That is great information, and I'll squirrel that away for future use. It will definitely be handy and I'll likely make some example stacks based on it - I have a few ideas of stuff I can add in the stack examples using some of this.

However, here's where I've probably made life harder for myself.
I'm scripting my new properties inspector to not only work with OXT Lite / OXT, but I also want it to work with my IDE (tIDE) where there is no revIDE stack, so I can't use revIDEExtensionProperties.

Not being deliberately difficult, but my version has to have no dependencies on the revIDE stack (because there's isn't a rev*[anything] stack, or an [anything].livecode stack either) :lol:

So a lot of it I'm having to write my own, but it's educational at the very least, and it does mean that I'm also able to unpick the IDE at the same time. Plus, I also find running through the revIDE stack quite a slow method because it has to traverse that function, pass the variables into the handler for each prop, look up the reverse identifier, read the file to see if it has that property, evaluate to see if the property can be set, read the status of the property, return it, send it back through the handler, then relay it to the inspector... That's a very round-the-houses method of checking if a property is set.

I'm also not entirely convinced if this jumping between various stacks, frontscripts and backscripts, is causing some of the window-palette-juggling I see on Linux.

Essentially I'm using a custom function to check the properties applied to the selected object, then return them directly to my inspector. This way I'm using about 3 steps instead of about 9.
It doesn't sound like a huge difference, but it results in a lightning-fast inspector which doesn't inter-link into any other stacks. It also doesn't depend on any reverse identifiers as it cycles through the selected object's properties. Example of button inspect function:

*card 1 of this stack is tab 1 of the inspector
The tabs won't change, so this should be okay. This is probably for my own amusement, but I'm coding this to also work on my zig-compiled engine where there are no such thing as reverse-identifiers. (I'm not using that property identifier method at all. It's all pulled from the engine directly, which is faster, as it's all embedded in there already - I just reference it through xTalk script directly.)
I'm all for making things as snappy as possible, and we certainly don't need to stick with the systems as they were handed to us...
You could copy any relevant handlers from the revIDE stack into your PI stack and then modify to your liking. Or you could write your own handlesr that do the same sorts of things (the Widget handlers just read those small .lci file that every extension generates and adds to the IDE when it's loaded/installed).

But since the revIDE library (along with all of the other IDE libraries) is loaded into memory at IDE startup I can't see that significantly taking any more time than having it in the same stack or a sub-stack of the same stack. It seems fast enough for me to retrieve the list of applicable properties for a selected Widget. The 'classic controls' properties are all stored in tab-delimited plain text files which are files that the IDE has to read on startup (which can easily be modified, so its not necessarily a static set of props). The Tools palette reads Widget array in a very similar manner to the way 'Classic controls' are read in from an Array (in fact revTools combines them into one list for its repeat loop).

I understand your goals with new Inspector, but I also think that it will cause some headaches, particularly if the Prop Inspector went back to being a completely static UI stack. Personally I want to keep supporting widgets, which pretty much means the inspector must remain dynamic. I suppose there could be a separate dynamic 'Widget' iInspector, but that seems a bit redundant. Bottom line is that not having a way to edit Widget properties certainly would a deal breaker for me.

I think that some of lag in the IDE might happen because there's too many messages being sent /received.
But I think you will likely still want your Inspector to subscribe to 'IDE messages' or something similar, so that it knows about things like the Screens/Monitors 'desktop' dimensions changed, or a new stack being created/loaded, which could trigger a selectedObject changed message, which could then invalidate some information displayed in your palette, etc., etc.

I spent quite a bit of time on that QuarkXpress-like text/object palette, which was mostly a subset of the Prop Inspector stack (I guess that's my way of exploring the underlying stuff too), but split out into its own palette. Similarly I made a separate object 'Alignment' stack (because I was annoyed by having to keep clicking to get to that tab in Inspector over and over again). Even just dealing with 'classic' controls without any IDE library, it will still have to do a lot of figuring out what sort of object the user has selected, it could be a button, it could be an image, it could be a selectedText chunk, etc. I'll have to upload the latest version of that stack later so that you can take a look at it, it might help.
I don't think I used any revIDELibrary (only subscribed to a couple of IDE messages), IIRC I had it iterated over 'the controls' in 'the selectedObjects', and get 'the properties' of a control. However 'the properties' and 'the customProperties' do not work with Widgets.

You might also care to read this doc, from when the Prop Inspector was rewritten to support widgets, it has some info about classic controls properties too and how the Prop-Inspector's templates are setup to work.
https://github.com/livecode/livecode-id ... spector.md

Or you can go your own way.
Personally, I think they've crammed too much stuff into these palettes.
Like the object alignment section that I made that into a separate palette.
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am I'm all for making things as snappy as possible, and we certainly don't need to stick with the systems as they were handed to us...
This was my thoughts on it too.
Although I still have to get my inspector to recognise a few things (as I say, it's early days yet), but you can see the speed difference with mine on the left and the LCC one on the right.
inspector-speed-comparison.gif
inspector-speed-comparison.gif (394.87 KiB) Viewed 857 times
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am It seems fast enough for me to retrieve the list of applicable properties for a selected Widget. The 'classic controls' properties are all stored in tab-delimited plain text files which are files that the IDE has to read on startup (which can easily be modified, so its not necessarily a static set of props).
Very true, but nobody would be modifying the IDE classic controls during normal use. And arguably, if they were, they'd be savvy enough to update a few property reading calls too. (In fact, modifying the classic controls in any way would break stack compatibility when those modified controls were saved. The standalones / runtimes would also need updating as they wouldn't understand how to read any modified properties too), so I don't think modifying the classic controls would be the approach I'd recommend anyone should do, not unless they are able to also recompile the runtimes to match. (including any mobile ones too).
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am The Tools palette reads Widget array in a very similar manner to the way 'Classic controls' are read in from an Array (in fact revTools combines them into one list for its repeat loop).
I think combined with all these back-and-forwards, jumping between various functions, reading things in arrays, splitting the arrays into items and variables are where the delays are happening. It seems like an awful lot of extra work the IDE is having to do.
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am I understand your goals with new Inspector, but I also think that it will cause some headaches, particularly if the Prop Inspector went back to being a completely static UI stack. Personally I want to keep supporting widgets, which pretty much means the inspector must remain dynamic.
Me too. I certainly don't want to drop any functionality, quite the opposite eventually, so I'm thinking a tab which is dynamic for widgets is probably the best approach. That can be loaded from the widget's individual custom properties it might have set.
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am Bottom line is that not having a way to edit Widget properties certainly would a deal breaker for me.
As above, I think that if you could knock up a demo of reading widget properties as a stack, then it would be something I can get my head around.
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am I think that some of lag in the IDE might happen because there's too many messages being sent /received.
But I think you will likely still want your Inspector to subscribe to 'IDE messages' or something similar, so that it knows about things like the Screens/Monitors 'desktop' dimensions changed, or a new stack being created/loaded, which could trigger a selectedObject changed message, which could then invalidate some information displayed in your palette, etc., etc.
Yes - and that's something else missing from my engine. There's no concept of subscribing to messages as of yet. I'd also like to have a broadcast function that can send the message to all objects if they can receive them, but that's on the wish list on the top shelf of ideas at the moment.
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am ...I was annoyed by having to keep clicking to get to that tab in Inspector over and over again).
That is the intrinsic design issue with having these on tabs. You've hit the nail on the head. Although you want to save screen space for smaller screens, at the same time you also want as many controls shown as possible so you don't have to play the annoying game of clicking through tabs constantly.
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am Even just dealing with 'classic' controls without any IDE library, it will still have to do a lot of figuring out what sort of object the user has selected, it could be a button, it could be an image, it could be a selectedText chunk, etc. I'll have to upload the latest version of that stack later so that you can take a look at it, it might help.
That would be great. All examples of how this works in practice would be appreciated, something I can take apart and dissect for my own purposes. It would be useful to anyone following along too.
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am I don't think I used any revIDELibrary (only subscribed to a couple of IDE messages), IIRC I had it iterated over 'the controls' in 'the selectedObjects', and get 'the properties' of a control. However 'the properties' and 'the customProperties' do not work with Widgets.
That's a pain, and is exactly where I reached a bit of a road-block when it came to dealing with the properties of widgets.
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am You might also care to read this doc, from when the Prop Inspector was rewritten to support widgets, it has some info about classic controls properties too and how the Prop-Inspector's templates are setup to work.
https://github.com/livecode/livecode-id ... spector.md
That's certainly one to sit and work through - but not exactly light reading ;)
OpenXTalkPaul wrote: Wed May 08, 2024 2:15 am Or you can go your own way. Personally, I think they've crammed too much stuff into these palettes. Like the object alignment section that I made that into a separate palette.
This is the thing - there's a lot of info to try and fit in. Especially on smaller displays as I mention above. But I think having loads of palettes to spawn can be equally as confusing, which is where tabs work well. Is it more annoying to have to click through multiple tabs than to remember which palette you need to open to find a control? (and what about if those extra palettes also have tabs on too (like the message box for example), you'd end up with about 4 or 5 clicks to get to the checkbox, rather than one)... however, open to ideas as I honestly am not sure of which approach is best at the moment.
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

tperry2x wrote: Wed May 08, 2024 8:29 am the speed difference with mine on the left and the LCC one on the right.
OK, first off the bat, the one on the right is doing some additional actions there, isn't it? It's resizing the stack's window, and it also looks like it's hiding the stack and then showing it again after the resize. Which is a more expensive operation of screen-area updating, involving both the OS's window manager and the engine to re-render the contents (visible card area) of the stack's window. Considering that, then your stack visually updating faster doesn't surprise me. Less screen updating is good... (although, I was just now about to add a similar method to merge my SVGIcon Glyphs browser stack, and my Unicode Font Glyphs/Emoji browser stack into tabs of the same stack.)
Would need to do actual speed test of the underlying scripts in milliseconds over a series of repeating the same action to really compare the speeds of different methods, particularly if that's going to be some justification for dropping support for something.

Personally, if I was going to drop the Extension Builder stuff I'd probably just go back to work off of v7 base because at least there was Unicode support, and there a Raspberian build of the Engine for that version (I love the whole concept of RPi / cheap SoC boards), plus Mac 32bit support (and might be possible to shoe-horn a v6 PowerPC engine into back into it's standalone builder). That's been a discussion for a 'OXT Retro' build. The problem with v7 Engine is that people complained v7 Engine was slower than v6 (and it was slower at processing blobs of text in particular, by a lot).

But for sure the less screen updating is good for a responsive feel to the UI. When designing user interface Custom Controls or Widgets you must consider such things as when exactly to redraw things (and with Extension Widgets they don't draw anything unless you code it to do so).
User avatar
OpenXTalkPaul
Posts: 1871
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

Open to ideas as well.
How about reveal 'flippers' triangles to expose more of palette as desired? I was planning on using one or two of those to allow show/hide of various groups of available objects in OXT New Tools palette with a single click. There should be a pre-scripted flipper control included in the revObjectLibrary (which I'd also like to also turn into a more readily accessible palette).

I also like the idea of having palettes that can (optionally) adhere themselves to a side of the screen. It's very common to have palettes in these positions in single-window / fullscreen UIs, and of course it makes sense to keep tool palettes out of the work area as much as possible.

Screen real-estate becomes increasingly import the less of it you have available, but I can remember working on 17 x 11 inch paper sizes documents on a screen that was a 512 × 342 pixels (not to mention 1-bit / black & white only), so I know it can be done, but obviously it is the design problem.

HOWEVER, now in the days of Hi-DPI screens, we can 'set the scaleFactor of myStack to 0.80' to use 20% less screen space for a palette (and hopefully everything renders nicely at that new scale).

The Text-Xpress palette idea I was designing was (mostly) for formatting the selectedText chunk. The property inspector doesn't do that on a text-chunk level. Currently the inspector can only set the textFont, textColor, etc. text properties on the control level (most likely a field object or button). This palette can do either or both, so the idea wasn't quite the same as splitting out something that existed into its own palette.
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

MacOS bug with grouping objects, discovered 26-6-2024
User avatar
richmond62
Posts: 3264
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Known Bugs

Post by richmond62 »

I shall continue my 'Turtle Challenge' thread once:

The grouping bug has been sorted out.

Using a GRAB command with certain types of GROUP does not crash the IDE.
-
Screenshot 2024-06-26 at 20.41.06.png
Screenshot 2024-06-26 at 20.41.06.png (297.8 KiB) Viewed 354 times
-
Ridiculously, with this stack, to create the group 'edna' at the bottom-right, I had to open the stack in LC 963.

That group does NOT crash the IDE.
Attachments
Dragger.oxtstack.zip
(20.93 KiB) Downloaded 11 times
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

richmond62 wrote: Wed Jun 26, 2024 5:42 pm I shall continue my 'Turtle Challenge' thread once:
The grouping bug has been sorted out.
I thought you'd grouped it successfully because:
richmond62 wrote: Wed Jun 26, 2024 1:28 pm On finally succeeding in GROUPING my controls and giving the group this "complicated" script...
richmond62 wrote: Wed Jun 26, 2024 5:42 pm Using a GRAB command with certain types of GROUP does not crash the IDE.
That group does NOT crash the IDE.
Do you know what specific groups do crash the IDE?
In my testing here on MacOS 12.7.4, Linux and Windows, I can't get it to crash dragging all manner of groups around like in the scripts you set. (otherwise I'd experiment myself with this) Did you see my test videos posts by the way?

Can you also test on your MacOS 12.7.5 machine and see if LCC 9.6.3 crashes on there with the same stack too. (a 0.0.1) version update wouldn't make too much of a change you'd think, but you never know.
User avatar
richmond62
Posts: 3264
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Known Bugs

Post by richmond62 »

Can you also test on your MacOS 12.7.5 machine and see if LCC 9.6.3 crashes on there with the same stack too. (a 0.0.1) version update wouldn't make too much of a change you'd think, but you never know.
Not today or tomorrow as at work: I will do some tests on the MacOS 15 'Sasquatch' beta with BOTH LC 963 and OXT Lite 1.05.
-
SShot 2024-06-27 at 11.09.44.png
SShot 2024-06-27 at 11.09.44.png (30.08 KiB) Viewed 332 times
https://richmondmathewson.owlstown.net/
User avatar
richmond62
Posts: 3264
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Known Bugs

Post by richmond62 »

Initially I opened my Turtle Challenge stack in OXT Lite 1.05

The group consisting of an image, a field, and a drop-down menu:
-
group1.png
group1.png (15.41 KiB) Viewed 332 times
-
The drop-down menu works.

On performing a mouseDown grab the IDE crashed.

On opening the same stack in LC 963 nothing crashes.
https://richmondmathewson.owlstown.net/
User avatar
richmond62
Posts: 3264
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Known Bugs

Post by richmond62 »

I decided to set up a stack with a number of different groups consisting of different objects: BUT, as I was unable to perform any grouping operations I had to perform the initial work in LC 963.
-
GC1.png
GC1.png (36.67 KiB) Viewed 332 times
-
The groups are called, from left to right, G1, G2, and G3.

Each group contains the following script:

Code: Select all

on mouseDown
    grab me
end mouseDown
ALL of these groups can be dragged without any problems when open in LC 963.

ALL of these groups can be dragged without any problems when open in OXT Lite 1.06.
https://richmondmathewson.owlstown.net/
User avatar
richmond62
Posts: 3264
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Known Bugs

Post by richmond62 »

I copied my 'tMOVE' group from my Turtle Challenge stack onto a clean, new stack:
-
Remooove.png
Remooove.png (53.45 KiB) Viewed 329 times
-
That did NOT crash the IDE.
https://richmondmathewson.owlstown.net/
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

richmond62 wrote: Thu Jun 27, 2024 8:19 am I decided to set up a stack with a number of different groups consisting of different objects: BUT, as I was unable to perform any grouping operations I had to perform the initial work in LC 963.
Could you not group them by dragging a box around them?
(not that that's my fix, you understand) - just trying to ascertain how broken it is on MacOS.
Is the group icon also disabled in the toolbar on MacOS 12.7.5 when grouping in a menuitem is unavailable?
richmond62 wrote: Thu Jun 27, 2024 8:19 am ALL of these groups can be dragged without any problems when open in LC 963.
ALL of these groups can be dragged without any problems when open in OXT Lite 1.06.
emphasis mine, I'm sure you mean 1.05
That's handy to know - it would maybe mean there's something crept in with a revMenubar edit - something that MacOS does not like.

As I say, it's a hard bug to track down - simply because I can't replicate any crashing here - but that's probably because I don't have MacOS 12.7.5.

I can however try and solve the grouping not being available, although the behaviour of this fluctuates between different versions of MacOS (implying to me - yes, it might be something we've inadvertently triggered with a revMenubar edit), but the severity of the bug varies between different versions of the OS.

As I say, the grouping and the grabbing - none of that shows as being an issue in Linux or Windows, it just works as expected. I think there must be something related to revMenubar (or the way MacOS is interpreting something) - which does not surprise me as we had flat-out entire IDE crashes involving the revMenubar stack already - which is why the revMenubar that's in OXT Lite now is the one I used from Paul's OXT 'heavy' RC4 version (Because my version previous to this started doing this at one point). It may be the most delicate part of the whole IDE as far as MacOS is concerned :?
User avatar
tperry2x
Posts: 1981
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

I should get a chance to look at this tomorrow on MacOS 12, all being well.
User avatar
richmond62
Posts: 3264
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Known Bugs

Post by richmond62 »

Could you not group them by dragging a box around them?
That is what I have been doing all along.

This triggers the GROUP menu item to show up: but clicking on it does NOT group the selected objects.
https://richmondmathewson.owlstown.net/
User avatar
richmond62
Posts: 3264
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Known Bugs

Post by richmond62 »

Paint me purple!

Today (OXT Lite 1.05, MacOS 15 beta 2) my offending group (image, drop-down, field) on being moved around via 'grab me' did NOT crash the IDE.
https://richmondmathewson.owlstown.net/
Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests