In reply to mseyunni:
Old post, but I have a similar problem: In some cases, the return value from tr.sprint() is from a totally different transaction type (i.e. not from tr). It works as expected if I call tr.sprint(my_tr_printer) instead of using the default printer (i.e. no sprint argument). Basically, I work around this problem by using a different printer instance for each transaction type when I call sprint from classes that deal with different transaction types (e.g. vseq, scoreboard). I don’t like this solution but it works.
In my case, the expected tr does NOT have a do_print() or convert2string() implementation; it relies on the field util macro for printing. The “bad” transaction that’s showing up in the middle of my message DOES have both of those methods implemented, similar to your example, and does NOT use the field util macros for printing.
Once the “bad” transaction is printed (intentionally), it sets printer.mstring and I think that’s what’s messing up the results in a subsequent tr.sprint() call. If printer.m_string is set, then sprint uses it. If not, then it returns printer.emit. Maybe it’s bad practice to mix-and-match setting printer.mstring in one transaction type and using the field macros in another, but the macros are handy and consistent when I don’t need a fancy message format implemented with convert2string.
Another solution would be to call convert2string()directly instead of indirectly via sprint()->do_print()->convert2print(). That only works if you know which transactions implemented convert2string() or if you implement it for all transactions.
I’d like to hear other suggestions for how to prevent this message mixup when using sprint().