REALconsoleSafe and not

When adding a class to an existing plugin you cannot set the REALconsoleSafe flag because choosing an empty ConsoleApplication template and issuing the run-command, it leads to compilation errors related to classes that don’t have this flag set. I would have expected that the classes that don’t have the REALconsoleSave flag would not be involved. The new class does not reference anything with respect to the existing classes defined in the plugin.

So I tried to set the REALconsoleSafe flag on every class but cannot do this on the two invisible controls. Subclasses of these controls with the REALconsoleSafe flag, complain because their superclass is a control.

I’d like to have this new ConsoleSafe class in this plugin (where came this misnomer from?, it has nothing to do with the console, it should be terminalSafe). Does the new class need to be compiled in a separate bundle/dll? Or is something completely wrong with the plugin? Note that avoiding the REALconsoleSafe in the new class allows an empty consoleApp to compile and run ok. Also, when the REALconsoleSafe is set, an empty or implemented Desktop app is properly compiled and runs fine.

You should set console safe only on those things that are safe for Console apps - which means they will work in a console app OR GUI app. If you don’t set it the expectation is its for a GUI app only.

And don’t set it on things that cannot work in a Console app. Like anything that requires a subclass of Control as Controls do not exist in Console apps.

Norm, I know what can and what cannot. If your answer relates to: you cannot have controls and consoleSafe classes in one plugin because Xojo cannot handle these to separate them out then that would be a fair answer.

I’m not seeing anything that jumps out at me that suggests this should be an issue.
However I can imagine that if you have a namespace that is not console safe and try to add a console safe class into it that there could be an issue.
I dont suppose thats what you’re trying to do ?

You could send me your plugin off list as an email attachment & I could load it up in a debug version of the IDE & see if I can see whats going on

Alfred, what you can do is to register this control as class for a Console plugin.
Than the console safe flags would work.

[quote=306877:@Norman Palardy]I’m not seeing anything that jumps out at me that suggests this should be an issue.
However I can imagine that if you have a namespace that is not console safe and try to add a console safe class into it that there could be an issue.
I dont suppose thats what you’re trying to do ?[/quote]

I know what was wrong, Calling REALGetClassReff on the invisible controls while in design time. That confuses Xojo. Fixed it by calling it in runtime.

[quote=306931:@Christian Schmitz]Alfred, what you can do is to register this control as class for a Console plugin.
Than the console safe flags would work.[/quote]

Yeah, I just wished the invisible control would be treated as a controller like XojoScript. Switching the invisible controls to a class is doable, but it defies the purpose for desktop applications. This whole plugin has nothing to do with accessing GUI stuff but setting some parameters in design time would be beneficial.

By the way, calling REALnewInstanceWithClass, or REALnewInstanceOfClass fails in the console application, but not calling it from the run event (which is directed to the plugin, which would issue one of the two factorization APIs). Not sure if this is to be expected.

I mean, dim myClass as new BasicScripter works fine in the run event of the consoleApplication. Doing it from the plugin fails.

[quote=306997:@Alfred Van Hoek]By the way, calling REALnewInstanceWithClass, or REALnewInstanceOfClass fails in the console application, but not calling it from the run event (which is directed to the plugin, which would issue one of the two factorization APIs). Not sure if this is to be expected.

I mean, dim myClass as new BasicScripter works fine in the run event of the consoleApplication. Doing it from the plugin fails.[/quote]

I have had issues with REALnewInstanceWithClass that I was never able to pinpoint fully why or how.

What I do know is it happened to me when the class was in a module. Taking it out of the module solved the problem. But at same time I had other very similar case in a module where all was fine, I never found why one worked and the other not.

Norm,
in the terminal I get a harmless message:

Plugin requested unavailable entrypoint: PluginRegisterControl Plugin requested unavailable entrypoint: PluginRegisterControl
followed by successful initiation:

[code]/Developer/Xcode&CW/Script Plugin/Script Plugin Converter/Sample Projects/Basic Interpreter.debug/Basic Interpreter.debug

in Bas_Initializer
in _on_startup
in _open_mem_pool
out _open_mem_pool
in _create_code with instance 17919280
out _create_code
out _on_startup[/code]

Since the plugin is registering two invisible controls, do I need to encapsulate these at REALinRuntime() and call

REALLoadFrameworkMethod("App() As ConsoleApplication"

to prevent these messages to show up? Or should I file some bug report?

[quote=307189:@Björn Eiríksson]I have had issues with REALnewInstanceWithClass that I was never able to pinpoint fully why or how.

What I do know is it happened to me when the class was in a module. Taking it out of the module solved the problem. But at same time I had other very similar case in a module where all was fine, I never found why one worked and the other not.[/quote]

Hmm, I seem to have solve this, but sometimes get a Segmentation fault: Make sure you call REALGetClassRef to your class in design time and in runtime. However, I assume you did that already.

I never saw those log messages. Are them from your own code?

yes.

Adding some more weirdness. The plugin successfully instantiates the class instance and Xojo gives it a lock count of 2. However, when the console app is exiting, cleaning up by REALUnlockObject leads to a segmentation fault. Avoiding this call remedies it, but the finalizer of this class is then never called under these conditions. This is baffling because in a GUI app, calling REALUnlockObject is just fine. Am I missing something?

If you could send me some examples of what you’re seeing, that’d be helpful.

I guess it has everything to do with the usage of a stdlib API:

int	 atexit(void (* _Nonnull)(void));

It is used within the plugin after redirecting the run event to a myMain entry point. The call

atexit(_on_exit);

is issued before everything else. “_on_exit” is called after the run event, Xojo decreases the ref count, lock count to 1. The _on_exit needs to access the instance and at the end of that procedure it calls the REALUnlockObject, which sometimes triggers the finalizer lock count = 0, or it reports a bus error, segmentation error 11, or a Runtime failure in REALstring.
It appears that anything being called after the run event gets screwed. To be expected, I guess?

[quote=307460:@Alfred Van Hoek]I guess it has everything to do with the usage of a stdlib API:

int	 atexit(void (* _Nonnull)(void));

It is used within the plugin after redirecting the run event to a myMain entry point. The call

atexit(_on_exit);

is issued before everything else. “_on_exit” is called after the run event, Xojo decreases the ref count, lock count to 1. The _on_exit needs to access the instance and at the end of that procedure it calls the REALUnlockObject, which sometimes triggers the finalizer lock count = 0, or it reports a bus error, segmentation error 11, or a Runtime failure in REALstring.
It appears that anything being called after the run event gets screwed. To be expected, I guess?[/quote]

I’d love to see an actual example because the runtime failure in REALstring sounds interesting.

What are you taking about?
Run event? Is that a thread subclass?

Do you trigger destructors on a thread which can only run on main thread?

[quote=307472:@Christian Schmitz]What are you taking about?
Run event? Is that a thread subclass?

Do you trigger destructors on a thread which can only run on main thread?[/quote]

Really? Does App.Run event ring a bell?