Just because one can do something, doesn't mean one should. If you
the 'standard' then that is your choice. Just as long as you
your PC out to the curb. It contains lead, Windows Vista, mercury and
> Thanks Kent for the fine explanation. So functions from plugins can
> take any name (as do custom functions), but, the community and FMI
> frown on not inserting the 4 char prefix out of concern for naming
> conflicts. What about going with a suffix as opposed to prefix? The
> advantage there is that the function is then more easily selected
> via type-ahead (based on the concept that the actual function name
> is more informative of the resulting action than the 4 char unique
> identifier). Is there a specific guideline stating the identified
> should be a prefix as opposed to suffix?
>
> On a related basis, is it possible for a function from an external
> plugin to appear in the "all functions by name" view for functions
> in Specify Calculation dialog? Oddly, they appear when selecting
> "all functions by type" but not by "name". So, "all" means different
> things depending upon which "all" you select (I also have a big
> problem with the fact that the built-in Get functions don't appear
> in "all functions by name", but, that's another story.) I suspect
> it's not possible to have one's plugin function listed in "all
> functions by name", just seems like a UI inconsistency to me.
>
> On Oct 24, 2009, at 1:44 PM, Kent Lendrum wrote:
>
>> Hi Bill,
>>
>>> So, to answer my question, it's a technology requirement or FMI
>>> rules requirement?
>>
>> It's not a 'technology' requirement, as it is entirely possible to
>> create external plugin functions without it - however it is good
>> practice if you intend to on-sell your plugin.
>>
>>
>>> I don't know if there is a formal mechanism for a plug-in
>>> developer to
>>> "register" a prefix, or if the developers just know what is
>>> available and
>>> pick something unique when they develop new plug-ins.
>>
>> In the FM 5 days, the instructions said you were to register your
>> 4 character code on the Apple Developer web site, even if your
>> plugin was going to be windows only, but this would confirm your 4
>> character code was unique with any application
>>
>> I don't know if this is still the case however.
>>
>>
>>> Naming conventions for external functions
>>> The function name prefix for all of the plug-in's external
>>> functions must be
>>> a unique value containing four or five characters and must not
>>> begin with
>>> the characters "FM" or "Web." Four-character prefixes are reserved
>>> by
>>> FileMaker. For example, the FMPluginExample plug-in's function
>>> name prefix
>>> is "XMpl."
>>
>>
>> Remember there are two places where this 4 character code is used.
>>
>> The most important is the pluginID which is passed with
>> registering your functions. If you change this, then things break :
>>
>> fmx::QuadCharAutoPtr pluginID('A', 'B', 'C', 'D');
>>
>>
>> Last time I duplicated my plugin as a template, but forgot to
>> change the pluginID, neither loaded - which caused me great
>> confusion for a while.
>>
>> The next is your plugin function names themselves - these obviously
>> need to be unique, and most plugin developers used the above
>> character code for their plugin function names.
>>
>> eg.
>> ABCD_Version
>> ABCD_VersionAutoUpdate
>> ABCD_MyFunction
>>
>>
>>
>> This however doesn't mean you can't create a function name without
>> the leading 'ABCD_', it just isn't ideal. And hence why FM
>> themselves have stipulated all plugins must use a unique 4
>> character code.
>>
>> For example, in my own plugin I have a function 'sp'. I don't sell
>> my plugin and it's only used by my solution, so I kinda feel it's
>> okay - but I know it's not following FM's guidelines.
>> In reality, I could have created it as a custom function - as
>> that's all it really is - and there aren't any rules for custom
>> function names - but it was easier to create a plugin call, than
>> add the Custom Function to 40+ files.
>>
>>
>> Kent.
>>
>>
>> _______________________________________________
>> The Troi plug-list mailing list
>>
[hidden email]
>>
http://mail.troi.com/mailman/listinfo/plug-list_troi.com>
> Bill Doerrfeld
>
[hidden email]
> www.BillDoerrfeld.com
>
>
>
>
>
> _______________________________________________
> The Troi plug-list mailing list
>
[hidden email]
>
http://mail.troi.com/mailman/listinfo/plug-list_troi.com
