What I'm adding, and what I'm planning next...

[mwieder]

OK - solved it.
The first part is my error. I said I tried this with no third-party plugins, but apparently I lied. I thought I had done that earlier, but I was in a hurry and guess I messed that up. So...

The ferruslogic error shows up for only me because I currently have PowerDebug set to enable the global gRevDevelopment to true. Normally you want this false because you want to ignore errors in system stacks.

Errors in system stacks are ignored unless gRevDevelopment is true. If I modify PowerDebug to default to false for that global var then I don't see the error and my experience is the same as that of everyone else.

And that's where the rest of this comes in.
The fact that I'm catching the error in a system stack (home) shows that there actually is an error there, you're just not seeing it because it's being ignored for you. The line of code sending a command to the ferruslogic stack is failing because a) the script isn't in memory at the time and b) the defaultFolder is empty at the point it's being invoked. Therefore it's a "stack can't be found" error. This error causes an exit from the startup handler. If there were other commands after this point they'd be ignored, but fortunately there are none, so there are no other repercussions.

So while my patch does work in the sense that it causes the enclosing code to be ignored, that code isn't going to work anyway.
Another possibility occurs to me, and that's that you have the cLayoutGuides of your preferences stack set to true, in which case the offending code will be ignored on your system.

[tperry2x]

Ah, that's handy to know - thank you Mark for your detective work on this.
I'll look into it, and certainly explains why you are getting that error. Would be good to resolve it though, so I'll do that with an update.

Edit:
I've put it in a try statement, so that it can fail silently with an error.
(if it's failing... more on this further down).

fail-silently.png (16.95 KiB) Viewed 4611 times

I say 'if', because this is the bit that's frying my noggin' at the moment.
I could understand if it's failing as to why the error might be creeping in, but I'm sure the plugin can indeed be found .
If the option to use it is turned on in the preferences > extras > use layout guides, as you can see - it loads and works as intended:

guides.png (35.64 KiB) Viewed 4611 times

[mwieder]

If the option to use it is turned on in the preferences > extras > use layout guides, as you can see - it loads and works as intended:

Erm... yes, and then the errant code doesn't get executed. But if it's turned *off* in preferences then the stack is *not* in memory at startup.
Comment out the else statements and see if the devguides stack is around. I find it isn't.

[tperry2x]

?
If it's turned off in preferences, then it's unloaded by this function. (fully) Otherwise it's always active. (hence why the "--guides are on" does nothing else)

The on and off switch does work.
The stack is unloaded if the checkbox is off (so the stack also isn't showing up as it's fully removed from memory).
If it's on, the function does no unloading and lets the plugin load - so then it's active, as shown on my demo above.

Comment out the else statements and see if the devguides stack is around. I find it isn't.

It wouldn't be, because without the else statement, you are unloading it and removing it from memory regardless if the checkbox is on or off in the preferences.

[mwieder]

It wouldn't be, because without the else statement, you are unloading it and removing it from memory regardless if the checkbox is on or off in the preferences.

Sorry for not being clear. What I meant is to remove the *whole* else clause for the test. That clause either doesn't get executed if the property is true or causes an error because the stack can't be found if the property is false.

Code: Select all

else
  -- the guides are off
  -- put "community.ferruslogic.plugin.devguides" into tCloseFerrus
  -- send "extensionFinalize" to stack tCloseFerrus
  -- set the destroyStack of stack tCloseFerrus to true
  -- close stack tCloseFerrus
end if

And then look at the list of stacks and see that the devguides stack isn't in memory. It never gets loaded if the property is false.

[richmond62]

Screenshot 2024-08-03 at 19.21.44.jpg (266.96 KiB) Viewed 4388 times

-
If those "funny pink lines" are the Layout guides: then they are a great help, especially for group placement.

Mind you, quite why the MacOS screenshot thing turned my cursor from red to a sort of 'tired dog shit brown' I'll never know.

[tperry2x]

Sorry for not being clear. What I meant is to remove the *whole* else clause for the test. That clause either doesn't get executed if the property is true or causes an error because the stack can't be found if the property is false.

Ah, right - I was taking it too literally.
I remember now, I moved the unload to the extension - in the extensionInitialize handler.
So that's why this has no effect!

Do you also get an error if it's commented out in the home stack?

[mwieder]

No, no error in that case. The else clause could be safely deleted without causing any harm.

[tperry2x]

Okay, if you are not already on build 202408020944 (which you can check from Help > IDE Information), you should now be able to update and have this commented out.

If you were already on build 202408020944, edit the ".buildnumber" file in the same folder as the OXT Lite application. You want to replace the build number with 202408020943
Then reopen the IDE and check for updates again.

(once you run the update, you'll not have to do this anymore - as I've also added an option to re-run the last update for scenarios like this)

[mwieder]

Ah... check for updates. I have to get used to that workflow.
Yes, the error is gone now. Thanks.

[tperry2x]

If those "funny pink lines" are the Layout guides: then they are a great help, especially for group placement.
Mind you, quite why the MacOS screenshot thing turned my cursor from red to a sort of 'tired dog shit brown' I'll never know.

Yes, they are the layout guides. They were a great free open-source addon that I thought OXT Lite could really do with, courtesy of FerrusLogic.

The "Dog sh1t brown", I can't help with - other than noticing it's because the colours of it are inverted. As to why, not sure.

[tperry2x]

Ah... check for updates. I have to get used to that workflow.
Yes, the error is gone now. Thanks.

Good stuff. Yes, it's a bit 'Microsoft' with unending updates, but it gets the job done.
Better than downloading afresh each time.

[richmond62]

It's also a bit Debian and derivatives with endless updates.

Would there be a way so that when updates have been applied, instead of an automatic quit and a manual restart, there could be and automated both?

[mwieder]

On a different topic...

I've been concentrating on the engine itself and leaving the IDE stuff to you and Paul, but I've got a couple dozen or so bug fixes and enhancements that I've done on my own to IDE stacks. Since you're not on github I'm not sure how to submit these to you. Paul's IDE is on github but it seems out of date and my pull requests there have been ignored for a long time now.

Suggestions?

[tperry2x]

You should be able to upload them here (all in a zipped folder if you like).
If you just mention what you changed, or don't worry as I'll use a diff-compare to see what was changed.

[tperry2x]

Would there be a way so that when updates have been applied, instead of an automatic quit and a manual restart, there could be and automated both?

You mean, so when the IDE quits, it then reopens?
On older MacOS, and on Linux - yes.
On Windows and newer MacOS - no. (They see it as a 'chain-loader' so such behavior is blocked). Unless you start getting into daemon processes and windows services - but I'm not going there.

[mwieder]

You should be able to upload them here (all in a zipped folder if you like).

I'd rather start a separate thread for this rather than polluting this catch-all topic that's already on page 22.
For now I'd just point you to the open pull requests on https://github.com/OpenXTalk-org/OpenXt ... tion/pulls.

[tperry2x]

You should be able to upload them here (all in a zipped folder if you like).

I'd rather start a separate thread for this rather than polluting this catch-all topic that's already on page 22.
For now I'd just point you to the open pull requests on https://github.com/OpenXTalk-org/OpenXt ... tion/pulls.

That's cool and everything, but the first one I came to - I don't even use "About.txt", so that only applies to OXT DPE.
I guess I'll just have to wade through them one by one then? Seems like a lot of extra work, but okay

[tperry2x]

On this one, can you elaborate?
What is taking 49 seconds to run?

[richmond62]

What everyone needs to be aware of is that from now on OXT Lite and OXT DPE do need to be treated as separate beasts as they have diverged significantly.