{"id":143,"date":"2008-02-03T13:34:00","date_gmt":"2008-02-03T13:34:00","guid":{"rendered":"\/lisa\/post\/2008\/02\/03\/Beyond-TMM-analysis-of-a-bug-and-aftermath-of-architecture-work-What-happens-now.aspx"},"modified":"2021-08-30T14:27:36","modified_gmt":"2021-08-30T21:27:36","slug":"beyond-tmm-analysis-of-a-bug-and-aftermath-of-architecture-work-what-happens-now","status":"publish","type":"post","link":"https:\/\/spacefold.com\/lisa\/2008\/02\/03\/beyond-tmm-analysis-of-a-bug-and-aftermath-of-architecture-work-what-happens-now\/","title":{"rendered":"Beyond TMM, analysis of a bug and aftermath of architecture work: What happens now?"},"content":{"rendered":"

Bo Durban of Moxie data<\/a>\u00a0wrote to tell me about what I am sure is a bug even though I haven’t repro’d it yet. Not horrible, easy workaround, but a bug or bugs nonetheless.<\/p>\n

What, you thought there weren’t any?\u00a0 We’re very proud of the reporting work, and we appreciate your high opinion of it! Still, while the new-in-SP2 architecture elements are quite robust in general, this is bound to happen, and it will <\/em>happen, more than once, I’m sure.<\/p>\n

Try not to faint.<\/p>\n

Backstory<\/h3>\n

FXListener has some supported helper classes to perform the FX and GFX services supported by ReportBuilder extensions out-of-the box.<\/p>\n

We shipped more FX and GFX classes than FXListener has specialized class information for, and this distinction is critical, so I’ll say\u00a0this again:<\/p>\n

The ones you see supported explicitly by FXListener with\u00a0*class, *classlib, *module, and explicit instantiation\u00a0are the ones required to supply behavior when you use ReportBuilder dialogs to specify extension behavior; we didn’t want to take the chance that these weren’t available at runtime.\u00a0 We also explicitly instantiate\u00a0the one that replaced UpdateListener’s therm behavior for default runtime feedback. UpdateListener<\/a>\u00a0got replaced by fxTherm<\/a> in SP2 for some good reasons, which I’ll explain if anybody cares,\u00a0and we didn’t want that behavior to suddenly “go missing” in default output runs either.<\/p>\n

You can put other ones into the collection with impunity, and you can supply setup behavior that ensures yours are available in any number of ways — including, if you wish, extending the checkCollectionMembers method if you wish, with or without additional *class, *classlib, *module properties added to your subclass. It probably makes more sense to\u00a0simply set up the _oReportOutput collection of reportlisteners with the appropriate collection members at the beginning of your application.\u00a0 If you build design-time extension behavior, you can also ensure that any previews from the designer are preloaded with your collection members very easily.<\/p>\n

Read http:\/\/spacefold.com\/articles\/tmm\/ReportOutputApp<\/a>\u00a0and the original helpfile entry it extends, if you are unfamiliar with the idea of the cache.\u00a0 Read Colin’s article http:\/\/spacefold.com\/articles\/DataVizReports<\/a>\u00a0for step by step instructions if you are unfamiliar with\u00a0the idea of adding design-time controls into the builder (specifically the section on\u00a0Enabling the custom behavior by default <\/strong>will show you how the cache applies in this case). You could easily register behavior into your report\u00a0design environment that ensures the availability of\u00a0your decoration objects when the\u00a0designer is opened.\u00a0 Start here http:\/\/spacefold.com\/articles\/RSFundamentals-part1<\/a>\u00a0 if you are unfamiliar with the idea of registering new behavior elements into the Report Builder.<\/p>\n

Let’s\u00a0return\u00a0to our backstory.<\/p>\n

Each of the supported helper classes (which included, kind of late and clearly\u00a0very hastily<\/a>, gfxNoRender) have the own get* method, called by CheckCollectionMembers, precisely because the logic to decide when they are useful is different for each type. (This is covered in FxListener<\/a>. )<\/p>\n

For example, I really thought it was possible that the memberscript object might be useful even to a Successor (and I still do).\u00a0\u00a0But, generally speaking,\u00a0fx and gfx behavior is only supposed to be going on for the lead listener, the one attached to the internal report engine, not for Successors.<\/em><\/p>\n

This fact is pretty obvious if you look at fxListener’s SendFX method, which has the following call at the top:<\/p>\n

IF THIS<\/span>.IsSuccessor<\/span>
\n\u00a0\u00a0\u00a0\u00a0 <\/span>* Only the lead does this work.\u00a0\u00a0\u00a0\u00a0 <\/span>
\n\u00a0 <\/span>RETURN <\/span>m.liRenderBehavior<\/span>
\nENDIF <\/span><\/p>\n

 <\/p>\n

CheckCollectionMembers doesn’t have the same unilateral call at the top, just in case some collection objects are useful even in Successors.<\/p>\n

As I told Bo and Martin Haluza (http:\/\/www.eqeus.com\/<\/a>)\u00a0 this morning, I think that I should have put such a check at the top of fxListener.getNoRenderGFXobject(), and probably at the top of fxListener.getRotateGFXObject() as well.\u00a0 There is no earthly reason to check for the availability of, or the necessity to load, a gfx collection member in a Successor.\u00a0 Only the lead listener will\u00a0be decorating and certainly only the lead should be trying to write to the page using GDIPlus calls.\u00a0 (For one thing, the return value that determines whether the additional GDIPlus rendering will replace or add to the native rendering only makes sense in the lead listener, which is communicating with the engine.)<\/p>\n

Bo asked me “does this mean that a Successor\u00a0should not descend from FXListener?” And the answer is there is absolutely nothing wrong with a Successor\u00a0deriving from FXListener or one of its derived classes.\u00a0 The job of a Successor is to create extension output result types.\u00a0\u00a0The same\u00a0listener class\u00a0may do this sometimes as the lead (in which case it may also be decorating) and sometimes as a Successor (in which case it receives the benefit of the decorations, but is not in charge of creating them).<\/p>\n

The real-life scenario(s)<\/h3>\n

In fact,\u00a0Bo and Martin have a classic scenario that both illustrates this and manifests the bug:<\/p>\n

Bo has written a listener that he\u00a0uses (for some reason)\u00a0as the lead.<\/p>\n

I am not sure why that is, and I haven’t asked him. If\u00a0Bo is writing content decorations he could do the whole thing as fx and gfx objects and he shouldn’t care what listener “hosts” his decoration objects.\u00a0 But perhaps he is adding more value to fxListener in other ways… and you could see the bug even if he only creates fx and gfx objects… so just assume Bo’s listener, or your listener,\u00a0is the lead listener for some good reason… \u00a0Read on.<\/p>\n

Meanwhile Martin has written a listener, also derived from FXListener, that creates extension output.\u00a0 In fact, as you probably already know, he can chain many copies of his listener together as Successors, to create multiple forms of output (such as PDF, DOC, and HTML) in the same report run.<\/p>\n

The fact that Martin could chain many different copies of his own listener together for different forms of output should illustrate why you don’t need multiple listener classes contributed by different authors to see this problem.\u00a0 One of Martin’s fxListener-derived objects will function as lead, the others will be Successors.\u00a0 Read on.<\/p>\n

So now Martin’s Successor listener (as well as\u00a0the lead) gets a gfxNoRender helper object, and\u00a0gfxNoRender\u00a0does a LoadReport check to see if any NoRender instructions have been included in this FRX.<\/p>\n

gfxNoRender has to do this work in LoadReport if it wants to take advantage of SP2’s ability to change the contents of the FRX dynamically during the LoadReport event.\u00a0 (If you don’t already know about this, start here<\/a> and read the referenced docoids).\u00a0 Since\u00a0LoadReport\u00a0occurs before the engine has loaded up the contents of the FRX, gfxNoRender “peeks ahead” and opens the FRX temporarily at this point.\u00a0 It actually has to do a lot of work to do this, check to see if it’s a built-in FRX, etc.<\/p>\n

Unfortunately — and Bo identified this — the Successor doesn’t yet have the information it needs to get into the correct FRXDataSession. At the time I wrote this part of the _ReportListener code, I don’t even think we had<\/em> the correct FRXDataSession information in LoadReport, and I certainly knew that the engine-provided copy of the FRX\u00a0would not be available in it yet.\u00a0As a result\u00a0_ReportListener doesn’t do this until BeforeReport, and, Bo’s right, we should certainly do it earlier now.\u00a0 Arrgh #1.<\/p>\n

One point that Bo missed was that my matching reset of the Successor’s FRXDataSession in UnloadReport is there but it is not working correctly; the lead still has its FRXDataSession value filled out so the Successor’s isn’t get set back to -1, as it should.\u00a0 That’s arggh #2.<\/p>\n

But the thing that really had me gnashing my teeth (big arggh #3) here was… why is a Successor\u00a0even doing these checks?<\/em>\u00a0 Hence my suggesting that the get* methods for the supported collection members need to be fixed.<\/p>\n

So what happens now?<\/h3>\n

We’ve got\u00a0at least 3 things we’d like to fix here.<\/p>\n

You have some easy, and obvious, workarounds you can use in your derived classes right now, which you can implement without worrying that they will screw up anything later when your classes re-inherit from a newer version of FXListener:<\/p>\n