I've hit the same problem, but in reverse, in my engine.
Opening Livecode stacks that might use something that I've not added to my engine, previously just caused a spontaneous quit.
At least I've now put in an error catcher, so it dumps the error to "errors.log" now.
So, that should also mean if I open a stack that requires the animation Engine, (and obviously my build doesn't have it)....
Code: Select all
[malloc addr._parser.cpp:242:20: parse error: 'tIDE/engine-main.hpp' file not found. Operand: "animationEngine"]
(Still a bit cryptic, so I could make this a lot more 'human readable'). Still, it shows what happens if I currently open a stack that relies on the Animation Engine.
(So I've already got the situation where I'm having to build support back in for the livecode stack format). - As rightly said, it's not really documented anywhere - so I'll try and piece some of that together into a readable version as it's all internal to the engine currently).
Worth clarifying: I wasn't building new commands into my version of the engine, directly hard-coded into the C++ source, just to be clear. I'm keen to externalise everything, so anyone will be able to get to it and modify things without having to fire up a compiler.
I'm adding any new commands as extensions.
(I'm testing these out in OXT Lite at the moment, just because my engine currently doesn't understand extensions - yet another thing I need to recreate and ensure are compatible)...
- Screenshot_2024-03-13_19-43-50.png (217.41 KiB) Viewed 328 times
So, yes - this is just me testing a revised SystemVersion command. You can see I call it OSVersion in the screenshot above.
I checked with Paul the other day, just in case I was missing something obvious, but it seems I have to run it as a bit of an ugly function?
I can't just use "get the OSVersion" as those neatly formatted commands are internal commands, and it seems only possible to keep them nice and succinct like that if they are part of the engine (hopefully someone will correct me on that). I'd be happy if that's not the case.
You'll also notice my copyright text in there - which I can add as it's all my own work and does not rely on the LCC source, and will be developed in my own engine (so they have no ownership of my code) - it'll just 'coincidentally' happen to work with OXT/OXT Lite too
/*
* This code is intended to provide extra functions to OpenXTalk / OpenXTalk Lite.
* This should be considered free to use by anyone, however there is one stipulation / condition:
* This code should in no part be used in any LiveCode product, or fork bearing the LiveCode product name. This stipulation cannot be modified or altered, and this notice MUST go with this plugin unaltered.
*/
Why? Well, you'd be amazed (or maybe not) about the amount of work required to re-create everything we take for granted in the LCC engine at present. Even basic things like adding text formatting and colours into my engine took me a while to figure out, and ensure that it was compatible - I'm striving for maximum compatibility where possible of course between LCC stacks, so there's a lot of 'cruft' if you like that it has to support. I'll ultimately add this as a 'legacy-support' extension.
The benefit of that being of course, if someone wants to 'slim-down' a copy of my engine at any point (when it's ready in say, 2030!) they don't have to go through source code and strip out the legacy functions. They just remove the 'legacy-support' extension from a folder.
Okay, not 'cruft' - that's a bit of a bad description, as this is the xTalk language that we know (and ultimately what I'm trying to preserve I guess)... however, just how far do I go with that? Do I try and support things like revCopyFile (things beginning with rev), because this is frankly really old syntax and harks back to the days of Runtime Revolution.
I'm thinking I just set up an alias function, so when you call revCopyfile() it just passes to xTCopyfile() or something simple like that.
So, with all this work in mind (which in my opinion needs to be done if we are to ever break the shackles of LC), I'm not keen on them having any claim to any part of this as their own. Yes, I'm [slowly] reinventing the wheel - but the wheel needs it in my opinion.
In the following 7z file, you'll also find an "api.lcdoc" which is currently blank. I know this where my blurb goes for the syntax of any new commands, so that they get added to the dictionary I guess. But, again - I can't see this documented anywhere - so I hope someone can tell me what format this takes? Perhaps someone in the know can write a sample "api.lcdoc" file that describes my simplistic OSVersion command above?
