Community
Participate
Working Groups
Build Identifier: 20110929 There is no Stereotype search in RBD. Do a kind of Stereotype search, some delegate data will be returned as results. But I searched help, stereotype does not include delegate types. Reproducible: Always Steps to Reproduce: 1. Import PI from attatchment. 2. Select MainProject first. Go to EGL search wizard, set Search string as "*", Search for as "Stereotype", Limit To as "References", Scope as "Selected resources", then click search button. Actual results: There are some delegate types found in search results. But from the help doc, they should not be strereotype.
Created attachment 204346 [details] PI
Created attachment 204347 [details] screenshot
Seems Delegate is also a kind of Stereotype; Paul, can you explain this? thanks
While search and indexing are not really my strong points, I did spend a little while trying to understand what is going on here. I created this small testcase to demonstrate what looks like 1 problem: delegate del1() end externaltype prhObject type javascriptobject delegate1 del1?{@Property{getMethod = "getDelegate1", setMethod = "setDelegate1"}}; end library lib1 prh prhobject; function f1() prh.delegate1(); lib1.f2(); end function f2() end end When i search for stereotypes, it flags the reference to prh.delegate1() as a possible match. This is because, in MatchVisitor.endVisit(FunctionInvocation), when a delegate is invoked, the code falls through to 471 (if invoking a function, this visit method returns on line 467). Because of this, it is asking the pattern (in this case a PartReferencePattern) to getMatchingLevel(). The PartReferencePattern simply checks to see if the node is a Name, and if so, it checks that name against the search string (in this case *). So the pattern believes that this is a reference to a part. Interestingly enough, the same search result is returned if I search for ANY part type (Program, Handler, Interface, etc). These searches all return the delegate reference as a result. This is because these searches all use the same PartReferencePattern. I think error lies in the MatchVisitor.endVisit(FunctionInvocation) method (perhaps this should stop processing if the invocation is a delegate, since the delegate will always be a variable, and should really not be found by any search...as we do not have a variable search).
Paul, thanks a lot for your comment, I will research it based on your comment
fix it
Verified in build of 20111027
