Interesting or odd xTalk syntax

All flavors welcome.
Forum rules
Be kind.
Post Reply
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Interesting or odd xTalk syntax

Post by OpenXTalkPaul »

Every so often I'll come across some syntax that strikes me as odd or uniquely 'xTalk'.
Sometimes it might just be syntax I didn't even know existed, even though the dictionary says it's been in it since v1.0, which is a tribute to just how rich the syntax is.
Here's an example that struck me as odd today:

Code: Select all

this me
This is functionally equivalent to 'self' used in some other coding languages.
Used like so:

Code: Select all

on openStack
    put the name of this me -- message box will display the name of the stack
end openStack
Not very "English like".
User avatar
astu
Posts: 31
Joined: Fri Nov 26, 2021 7:34 pm
Location: Germany
Contact:

Re: Interesting or odd xTalk syntax

Post by astu »

I would not be surprised if there is not more "forgotten" syntax. But some will be obsolete, because other terms or functions have replaced them and are therefore no longer included in current dictionaries.Old syntax is usually retained to ensure compatibility with older products.
GitHub: https://github.com/Hoerwi

Image
User avatar
richmond62
Posts: 2619
Joined: Sun Sep 12, 2021 11:03 am
Location: Bulgaria
Contact:

Re: Interesting or odd xTalk syntax

Post by richmond62 »

An ongoing criticism I have had of LiveCode has been that they have been driving hell-for-leather
towards the red lights at such speed that an awful lot of stuff is getting left behind; some of which,
with a bit of tweaking, would be very useful.
https://richmondmathewson.owlstown.net/
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Interesting or odd xTalk syntax

Post by OpenXTalkPaul »

richmond62 wrote: Thu Dec 30, 2021 1:13 pm An ongoing criticism I have had of LiveCode has been that they have been driving hell-for-leather
towards the red lights at such speed that an awful lot of stuff is getting left behind; some of which,
with a bit of tweaking, would be very useful.
I definitely want to do some tweaking, the play command in particular.
What tweaks did you have in mind?

I should add that

Code: Select all

this me
is not the same as

Code: Select all

me
If you:

Code: Select all

put the name of this me
You will get the name of the actual object that the script is running in, which could be a button script that is used as a behavior, whereas if you:

Code: Select all

put the name of me
You will get the name of the TARGET object that a behavior script is linked to, so the functionality is different.
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Interesting or odd xTalk syntax

Post by OpenXTalkPaul »

So I was working on getting the IDE's built in 'systemAppearance' message to work as it should.
It's supposed to send it's message to the mainStack, which technically it does, which would be the 'mainStack' or topStack in a stack running as a standalone app, HOWEVER this message is actually sent to the stack that is the defaultStack or ''line 1 of the mainStacks', which in the IDE is actually the 'Home' stack.

So there's currently no easy way to test your handlers that respond to this message except for building a standalone (which I might point out leaves out any non-standalone building "hobbyist" plan over there ;-) ) and then running it to see see it work, then rinse and repeat for additional changes OR you could edit the IDE's critical "Home" stack script. I intend to have the home stack pass/forward this message to the user's current mainStack or topStack (not the IDE's defaultStack)

Anyway while tinkering with this with the message watcher open, I happened to click on the IDE's icon in my dock and noticed that there was this message I'd never seen before. I looked it up in the dictionary and there was no entry for it! Initially I thought maybe this message was from my Apple PDFKit Widget that I had open, which jacks itself in to the IDE app's NSNotifications to handle PDF page change messages and such, but I double checked and there was no similar message sent from my Builder code. A mystery!

The message was iconMenuOpening. I did a google search which found something similar mentioned in the LC v.4.6 release notes: statusIconMenuOpening, but these features were noted as 'experimental'.

From Page 21 of '4.6.x Release Notes – Revision 14 – 2011-03-25 – Mark Waddingham'
Status icon support (4.5 – experimental)
Windows, Linux and Mac all have an area where so-called 'status icons' can be displayed. On Windows this is the system tray on the bottom right of
the start bar, on Linux this is typically the right of the panel at the top of the screen, and on Mac this is on the menubar.
The engine has support for adding a single status icon, and it can be configured using the statusIcon, the statusIconTooltip and the statusIconMenu:
set the statusIcon to imageId
set the statusIconMenu to iconMenuSpec set the statusIconToolTip to toolTip
Here imageId is the id of the image you wish to use as the icon.
It will be scaled down automatically to the appropriate size for the platform and then set.
The toolTip specifies what message appears when the user hovers over the status icon.
The iconMenuSpec allows you to configure a menu that will appear when the user does a 'menu' click on the icon. This string uses a subset of the standard engine menu specification:
[ <tab> * ] [ '(' ] <label> [ '|' <tag> ]
Here the number of tabs determines the depth of the menu (i.e. use this to create sub-menus).
The optional tag is used when calling the statusIconMenuPick message.

Before the engine displays the status icon menu, it will send a statusIconMenuOpening menu to the current card of the defaultStack. You can use this opportunity to change the icon menu before it is displayed, this is an analog to handling mouseDown in a menu button.

When the user selects an item from the dock menu, the engine will send an statusIconMenuPick message to the current card of the default stack:
iconMenuPick which
Here which will be a list of labels or tags (if specified) separated by '|' which determines which item was selected.
In addition, the engine will send the following message in response to clicks on the icon:
statusIconMenuClick button
statusIconMenuDoubleClick button
You can use these to perform an appropriate action.
Note: If you wish to display a menu from the status icon you must use the statusIconMenu property, attempting to
open a normal popup menu in response to one of the click messages is not guaranteed to work.
Note: This syntax is only implemented on Windows at the moment and replaces the previously unsupported use of
the icon and the iconMenu for this purpose. The properties specified above will have no effect on Mac and Linux at this time.
Important: This feature is currently experimental. This means that it may not be complete, or may fail in some circumstances that you would expect it to work. Please do not be afraid to try it out as we need feedback to develop it further.
I went on the share site and found someone had made a demo, but the file was corrupt (looking at the contents in Atom I can see there is HTML attached to the end of the stack file)...

So I made a quick test stack which did NOT receive the message, then I remembered the issue with the systemAppearance message, inserted my test handler into the 'Home' stack scripts, and Viola!!! The IDE receives the iconMenuOpening message!

Apparently they've renamed this message at some point? Probably because a 'statusMenu' on macOS is NOT the same thing as the App's dock menu. The 4.6 docs for this 'experimental' syntax seems to mixed up 'statusMenu' with a dock 'iconMenu'.

A 'statusMenu' appears in the top left of the system's menu bar. Support for making a macOS Status Menu WAS later added as a builder extension by Trevor Devore, which was then it was added to LCC), while this 'iconMenu' is the menu that pops up when you click and hold on a app's icon in the Dock.

I had considered handling this menu in macOS native tools library but never got around to it. I was particularly interested in making a dockTile image at one point to show progress bar image. I did add handlers to "badge" the dock Icon, which is a string that gets applied on top of the app icon ( like the number of new emails that shows on the mail app ).

After some quick tests I've worked out the actual messages that are now sent in response to opening the app's 'dockMenu' or whatever it's called on Windows and Linux, which the engine calls the iconMenu and how to specify the menu to be added.

Code: Select all

on iconMenuOpening pParamMaybe
   set the iconMenu to (tab & "Utilities" & cr & tab & tab & "Gather Windows")
   put "Home Stack Message Recieved:" &cr& "IconMenuOpening" & cr after msg
   pass iconMenuOpening
end iconMenuOpening
   
on iconMenuPick pWhich
   put "Home Stack Message Recieved:" &cr& "iconMenuPick" & cr after msg
   if pWhich is not empty then 
      put pWhich after msg
   end if
   pass iconMenuPick
end iconMenuPick
To see this get triggered either copy/paste this into the IDE's home stack's script, or make a test standalone with this in it's mainStack's script (adjust to output to a text field since this logs messages to the message box).

I haven't figure out the syntax for setting the dock icon to an image though, or if that even works at all. Setting the stack's icon image or toolTip dont seem to work, at least not in the IDE. If not, this dockTile control could be implemented in the macOS Native tools.

We should create the docs for this to add to the dictionary as it's not in there currently (after 11 years I would think this is no longer 'experimental', more like forgotten).

I hadn't ever heard of LiveCode back in March 2011 when 4.6 came out, and again...
THERE IS NO ENTRY FOR THIS IN THE DICTIONARY!
So this is like finding a new hidden feature for me!

:)
Screen Shot 2022-01-17 at 1.34.20 AM.png
Screen Shot 2022-01-17 at 1.34.20 AM.png (211.74 KiB) Viewed 2219 times
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Interesting or odd xTalk syntax

Post by OpenXTalkPaul »

Oh and this weekend I did tinker around a bit with that native NSVisualEffectView
DarkModeWindow.png
DarkModeWindow.png (1.37 MiB) Viewed 2200 times
Now I just got to get that applied to a stack window!
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Interesting or odd xTalk syntax

Post by OpenXTalkPaul »

OpenXTalkPaul wrote: Mon Jan 17, 2022 6:49 am So there's currently no easy way to test your handlers that respond to this message except for building a standalone (which I might point out leaves out any non-standalone building "hobbyist" plan over there ;-) ) and then running it to see see it work, then rinse and repeat for additional changes OR you could edit the IDE's critical "Home" stack script. I intend to have the home stack pass/forward this message to the user's current mainStack or topStack (not the IDE's defaultStack)
I just realized it is probably possible to trap for this message without editing the Home stack script at all, by inserting a script into front. I'll have to test that theory, but it seems like the pretty obvious solutions in hind sight. Once the GUI editing / de-branding stuff is fully complete, I'd like to look more closely at where the IDE can be extended.

Working on the oxtTools palette I can see how some of the classic 'tools' are really the same tool but with different 'template' object properties set. For instance the rectangle and oval paint tools are actually the same shape painting 'tool' but one 'tool' sets it to oval and the other to rectangle before the user clicks by setting the 'template graphic' depending on the icon that is selected in the tools palette. So we that means could add 'tools' of our own I imagine. Indeed it seems like certain 'tools' have disappeared from that palette over the years, there is no Pixel-based font tool that was present back in the 1990s for example. I'd like to see if we could improve on both the vector graphic object tools and the pixel painting tools which in my opinion are stuck in the 1990s features wise. In particular I'd like to have alpha channel control directly from within the stack that I'm working on, that is, I want to be able to paint the 'A' part of RGBA Pixels directly in my stacks and have it update the stacks windowShape property when I mouseUp so it updates the window's oppacity change immediately after editing it. Looking at these, apparently mostly unused by anyone, pixel drawing features I can see areas that could be a lot more usable. Take a close look at that 'Airbrush' tool, it's the 1980s 1-bit/stippling version of a digital airbrush tool! Can the Engine NOT load a 8bit or 24bit 'brush' pattern? And how about a maximum brush size that's appropriate for the days of 8k high-density displays? If we can get even a little bit more Photoshop/Gimp-esque in this area, that would be really nice, IMO.
User avatar
OpenXTalkPaul
Posts: 1485
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Interesting or odd xTalk syntax

Post by OpenXTalkPaul »

OpenXTalkPaul wrote: Sat Jan 22, 2022 2:12 am I just realized it is probably possible to trap for this message without editing the Home stack script at all, by inserting a script into front. I'll have to test that theory, but it seems like the pretty obvious solutions in hind sight. Once the GUI editing / de-branding stuff is fully complete, I'd like to look more closely at where the IDE can be extended.
Just to confirm this is a solution for this problem, insert the scripts into front in order for your non-standalone stacks to properly receive these messages (there's actually a few that exhibit this behavior, incl. systemAppearanceChanged, iconMenuPick, mouseDownInBackDrop, mouseUpInBackDrop, etc.)

There should probably be a note in the dictionary entries about this behavior:
By default the engine sends these messages to whatever line 1 of the list that mainStacks() returns, which is very likely to be the "Home" stack while running in the IDE (non-standalone).
Another option would be to modify their current message path by having the IDE's Home stack always forward these messages to the topStack()
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 3 guests