> Variables are declared for indexes, since you are likely to need > temporary storage to create the index before creating the rowreq context. > The other two are assigning data to the data context, and thus should be > real values. Until recently, those variable names were of the form > TODO_FIND_nsIETFWGChair2, which made it pretty obvious what was needed.
Yes - I thought it might be something like that. This is sort of what I mean by the distinction between "ready-to-go" and template code. > BTW, you might want to use a test table with multiple types in it. Yes - my test table does. It's Wes' that doesn't :-) DS> I'm sure it will all fall into place once I've DS> a better idea of how it all fits together, but at the moment I DS> feel like I'm drowning in caterpillers :-) > Hopefully the cmd line I send to generated the ordered todo list will > help a little, at least in terms of where to go first. Give us a chance, Robert! I'm still trying to come to terms with what this helper does do. I'm nowhere near ready to start looking at what it *doesn't* do! :-) > I'm a little disappointed (but not too surprised) that the README > files didn't help. Suggestions welcomed! You're being too hard on yourself, Robert. The README files probably *will* help, now that you've pointed me in the right direction. It's just stuff like the description of the mib2c control variables and the regurgitation of the MIB definitions that was muddling things a bit. I'm basically still identifying what can be ignored, and what is actually useful :-) Remember that I'm used to Wes' style of coding, and you tend to work (and comment) in a very different way. DS> Is there any way to get hold of the container at a later DS> stage > No. Maybe it should be added as a parameter to one of them... No - don't do anything just yet. I'm simply trying to get a picture of what's possible at the moment. I'm hesitent to start tweaking APIs piecemeal - much better to wait until I'm up to speed on this helper, and we can discuss the best way to proceed. We're probably looking at 5.3 anyway, so there isn't a major rush! > I'd rather not expose the internals any more than I > have to. Maybe I should add insert/find/delete utility routines. > That would allow containers to be replaces with something else > without requiring the user code to change... hmmmm... One thing that struck me with the user-array helper (and it may apply here too), is how much was effectively duplicating code that was also in other helpers (perhaps with a different API). Similarly with the table_container and table_data helpers. One thing I'd like to explore (in due course) is whether we could sensibly consolidate some of these helpers so that they worked togethe a bit more, rather than in isolation. The less code we have to maintain, the better! But I don't think this is quite the right time for that discussion :-) Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
