Precompiler

Opto_Will

Is there a limit of the number of Parameters that @Params can handle in a Service?

I am trying to merge 2 services we have. One had @Params declared, the other had Param1-12 declared individually.

I can't for the life of me get the merged entity to compile without an Unassigned variable warning for Params 11 and Params 12 if I leave the @Params. (I can replace it with individual declarations and it compiles without warning.)
If I then try and call this Service using 12 parameters I get a "Too many parameters passed...."

I have this note from Enhancing BASIC+ Part 4:
"The SRP PreCompiler will replace @PARAMS with Param1 – ParamN, with N being the exact number of parameters needed to cover all your services."

So my question is , Is there a cap at 10 for @Params?

KevinFournier

There is no hard coded limit. I just did a simple test with a service that had 24 parameters and it compiled and ran fine. I will need to see code to diagnose any further.

DonBakke

@Opto_Will - Are you sure you have a service that has at least 12 arguments? Remember, the precompiler will only create the number of arguments in the declaration based on the largest number of arguments in your services. Thus, if you only have a maximum number of arguments of 10 (for example) then explicitly calling your service with 12 arguments will produce the "Too many parameters passed..." error.

Opto_Will

@KevinFournier

You answer is what I expected so I looked further.

I am confusing 2 symptoms and getting influenced where I should not.

Problem 1. The Service function has a Service that wants to accept 12 Parameters. On compile it complains about Param11 and 12 being unassigned. This is because the SERVICE_SETUP insert is only initialising 10 Params.
This is explained and understood then.

Problem 2.
Calling a Service with multiple Parameters is appearing to fail. I have stripped all the code out to the basics.

Function Test_Services(@Service, @Params) // @PARAMS test #pragma precomp SRP_PreCompiler $insert SERVICE_SETUP GoToService else Error_Services('Add', Service : ' is not a valid service request within the ' : ServiceModule : ' module.') end Return Response OR '' Service TestParams() JobTicks = Param1 PartCodes = Param2 MatCodes = Param3 MatQtys = Param4 ProQtys = Param5 QtysAll = Param6 DueDates = Param7 WcAlls = Param8 SetAll = Param9 ProAll = Param10 EmpCode = Param11 CltCode = Param12 debug end service

I then tried to call from another test procedure stub (from all 12 down to 1)
Param1 = "1"
Param2 = "2"
call Test_Services('TestParams', Param1, Param2)
This still gives the Too Many Variables.

This works though:
call Test_Services('TestParams', Param1)


I even used a different Environment with the same results.
I am using all the latest SRP stuff (Controls, Editor, Utils, etc) except the Frameworks proper. We are unfortunately stuck on a old version there for internal reasons.

This is obviously not fatal as I can just individually declare the 12 Parameters.
That doesn't sit right with my OCD though!!!

KevinFournier

When using SRP_PreCompiler, you specify the parameters directly and the precompiler handles the @Params invisibly. It should look like this:

Function Test_Services(@Service, @Params) #pragma precomp SRP_PreCompiler $insert SERVICE_SETUP GoToService else Error_Services('Add', Service : ' is not a valid service request within the ' : ServiceModule : ' module.') end Return Response OR '' Service TestParams(JobTicks, PartCodes, MatCodes, MatQtys, ProQtys, QtysAll, DueDates, WcAlls, SetAll, ProAll, EmpCode, CltCode) debug end service

Opto_Will

Doh! Of course that is the case. I know better than that.
I quite literally just explained that same concept for Events to someone here.
Total. Mental. Block.

And now I have just exposed my shame to the world!!!

Thanks @KevinFournier and @DonBakke for putting me back on the right path

KevinFournier

Don't beat yourself up. I've had some doozies, lemme tell ya.