Suspending development tools

[TAK1974]

What is the difference between selecting "suspend development tools" from IDE and circumventing the IDE loading from the Home stack and running a stack directly in the engine? I have discovered that "answer" no longer works if circumventing the IDE. What else does it break?

TAK

[richmond62]

circumventing the IDE loading from the Home stack and running a stack directly in the engine

Can you tell me how you do that?

AND, if you suspend the IDE how you manage to load a stack in the engine alone.

[TAK1974]

I added a script to the startup handler of the home stack that opens an ask file dialog if I startup with the option key down. I open the selected stack then exit the startup handler, preventing the IDE from starting up. If you send "Startup" to the selected stack before opening the stack the selected stack, the stack will handle the startup message before receiving preopenstack, etc

[richmond62]

For instance, mucking around with the stack script of the "home" stack like this:
-

Screenshot 2024-03-13 at 20.41.04.png (104.37 KiB) Viewed 243 times

-
Means that the MenuBar and the Tools stack don't show up at the start on a Mac system.

But one can toggle the Tools stack from the Mac Menu bar, and one can easily access a lot of the IDE from there.

[richmond62]

If you send "Startup" to the selected stack before opening the stack the selected stack, the stack will handle the startup message before receiving preopenstack, etc

What is the advantage of doing that?

[TAK1974]

Actually you do get a menubar with an OpenXTalk menu that has a quit opentalk option.

TAK

[TAK1974]

The only advantage is if you want to receive a "startup" message. Normally the home stack gets that message and it is never received by other stacks.

TAK

[richmond62]

I'm not exactly sure why that would be useful in a stack, as one can use an on preOpenStack or an on openStack script in the stack.

In a standalone an on preOpenStack or an on openStack script in the stack would function exactly at startup.

[TAK1974]

I never said it was necessary. Just said the option was there. It's a message that is sent when OpenXTalk is launched but a user stack never receives. The engine is seems snappier without the IDE running behind everything.

TAK

[OpenXTalkPaul]

I never said it was necessary. Just said the option was there. It's a message that is sent when OpenXTalk is launched but a user stack never receives. The engine is seems snappier without the IDE running behind everything.

TAK

Correct, only the mainStack stack gets sent a startup message. In the IDE that is the Home stack, however in a standalone app the mainStack of your stack receives the startup message.

The IDE Home stack startup handler initiates the loading of all of the script libraries and stacks that make up the IDE, even before preOpenStack or any other message.

It's useful that 'on startup' happens before any stacks are windows are created. I had to edit that handler in the Home stack in order to get macOS darkMode to appear seamless. Originally I put those calls into 'preOpenStack' but then window frames would open in 'lightMode' until the preOpenStack fired, and you could see the change-over happen to the IDE stacks (palettes), not good.

The 'Suspend Development Tools' menu item I believe is meant to be a 'Standalone Preview' mode. I thought it just did that cosmetically (hiding palettes, changing the menu bar). Are you saying that it allows you to test 'On StartUp' handlers? I've never really used 'Suspend Development' other than to preview a custom menuBar. I guess it acts a bit like setting HyperCard's userLevel to something less than 5 (full authoring mode).

There is at least one other message that only gets sent to the mainStack on macOS, 'on appleEvent' which is how you can handle open file messages sent from the macOS Finder, and other inter-application AE messages too.

The engine might seems snappier because the IDE normally passes around all sorts of messages and I guess those messages are also suspended. Those messages are only relevant to the IDE (and any AddOns that subscribe to those messages). It's the same reason why a stack saved as a standalone app often performs better than the same stack running in the IDE.