OpenXTalk Forums

richmond62 wrote: ↑Sat Jun 22, 2024 10:31 am The problem lies in, for the sake of argument, when one presses the 'Q' key how one detects whether at that moment the ENTER or RETURN key is being pressed.

Again just check if either number is 'among the items of the keySDown' -- Note the 'S' in the middle!
This is the only way to check keyboard "chords".

Also note that because of the matrix of electrical contacts most (every?) modern keyboard uses, certain "chords" may not be physically possible for the keyboard HARDWARE to produce. Most Keyboards DO NOT have separate mechanical switches for every single key, it's a matrix of electrical contacts on a plastic sheet under the plastics keys that push down onto it to complete circuit (at least that's how I THINK it works, but I'm not an electrical engineer). If you've ever ripped apart a computer keyboard in the past 25 years then then you've probably seen what I'm talking about.

OK: I apologise: you are quite correct:
-

Here, I added 1 line to the handlers and tested this and it works, hold down "Q" and "Return" at the same time and you'll see in the message box "113,65293"

richmond62 wrote: ↑Sat Jun 22, 2024 4:29 pm OK: I apologise: you are quite correct:

No problem, glad you got something workable for what you're looking for.

My problem with the keySdown is it SHOULD be named the rawKeySdown (because it contains key code-number) and there should be different the keySdown that returns actual characters or a 'keyName' (for non-printable chars like 'F1'). That would make it consistent with the way engine keyboard messages are named and their functionality.

That would make it consistent

An awful lot of things in xTalk are inconsistent.

How about setting up an alias-function / pointer to a renamed function instead.

we could potentially set up: and MultipleRawKeyDown can return 97,112
and MultipleKeyDown can return a,z

for example?

That sounds super.

How about also (pace Paul) introduce rawKeysDown and modify keysDown?
-

That would have been the ideal method - (and the most logical) - please correct me Paul if not, but I think these are baked into the engine.

baked into the engine

Is there a list of what is 'locked up' inside the engine, and what is external?

Pretty much everything, except for the functions myself and Paul have added.
From my point of view,... ...is a good example. Just me testing stuff, this resides in the "community.openxtalk.plugin.oxtlite" plugin in OXT Lite - which you can edit the script of with the Application Browser. This is the preferred method - externalising all this sort of stuff.

Of course, in an ideal world (pause for superior, cynical laughter) EVERYTHING that could be externalised and modularised would be.

Objously time to get our mitts on someone who can seriously rejig the engine, and . . .

Macintosh ARM processors.

RISC machines.

'Modern' Power PCs.

tperry2x wrote: ↑Sat Jun 22, 2024 5:05 pm That would have been the ideal method - (and the most logical) - please correct me Paul if not, but I think these are baked into the engine.
baked-in.jpg

Correct, the xT interpreter would need to be modified to do that properly.

tperry2x wrote: ↑Sat Jun 22, 2024 5:20 pm Pretty much everything, except for the functions myself and Paul have added.
From my point of view,...

Code: Select all

put OSVersion()

...is a good example. Just me testing stuff, this resides in the "community.openxtalk.plugin.oxtlite" plugin in OXT Lite - which you can edit the script of with the Application Browser. This is the preferred method - externalising all this sort of stuff.

Ah cool, then other people can add to that too. I prefer the idea of putting our community additions into our own OXT library(ies) as well. I've been using the format 'org.openxtalk.whatever.whatever.whatever' as an extension identifier. community.HH I've used for HH because he's unfortunately no longer alive to approve of being to be part of OXT (although almost all of his work was put out as MIT license so we're good to include these works legally).

Am I right in assuming code in those plugins can over-ride anything in the engine?

Presumably to effect an over-ride that has to be stated somehow explicitly in a plugin.

Thanks for confirming Paul. I thought as much, this is all part of the way the lextable is assembled in the engine as far as I can tell. (I'm still learning C but it looks like that's indeed what it's doing if I'm interpreting it correctly).

I think we spoke about it before, but functions that we've created ourselves - they have to be accessed with: showing the brackets. We can't just type: because the message box will return the string 'osversion'.

The only way I found to do that was to load it into a global variable first, so you can also use tsystemversion without the brackets.
Is there a way to call a function without the brackets, Paul?

I mean, sometimes you want the brackets for when you are passing variables to the handler - granted.
I just tried a test function:
Then in the message box I can call it with: And it'll return the output: But what about functions where no variables are needed, and you simply want to call the custom function in the plugin with no arguments?
I know, it sounds a bit basic, but it's eluded me so far.

In short, I'm wondering how you get an externalised function to be treated like one embedded inside the engine.

tperry2x wrote: ↑Sat Jun 22, 2024 8:16 pm In short, I'm wondering how you get an externalised function to be treated like one embedded inside the engine.

If it doesn't need any arguments then maybe you could just have it be a 'command' handler instead of function handler, and can still set the result and the 'it' values.

But there's no way that I've found to create a new 'global/engine level property' from a script, it seems that's exclusively the domain of the engine. Like you I've used globals to get something similar to global property (like 'selectedSoundFont' used by my general music library), the difference is in readability of scripts because 'the' is the token that indicates a property. With a global I can't 'put THE selectedSoundFont', but I can 'put selectedSoundFont'.
Now that I think of it there might be a way I suppose to make a new 'global property' like with those .tsv tab separated value files, I think I did do some experimenting with a 'properties.txt' file.

And to answer Richmond's question more specifically... no you can't override internal engine functions/commands, or keywords, or even some words that are simply reserved by the engine (deprecated nor 'for future use'), although you can set some of those that are 'stubs' or 'has no effect / for compatibility'(with other xTalks) keywords, sometimes with arbitrary values. Extension Builder language doesn't allow overriding any of the Engine's keywords/commandNames/functionNames either as far as I can tell.

This will get you a list of most of them... in the message box paste: One of the things I really like about the way 'HyperCard Simulator' works is that the top-level (second level below interpreter in its message path) 'SimScript' functions that you add can be called as if they're 'global properties' (ie with 'the' in front of the function name and no ( parentheses ) needed. So I have a function that uses a mix of xT and JS, 'function darkMode' which returns a boolean and I can use it like 'if the darkMode then ...'

HyperCard (and OpenXION) allowed you to override almost every keyword in the interpreter, which came in handy but could also get confusing (I used to override the 'play' command in HC). In OpenXION I was easily able to overide ask/answer with AppleScripts/Python script to implement graphical UI dialogs instead of its internal text/console based dialogs.

I read a very old discussion about allowing this sort of thing from MetaCard Mail List archive, at least with some keywords, but that obviously never happened.

OpenXTalkPaul wrote: ↑Sat Jul 27, 2024 4:58 pm HyperCard (and OpenXION) allowed you to override everything in the interpreter, which came in handy but could also get confusing (I used to override the 'play' command in HC). In OpenXION I was easily able to overide ask/answer with AppleScripts/Python script to implement graphical UI dialogs instead of its internal text/console based dialogs.

I had a long conversation with Dr Raney about this back in the day.

TL;DR: he didn't add overriding for performance and compatibility reasons. He felt that custom behavior merited a custom name, effectively encouraging overloading rather than overriding.

Fuller description of that conversation here:
https://forums.livecode.com/viewtopic.p ... 186#p93186

Unfortunately what you mentioned in the seventh paragraph of your posting did not get anywhere:

Because the proposed "Open Language" syntax will be, AFAIK, based on a system of well-defined prototypes, it may be able to take care of many of the current cases where parentheses are currently needed. But I'll have to see it before I get too excited about it beyond that and making externals and custom handlers more readable.

FourthWorld wrote: ↑Sat Jul 27, 2024 5:59 pm TL;DR: he didn't add overriding for performance and compatibility reasons. He felt that custom behavior merited a custom name, effectively encouraging overloading rather than overriding.

Fuller description of that conversation here:
https://forums.livecode.com/viewtopic.p ... 186#p93186

Thanks Richard. Now I recall that was the end of that Metacard list thread (I was reading a lot of historical sites and list posts for a while, but that was some time ago).

Personally, I think it would be good to allow overriding a subset of syntax that could/should be externalized, things that are peripheral to the core language, such as the play command.

I argued with him, and he was ultimately willing to offer a compromise, in the form of a challenge: if I or anyone else could find a reason why it would be necessary to have custom behavior for a function that must have the name of a built-in function, he'd add support for that.

Again, the play command, the APIs that this command relied on have changed so much it's broken and virtually useless now on some platforms, and it never followed (what I call) 'standard' xTalk anyway. Play 'playSentence' form was never supported. I have to use 'PlayPMD' or (an alias name) PlaySentence to get that behavior but that doesn't read very English-like, which I always thought was the goal of xTalk.