Precompiler

Opto_Will · February 2023

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 · February 2023

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 · February 2023

@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 · February 2023

@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 · February 2023

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 · February 2023

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 · February 2023

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

Precompiler

Comments