Error 414

[Dave Paton]

I saved an Inc file using the PBComBrowser of a third party library (Surfer 8 Type Library 1.0). One of the methods, GridData, which is like THE KEY method when it comes to creating a Kriging variogram has 57 parameters. Error 414 states ")" expected - The statement's syntax requires a right parenthesis ()). The compiler encountered text or symbols where a right parenthesis was expected, or a parenthesis is missing. This error can also occur when attempting to pass more than 32 parameters to a Sub, Function, Method, or Property. The last bit about 32 parameters is the problem. What is so special about 32? The Help file says the way around this is to create a User Defined Type, but the folks at Surfer cannot tell me whether this will work or not. Is there any way to get around this limit of 32 parameters?

[Mel Bishop]

I do not know the answer to this question but does a GLOBAL variable count as a parameter?

[Rodney Hicks]

The documentation states that a 'METHOD' is very similar to a 'FUNCTION'. Documentation for 'FUNCTION' states that a function is limited to 32 parameters.
The documentation for 'METHOD' does not state a limit, but may be adhering to that figure. Check with PB support for clarification.

[Cliff Nichols]

like the doc has said for quite some time

Parameter restrictions


PowerBASIC compilers have a limit of 32 parameters per FUNCTION. To pass more than 32 parameters to a FUNCTION, construct a User-Defined Type (UDT) and pass the UDT by reference (BYREF) instead.

Why 32? your guess is as good as mine unless I google it, but I would hazzard to guess in the past the value would be 16 for 16 bit processing, 32 for 32 bit processing, and sometime in the future 64 for 64 bit processing???

But that is a shot in the dark, and I may have just shot my cat

[Dave Paton]

I am not aware of any Global variables. The actual syntax is...
object.GridData( DataFile, xCol, yCol, zCol, ExclusionFilter, DupMethod, xDupTol, yDupTol, NumCols, NumRows, xMin, xMax, yMin, yMax, Algorithm, ShowReport, SearchEnable, SearchNumSectors, SearchRad1, SearchRad2, SearchAngle, SearchMinData, SearchDataPerSect, SearchMaxEmpty, FaultFileName, BreakFileName, AnisotropyRatio, AnisotropyAngle, IDPower, IDSmoothing, KrigType, KrigDriftType, KrigStdDevGrid, KrigVariogram, MCMaxResidual, MCMaxIterations, MCInternalTension, MCBoundaryTension, MCRelaxationFactor, ShepSmoothFactor, ShepQuadraticNeighbors, ShepWeightingNeighbors, ShepRange1, ShepRange2, RegrMaxXOrder, RegrMaxYOrder, RegrMaxTotalOrder, RBBasisType, RBRSquared, OutGrid, OutFmt, SearchMaxData, KrigStdDevFormat, DataMetric, LocalPolyOrder, LocalPolyPower, TriangleFileName )

Apart from 2 strings, 3 longs and 1 SrfGridFormat, all the other parameters are variants, so this method is a memory hog. I didn't design it - I just have to use it and figure out how to get PB9 to like it.

[Gösta H. Lovgren-2]

I just have to use it and figure out how to get PB9 to like it.

Smile coquettishly?

[Dave Paton]

This may not be the best workaround, but it is functional. If you have a COM Browser generated method or function statement with more than 32 parameters, you can delete those parameters that you are reasonably certain you will never need in the future to get your parameter count down to under the magic 32 limit. By doing this, you can get PB to compile the project without errors. You can also delete other defined methods in the include file if you are sure you won't need them in the future and thus reduce the size of the include file. The limitation to this solution, of course, is that if your needs change in the future, you may have to regenerate the include file via the COM Browser and make appropriate changes to reflect your new needs. I found that a UDT would not work to reduce the number of parameters.

[Cliff Nichols]

ok I gave it a bit before I made this comment (and will try to keep it as PB friendly as I can)

I can understand trying not to limit tooooo much as to parameters (within reason), and I can understand PB up to 32 (nice buffer of not limiting the programmer)

But WHO???? In their right mind would have 32 parameters??? (If it were me, I would quickly start working on where I went wrong and fix it)

But OMG 54 parameters??? Whatever monkey they have typing Shakespeare, REALLLLLYYYYYyyyy needs to hire better monkey's for less bananas

Attempting to look at a worst case scenario, best I can come up with is 23 to 27 parameters, and even then I am sure they could be broken down to smaller more readable parts for debugging. (Pitch Yaw Roll, reference, etc...if I was programming a "Black Box" for airliners or something)

54?? Jezus sakes....I would NEVERRRRRR use anyone's functions taking that many parameters...whoever came up with that concept had a monkey banging on a keyboard, and needs to be fired


That said, another option (maybe) if the back of my mind reminds me, is if you can fill parameters into an array and then fill the function with each element of the array? (like a VB paramarray, which was a good and bad idea at the same time)

Overall, I doubt it would work but worth a shot and anyone that would create a function like

object.GridData( DataFile, xCol, yCol, zCol, ExclusionFilter, DupMethod, xDupTol, yDupTol, NumCols, NumRows, xMin, xMax, yMin, yMax, Algorithm, ShowReport, SearchEnable, SearchNumSectors, SearchRad1, SearchRad2, SearchAngle, SearchMinData, SearchDataPerSect, SearchMaxEmpty, FaultFileName, BreakFileName, AnisotropyRatio, AnisotropyAngle, IDPower, IDSmoothing, KrigType, KrigDriftType, KrigStdDevGrid, KrigVariogram, MCMaxResidual, MCMaxIterations, MCInternalTension, MCBoundaryTension, MCRelaxationFactor, ShepSmoothFactor, ShepQuadraticNeighbors, ShepWeightingNeighbors, ShepRange1, ShepRange2, RegrMaxXOrder, RegrMaxYOrder, RegrMaxTotalOrder, RBBasisType, RBRSquared, OutGrid, OutFmt, SearchMaxData, KrigStdDevFormat, DataMetric, LocalPolyOrder, LocalPolyPower, TriangleFileName )

should not only be ashamed of themselves, but also worry if they are an "Oxygen-Thief"???

[Dave Paton]

Actually, when you understand kriging, which is a form of geostatistics, 57 parameters is pretty short, when you consider that there are many flavours of kriging, including simple kriging, minimum curvature, modified Shepard's method, nearest neighbour, natural neighbour, polynomial regression, radial basis function and triangulation with linear interpolation. All the methods are very similar and some have more parameters than others. As in my previous post, you can omit the parameters that you might never use to get the parameter count down to under 32 and still have the compiler work OK.

[José Roca]

you can omit the parameters that you might never use to get the parameter count down to under 32 and still have the compiler work OK.

Only if you use Automation (OBJECT CALL, etc.), and named parameters. If you use positional parameters it will fail.

[Dave Paton]

Using named parameters is how I've been using this function in VB6 and from what I can see, once I figure out how to create and access the object in PB, the coding is going to be very similar between VB6 and PB9. Actually, when I say that the project will not compile, I was refering to the include file when you just add it to a project and compile. Up to this point I've just been trying to get the include file into the right format for the PB compiler. But your comments about automation are interesting and I've just started to explore your web site. I've actually got a post there about GUID's.

[Cliff Nichols]

Just an off idea, that may work but I have not tried it yet myself.

VB has "ParamArray" (not sure the limit of parameters though), that might be replicated in PB (with some "slight-of-hand" of sorts).

If it is possible, then the "Slight-of-hand" trick, may actually make 1 large function readable by breaking down to multiple smaller functions.

Although I will admit I do not understand "Kringing", but a quick look at the generic formula's it is just a summation of multiple parts (aka: Function results)

Worth a shot anyways....