Plugin Methods not displaying Hints in IDE

Hi Folks,

If you use plugins (MBS, Einhuger, etc.) with your projects, does the IDE display the method hints when you roll you mouse cursor over a line of code in the code editor? There’s some disconnect between the Xojo team and what some of us are seeing.

Here’s what you see when you cursor-over a built in method:

Here’s what some of us see when we cursor-over a plugin method (UpdateNowMBS in this case):

These shots are from the latest (14.5) MBS plugins and Xojo 14r3.1.

If you’re not seeing the hints for plugin methods, please check in with <> and let them know.

well, let me try if I can change the plugin.

Fixed for next release of MBS Plugin.

I am confused here, what what wrong ? And is it wrong with other plugins ?

Basically, the moral of the story is to avoid using the deprecated REALRegisterStructure, REALRegisterEnum, and REALRegisterMethod functions. If you do use them, things like code tooltips might not work correctly.

Registering everything through modules is just a no go until Xojo makes it so that more than one segment can register module with same name so they end in same “namespace”

Its just silly when you got big plugin like for example PictureEffects which has large amount of segments and the only logical namespace would be same namespace for them all. And I would certainly not want to invent random namespaces for my users where they would need to do something like PictureEffectsPart1.XXXX makes no sense to let the user have to find out or even know or care about which part to use.

I would love to register all my globals in a MBS module.
But now I simply make them in GlobalsMBS, so I auto generate a lot of modules.

But what if your plugin has multiple segments inside it ?

nor sure, but maybe 50 modules?

Excatly !!

As you can probably Imagine then it would not make sense for your user to have to do


Since after all your user won’t have any idea that your function is in module 3 and not 7.

In some cases this is not a issue since it might be that methods group logically between segments, like for example if one module has Locale stuff and one Math stuff then its obvious and helpful for the user if its MBSMath.Something and MBSLocale.Something

While in other cases there may not be any logical grouping, like for example PictureEffects is segmented based on what your likely to use together so you don’t need to compile the huge library always as whole into your application.

They don’t need to know.

They just call SomeFunctionMBS and it’s in some module MathGlobalsMBS, but they don’t need to care for module name.

If the method are all in named modules but marked as global it wont matter.
They’re still global and can be used exactly as it always has