Thanks Hugh, that's the idea I had in mind. However, I'm beginning to see the limitations of this approach. Unless I'm missing something, it can only work if the right operand of the pair is a literal value. In other words, I could do something like "ChartSize=tVar", where tVar is a variable in the handler that issues the call. Similar problem if I wanted to pass the id of control as the right operand.
So while I can make use of this technique when I want to pass literal values, it seems that it the engine would have to recognise this syntax and resolve any non-literal values involved before invoking the called procedure. I also learned something new - that there's a limit to the amount of data you can pass in to handlers in parameters. As far as I know I haven't run into that but sounds like it's something that should be checked if there's any danger that it could happen in any specific handler. Pete lcSQL Software <http://www.lcsql.com> On Sat, May 5, 2012 at 1:11 AM, FlexibleLearning <ad...@flexiblelearning.com > wrote: > ChartMaker uses the 'keyValue pairs' syntax (in the form "Key=Value"), of > which any, some or all can be passed as parameters like this... > > get CMBarChart("ChartSize=500,300","Values=[list of > values]","Categories=[list of categories]") > > > The app first applies all the defaults in an internal array. It then parses > any specified keyValue parameters to update the array that is then used to > create the chart. The keyValues are finally stored in the chart for later > use. Once the app's initial parsing scheme is written is it relatively > straightforward to modify it with new keyValue pairs. > > The advantage of this method is that the order of the parameters is > irrelevant and their contents can be optionally passed as variables for > coding simplicity... > > get CMBarChart(tChartSize,tValues,tCategories) > > > The main downside of passing parameters is the engine's limits on total > parameter string length. If too much data is passed, the engine simply > truncates the data to the maximum length it can handle. > > If the amount of data does exceed the engine's parameter-passing limit, > then > the data elements have to be iteratively set directly (e.g. set the uValues > of group "Chart1" to [a very large dataset]). I personally find this a more > cumbersome syntax than the keyValue syntax but it does mean there are > limits. For ChartMaker, the limits are about 15,000 data points (depending > on overall string length, of course). > > ChartMaker is available from www.FlexibleLearning.com/chartmaker > > > Hugh Senior > FLCo > > > > Peter Haworth wrote: > > I seem to recall somewhere in the dim distant past that some languages have > a syntax where function and procedure calls can have named parameters > rather than positional ones. > > function doIT p1,p2,p3,p4,p5,p6,p7,p8,p9,p10 > .. > .. > end doIT > > put doIT("abc",p3="xyz", p10="def") into tVar > > When functions have a large number of possible parameters but not all of > them are required, this is a great way to avoid having to count commas in > the calls to them. > > I don;t think LC has any such syntax built in but wondering if anyone has > tried to implement something similar? > > Pete > lcSQL Software <http://www.lcsql.com> > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
