Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

Re: New Plugins-SDK available: NOSTATICINIT (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: Re: Need a little more string detail
Next thread: Re: New Plugins-SDK available: REALSetMovieMovie


Re: New Plugins-SDK available: REALSetMovieMovie   -   Alfred Van Hoek
  Re: New Plugins-SDK available: NOSTATICINIT   -   Alfred Van Hoek
   Re: New Plugins-SDK available: NOSTATICINIT   -   Joseph J. Strout
    Re: New Plugins-SDK available: NOSTATICINIT   -   Alfred Van Hoek
     Re: New Plugins-SDK available: NOSTATICINIT   -   Joseph J. Strout
      Re: New Plugins-SDK available: NOSTATICINIT   -   Alfred Van Hoek
       Re: New Plugins-SDK available: NOSTATICINIT   -   Joseph J. Strout
   Re: New Plugins-SDK available: NOSTATICINIT   -   Peter Robinson

Re: New Plugins-SDK available: NOSTATICINIT
Date: 07.06.02 03:45 (Thu, 06 Jun 2002 22:45:06 -0400)
From: Alfred Van Hoek
#if defined(MPW_CPLUS) || defined(MPW_C)
#define NOSTATICINIT 1
#endif

There has been a lot of discussion in the past of the usage of __sinit() for
the classic environment. It seems as if all that was said about this was a
waste of time. The only thing we do see is that __sinit does not compile
when using MPW, which is not officially supported by RS.

I am disappointed that the reasons for not allowing commenting out __sinit
are not mentioned. 2 members of the plugin list have provided strong
arguments to use __initialize instead (also for CARBON). There was another
argument that opposed the use of __initialize in favor of __sinit, but that
argument was convincingly categorized as irrelevant.

But what are the exact reasons not to support __initialize, other then
saying " it could have possible side effects " without going into detail?

I am getting a bit upset here, also because an SDK is provided which does
not compile, and I have to add missing code... little things add up to a
growing frustration.. together with other things not mentioned here.

Alfred



- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: New Plugins-SDK available: NOSTATICINIT
Date: 07.06.02 04:22 (Thu, 6 Jun 2002 20:22:46 -0700)
From: Joseph J. Strout
At 10:45 PM -0400 6/6/02, Alfred Van Hoek wrote:

>I am getting a bit upset here, also because an SDK is provided which does
>not compile, and I have to add missing code... little things add up to a
>growing frustration.. together with other things not mentioned here.

How does it not compile? What missing code do you have to add? I
certainly don't see anything like that here. I'm eager to help, but
I'm not a mind-reader; please post what problems you're having and
we'll see about fixing them if at all possible.

Best,
- Joe

Re: New Plugins-SDK available: NOSTATICINIT
Date: 07.06.02 04:39 (Thu, 06 Jun 2002 23:39:47 -0400)
From: Alfred Van Hoek
on 6/6/02 11:22 PM, Joseph J. Strout at <email address removed> wrote:

> How does it not compile?

What I earlier posted on the Boolean Key function in the
REALcontrolBehavior. Please look and figure..

Alfred

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: New Plugins-SDK available: NOSTATICINIT
Date: 07.06.02 04:52 (Thu, 6 Jun 2002 20:52:15 -0700)
From: Joseph J. Strout
At 11:39 PM -0400 6/6/02, Alfred Van Hoek wrote:

> > How does it not compile?
>
>What I earlier posted on the Boolean Key function in the
>REALcontrolBehavior. Please look and figure..

I looked, but I can't figure. Please post the actual errors you're
getting. As I said in my reply, it compiles fine here, so we need to
figure out what the difference is between your setup and ours.

Thanks,
- Joe

Re: New Plugins-SDK available: NOSTATICINIT
Date: 07.06.02 05:24 (Fri, 07 Jun 2002 00:24:30 -0400)
From: Alfred Van Hoek
on 6/6/02 11:52 PM, Joseph J. Strout at <email address removed> wrote:

> I looked, but I can't figure. Please post the actual errors you're
> getting. As I said in my reply, it compiles fine here, so we need to
> figure out what the difference is between your setup and ours.
>

Error : illegal implicit conversion from 'void (*)()' to
'unsigned char (*)(REALcontrolInstanceStruct *, int, int, int)'
PluginMain.cpp line 203 iour->keyDownFunction buildEnvironmentShell(defn->behaviour->keyDownFunction);

for 68K: #ifdef USECALLSHELL

when:

defn->behaviour->keyDownFunction buildEnvironmentShell(defn->behaviour->keyDownFunction);

You know all other functions in the behavior provide correct function
pointers, but this one simply does not have

(Boolean (*)(REALcontrolInstance, int, int, int))

But yeah, no support for 68K, no such target to test, you won't figure.

Alfred

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>

Re: New Plugins-SDK available: NOSTATICINIT
Date: 07.06.02 14:56 (Fri, 7 Jun 2002 06:56:40 -0700)
From: Joseph J. Strout
At 12:24 AM -0400 6/7/02, Alfred Van Hoek wrote:

>Error : illegal implicit conversion from 'void (*)()' to
>'unsigned char (*)(REALcontrolInstanceStruct *, int, int, int)'
>PluginMain.cpp line 203 iour->keyDownFunction >buildEnvironmentShell(defn->behaviour->keyDownFunction);
>
>for 68K: #ifdef USECALLSHELL

Ah! You're right, I didn't test 68k. It all makes sense now. We'll
fix it soon.

Thanks,
- Joe

Re: New Plugins-SDK available: NOSTATICINIT
Date: 07.06.02 09:40 (Fri, 7 Jun 2002 09:40:41 +0100)
From: Peter Robinson
At 10:45 pm -0400 6/6/2002, Alfred Van Hoek wrote:

>#if defined(MPW_CPLUS) || defined(MPW_C)
> #define NOSTATICINIT 1
>#endif
>
>There has been a lot of discussion in the past of the usage of __sinit() for
>the classic environment. It seems as if all that was said about this was a
>waste of time.

No, I don't think so. Everyone involved now seems to understand the
issues, and know the limitations and benefits of the different
techniques. And now at least they've given you a simple flag you can
set if you want to do the 'right thing' in your plug-ins :)

>But what are the exact reasons not to support __initialize, other then
>saying " it could have possible side effects " without going into detail?

IMHO it is entirely understandable that RS have not got rid of the
call to __sinit. Thomas Tempelmann and I agree that the 'correct'
thing to do is to remove the call and set the demo projects to use
__initialize (and __terminate where appropriate). The trouble is
that this would require plug-in authors change the project settings
for all their plug-in projects or else they would lose even the
current level of functionality wrt static constructors.

There is a solution, which Thomas implements in his plug-in starter:
In main, check to see if the constructors did get called (by the
project settings using __initialize) and call __sinit manually if
not. That would not have backwards compatibility problems, and would
work whether or not the plug-in developer had done the right thing in
their project settings. It would take more of Joe's time though...

RS certainly should have changed the demo project settings to use
__initialize and __terminate under carbon, though (they don't call
__sinit at all under Carbon). That requires no code changes, and has
no negative side effects AFAIK. Did they make that change? I cannot
tell, because my older version of CW resets the project settings when
I import the demo projects.

Peter

- - - - - - - - - -
For list commands, send "Help" in the body of a message to
<<email address removed>>
Unsubscribe:
<mailto:<email address removed>>