TMS scripter Roadmap or enhancements ?

Hello,

I use TMS scripter since more than 20 years. For me it is one of the most powerful, stable and efficient component library on Delphi. I'am studying to use it on Android/IOS app.
What I need :

  • Delphi Compiler Directives. I only need {$IF} {$IFDEF} {$ELSE} {$ENDIF} to use same script on different version of project or same script for Windows/MacOs
  • Updated version of SSimport.exe. For new Delphi and better source handling like TObject casting NativeUInt(...) etc.
  • Included Native Delphi library like System.IOutils etc. Maybe all System.*. Only for the last version of Delphi in a first time.
  • Webservice WSDL importation and handling (like in Delphi Component / Import WSDL)

Hi @Fab, thank you for the nice words.

You can register your feature requests individually in our feature request system. Other people can vote for them so we can gather the interest. Some personal comments:

  1. I think directives is not very useful/common, as you can always create your own Delphi methods with directives and make the scripter more "cross-platform" for your users
  2. SSImport: we are focusing more on the DefineClassByRTTI and other automatic registration than the import tool.
  3. That is a nice suggestion, but again keep in mind that you can register the methods yourself.
  4. This is very specific feature. What about the approach of importing WSDL via Delphi and then registering the imported WSDL classes in scripter?

Hi Wagner,

  1. I think directives is not very useful/common, as you can always create your own Delphi methods with directives and make the scripter more "cross-platform" for your users

It is that I do. But I want to share script between platform, software version or software using same framework without having to change something in the Delphi developer side. With compilation directive it could be done by end-users.

  1. SSImport: we are focusing more on the DefineClassByRTTI and other automatic registration than the import tool.

I use a lot of DefineClassByRTTI but (for the moment ?) there is a lot of limits :

  1. Overrided method (it's take the first one)
  2. Optional arguments become mandatory
  3. Other limit I don't remember.
    To say the truth when I need to quickly add a library to scripter I first use DefineClassByRTTI. But, because of these limits, when my end-users start using it I usually end up declaring method by method
  1. That is a nice suggestion, but again keep in mind that you can register the methods yourself.

I have done it for some libraries but it was an hard job (record -> class). But thank you because you have helped me a lot.

  1. This is very specific feature. What about the approach of importing WSDL via Delphi and then registering the imported WSDL classes in scripter?

No my generic software need to handle any specific WDSL for my customer. Imagine my customer has an internal (or external) webservice. He need to exchange data between my software and this webservice. I don't want to recompile my software each time to handle this a specific webservice for a specific customers. I have started to see for python4Delphi and Python-zeep to do it. But your scripter is really really better (efficiency, speed, portability, nothing to install, full control, no dependant to the python version of the day and I hate case-sensitive languages ;-) ).

Fair enough, I understand. But still it's a very specific use case. Note you can also provide information for users like "IsAndroid" or "IsWindows" so that users can still check the existing platform and add specific code for them. Scripter syntax is much less complex than Delphi itself, so the need to do preprocessing for specific platforms is very low.

Yes, that's how we encourage users to do it these days. We happily accept suggestions to improve this workflow, but that's what we want to push forward instead of replying on the importer workflow.

I understand. But still I see this as very separated from scripter. I think most of the work is in the WSDL importer, not the scripter.