Learning from right here #1

[tperry2x]

.. not from across the way.

I'm finding a lot more functions that aren't documented anywhere, but yet are really handy.

I didn't know you could do this until a moment ago:

Code: Select all

put revRuggedId(cd btn "button")

returns:
card id 1002 of stack "Untitled 1"
(does it all in 'one hit' - which might(will) make creating a revised 'project browser' a lot easier (another one of my future to-do jobs)

I then found you can do:

Code: Select all

put revLoadedStacks("all")

which is really going to help with the above.

Along with:

Code: Select all

put macVersionLessThan("9.2.2", "11.3.1")

9.2.2 being the maximum version of "classic macOS" I want to check for, and 11.3.1 in my example being whatever systemversion MacOS is currently returning. Someone has obviously thought about how to reliably deal with the macOS systemversion differencing, but not implemented /documented it.

I actually found these while looking for something else, but thought it might be interesting.
Sorry if this is old news to anyone, but I had no idea these things existed.

[OpenXTalkPaul]

For sure, and there's also a few useful handlers that come built into the IDE, particularly useful if you're working on the IDE itself like we are, or developing add-ons for it. if you look at the OXT modified version dictionary, some of these IDE handlers were added. Search for 'ide' here: https://openxtalk-org.github.io/OpenXTa ... ictionary/

But there is more that are completely undocumented, such as 'revRuggedId' which is not in the dictionary.
Another is revAvailableHandlers which is an object property (which is in the OXT Dictionary, but not in LC's)

the [effective] revAvailableHandlers of {scriptObject}

Code: Select all

put the effective revAvailableHandlers of stack "Home" -- returns IDE handlers available to be called from the home stack

When I first started to really dig into the stacks that make up the IDE I started to make a list of interesting things I'd find along the way so I that wouldn't forget about them, here:
https://github.com/OpenXTalk-org/OpenXt ... things.txt

Surprisingly 'revLoadedStacks' is part of the OXT and LC dictionaries. Which I guess that probably means it's a function that's built into the engine. Also similarly obscure to most users, but that are actually documented in both dictionaries, I would think are ones like: revAppVersion() which returns the engine version.

There is so much syntax available ( I think there's something like 1600+ engine-reserved words or keywords) that I often find things I've never noticed or considered before, like today's find:
set the pointerFocus to {true | false}
Which is an engine property that is related to window focusing (I haven't had a chance to try it):

Use the pointerFocus property to determine how the active window is determined.

On Unix systems, if the pointerFocus property is false, clicking inside a window makes it the active window. This is the recommended setup.

If the pointerFocus property is true, moving the mouse pointer into a window makes it the active window. Set the pointerFocus to true to work around problems in some Unix window managers (specifically, "olwm" and "fvwm" ) that prevent active-focus applications such as OpenXTalk from operating correctly.

If the application is started from a Unix command line, this property can be set to true on startup by using the -pointerfocus option.

Cross-platform note: On Mac OS, OS X, and Windows systems, setting the pointerFocus property to false changes window activation in minor ways which are not particularly useful, and has no other effect.

I added the emphasis, it says 'Unix' but the docs seem to consider Linuxes to just be a 'religion' of Unix (which I found in the IDE somewhere and contains 'penguin' to denote Linux).

[tperry2x]

That's a good find. I'll have to try pointerfocus with icewm (as that's the worst culprit for the 'window juggling' / window focus issue).
Just tried it here on MX, both using the command-line switch and setting it via the message box. Doesn't error, but doesn't seem to visually change anything either. Will have to experiment with a few distros. I'm sure it will be useful on others though. Thanks Paul.

Don't you think it's funny (maddening?) how we are still finding things buried and undocumented - bearing in mind how old some of this underlying IDE code is?

[richmond62]

When my in-laws died my wife and I inherited a house in a village in the mountains (where we now stay). It was built by my father-in-law and his friends. My father-in-law was a very skilled dentist.

Some 14 years after my father-in-law's death we are still 'paying' for the house.

Just redid the electrics which were mind-blowingly dangerous. Discovered that the 'mortar' between a lot of the bricks was about 20% mortar and 80% sand.

For 'some odd reason' that situation makes me think of elements of the current OXT situation . . .

[tperry2x]

In that case, hopefully we can start putting some cement in the places where it's needed, and we are gradually replacing as much of the dodgy internal wiring as we can get to.

That is a good analogy. Think of the engine like the foundations. (okay, on second thoughts probably best not to).

[OpenXTalkPaul]

In that case, hopefully we can start putting some cement in the places where it's needed, and we are gradually replacing as much of the dodgy internal wiring as we can get to.

That is a good analogy. Think of the engine like the foundations. (okay, on second thoughts probably best not to).

I think of our inherited engine as A foundation for an xTalk/xCard but (like I'm frickin' Issac Asimov) I still imagine a second foundation, and after that maybe a third distinct path ( sorry just reading about season 3 )
I've always wanted OpenXTalk to be about xTalk/xCard, open-source xTalk in particular, but not simply a continuation of LC Community Edition. I'm xTalk 'Engine' agnostic.