Hi y'all, I think the other thing you can do (and this would work in 2006/GB) would be to simply publish the Counter name parameter. If I'm reading it right, the issue is that the Counter name is the same in each instance which causes an ongoing count.
Go to the custom transformer tab (or open the fmx file). In the navigation pane (WORKSPACE tab) expand the list of transformers in there and find the Counter. Expand the counter settings. Right-click counter name and choose publish. Click OK. Now back in the main part of the workspace click on the settings button for one of the 3 custom transformers. See how the name is now published. Go through all your transformers and make sure the name is different in each case - eg counter0, counter1, counter2 Hope this helps. Publishing parameters is so useful for things like this. I just tried it in 2006GB and it seems to give the results you'd expect. If you need I can send you my example workspace. Regards, Mark Mark Ireland, Senior Product Specialist Safe Software Inc. Surrey, BC, CANADA [EMAIL PROTECTED] http://www.safe.com Solutions for Spatial Data Translation, Distribution and Access --- In [email protected], Matt Adam <[EMAIL PROTECTED]> wrote: > > Hello Simon, Jason... > > Jason is right here, the Counter has traditionally been "global" in > scope. If you have one inside a custom transformer, all instances of > the custom transformer share that same counter. > > Fortunately the situation has been improved recently. If you download a > recent FME 2007 beta, your counter will have a new "Count Scope" > parameter that lets you specify whether that count sequence should be > "Global" (shared between all instances) or "Local" (unique to that > transformer). > > Good luck! > > > -- > -------------------------------------------------------------- > Matt Adam [EMAIL PROTECTED] > Developer, Safe Software Inc. (604)501-9985 ext.234 > -------------------------------------------------------------- > > Jason Birch wrote: > > It may be because the Counter uses a (terminology unsure) global > > attribute to store the current count. You may need to expose this > > parameter of the counter, and set it differently for each input. > > > > Jason > > > > -----Original Message----- > > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of > > jusiheap > > Sent: Thursday, September 07, 2006 09:06 > > To: [email protected] > > Subject: [fme] Re: Inserting section headers into text file > > > > OK, my follow up question is a bit more involved. Here goes ... > > > > My workspace has a number of different source feature types down the > > left hand side (e.g. Road, River, Rail, ...). Individually, each feature > > type feeds into its own set of transformers. Functionally, each set of > > transformers does the same thing (that is, performs the sequence of > > translations that we've discussed in this thread in order to generate > > section headers). The chief reason for each feature type having its own > > set of (duplicate) functionality is because each feature type needs to > > set up and use its own Counter transformer. Ultimately each of the > > threads feeds back into a single text writer, but nevertheless there's a > > lot of duplication on my workspace. > > > > Aha, I think - surely I can build a custom transformer that embodies > > this set of common transformations, and which can be called individually > > from each of my feature types. So I created a single custom transformer > > from one of my common sets - now on my main workspace I had a single > > custom transformer and the remaining sets of common transformations. > > Then I replaced each of the remaining common sets with copies of the > > single custom transformer. I ran the translation and ... didn't get what > > I wanted - in that I wanted each separate copy of the custom tranformer > > on my main workspace to be invoked independently of the others, but > > instead it appears that they all got thrown into a single custom > > transformer. Thus, for example, the Counter transformer was invoked on > > the entire set of features and therefore only one feature was identified > > as being the first. > > > > If any of this makes sense, I have two questions: > > 1. Is my understanding/expectation of custom transformers > > incorrect/misguided? > > 2. What solution would you recommend, in order to reduce complexity and > > duplication in my workspace.? > > > > On a more general note, my evaluation of FME is all about proving (or > > otherwise) that the benefits of using FME outweigh those of implementing > > translation software in-house, and a key issue for me will be the scope > > for modularisation, abstraction, code re-use. > > > > So the floor is open to anyone that wishes to comment on this aspect of > > FME ... > > > > Thanks > > Simon > > > Join us at the FME Worldwide User Conference Sept. 21-22, 2006 Vancouver BC Canada. For more information, visit www.safe.com/2006uc. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/fme/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/fme/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
