Event handler of inbound plug not called when plug fired by event handler

Question

Hello All,
I have a rather bizzare problem, hopefully someone out there can figure out what is going on, as I'm rather stumped.
I have 2 views, A and B. They are linked by plugs, InA, InB, OutToA, OutToB. OutToB is linked to InB from A to B, OutToA is linked to InA from B to A.
There is an onActionLink in view A. Clicking on this triggers an action which calls the wdFirePlugOutToB method.
In view B some handling is done in the method onPlugInB, then wdFirePlugOutToA is called to change the displayed view back to A.
As far as the user is concerned they don't ever see view B. (this bit works perfectly!)
Now also in view A I have an event handler which handles a event from the component controller. It also calls wdFirePlugOutToB.
If I trigger an event in the component controller this event handler is called and the method called. However, when I put a breakpoint in the onPlugInB, flow never reaches here. Flow does get to the wdDoModifyView of view B but never to the inbound plug event handler.
Any suggestions as to what I might need to do? I would have thought calling the wdFirePlugOutToB method would ALWAYS trigger the linked event handler onPlugInB.
I am running NW04 SP18.
Thanks!

Answer 1

Hi Bharathwaj,
The project I'm working on has a requirement to allow for a road-mapped process (FPM) which has one step in which multiple screens can be accessed. I'll give an example: A user in step A selects the cost centre that they want to work with, in step B they need to maintain several pages of information about this cost centre. The do not want to break this information into steps, as there is no logical progression from one step to the next, and it may well be that the user wishes to go from maintaining screen 1 to screen 3, and then screen 2, and then screen 4. Stepping between all screens (1->2->3->2->3->4) wastes time and is not very user friendly. Step C of the process confirms the data that the user entered in step B, and Step D is the validation that the changes have been committed to the database. (a very familar 4 step process for those using ESS).
To allow for this requirement, I have designed a left navigation pane type screen. links appear on the left of the screen and the user can use these to navigate between different screens (implemented as FPM IVAC VCs) on the right of the screen.
It is quite an elegant solution (even if I do say so myself although quite complex to implement. I have relied very heavily on reading the code SAP put together for the FPM. The most complex part is that in order to update the the content of view containers in an application you must trigger a web dynpro view navigation by firing a plug to a different view.
Unfortunately I don't have any sample application code, only the finished product, which I can't really share. But I can say that if you look at the FPM code carefully, working from where the wdInit of the FPM is called, it will eventually make sense.
One thing I found slightly frustrating, you can't use the FPM's component usage register (FPM method attachComponentUsage(IWDComponent, IWDComponentUsage)) to add a VC... darned inconvienient really (you'd think that the web dynpro framework could have implemented the concept of extending an interface, but the IBLC and IVAC interfaces are different! - even though the IVAC is just IBLC + a few methods), but then again you can manage the instantiation of the used VC yourself and call the onInit method of the VC passing the current fpm reference, to attach it to a common FC, and given that you should be sharing context through the FC and never the VC, then really this isn't too much of an issue. (I spent ages worrying that I couldn't add the instances of the VC that I was using within my navigation pane VC to the fpm instance list, until I realised that it really didn't matter!)
One day - when I have time (yeah right!) I might put together a blog about this sort of stuff, in the meantime, it keeps me plenty busy enough not to have the time!
Hope this helped in some small way,
Cheers,
Chris