Yeh, Joe has just clarified that. I think it would have been a pretty cool feature if C could have been mixed with Xojo, compiled with clang and then statically linked together.
It would be interesting, but the number of users of the feature versus the time required to implement, test, document, and support it makes it extremely unlikely to ever happen.
yes understood, that’s why I said “also liked” …
If that would be true for ALL plugins (once the old plugin format is gone) that would be a huge issue for plugin authors… and plugin buyers!
I can imagine.
I know this feature
I want like Christian said make dynamic popup menus like have the tables of MY database in a popup menu in the IDE
that’s not possible right now.
it would be nice to have some methods for each control that appears in the ide to :
-launch an editor (made like a future plugin ? that can have his own edit window you write in xojo ?)
-a paint-in-the-ide method that prevents you to have a dummy white rectangle for your custom control
this way you could make the xojo community work for you and make nice editors you could include in future revisions of xojo
that’s all benefit for anyone …
just my 2 cts…
I agree. It’s something that needs solving, but might exist for the first or second IDE release with this feature – I don’t know yet.
As for the C++ plugin system going away, that’s so far off that I wouldn’t worry about it.
I imagine this is because the plug-in contains llvm pre-compiled code which relies on the llvm ABI not changing. If Xojo upgrades the llvm infrastructure in a future version it could mean the existing pre-compiled code is incompatible. This is probably completely out of their hands. I guess the only way to avoid that would be for the plug-in to contain the original Xojo code in some encrypted format that could be re-compiled.
My gut feeling is that normal plug-ins would not be effected in the same way but i’m sure Joe will clarify.
[quote=188365:@Kevin Gale]I imagine this is because the plug-in contains llvm pre-compiled code which relies on the llvm ABI not changing. If Xojo upgrades the llvm infrastructure in a future version it could mean the existing pre-compiled code is incompatible. This is probably completely out of their hands. I guess the only way to avoid that would be for the plug-in to contain the original Xojo code in some encrypted format that could be re-compiled.
My gut feeling is that normal plug-ins would not be effected in the same way but i’m sure Joe will clarify.[/quote]
Yep, compatibility of the LLVM bitcode and the IR it represents between versions of LLVM is one of the concerns. The other problem is dealing with changes to the Xojo runtime. Things like the object structure changing, new flags being introduced, or even public-facing changes like adding a new property to a superclass.
Plugins written against the current C++ SDK don’t have this problem because they’re abstracted entirely from the runtime.