Community
Participate
Working Groups
Build Identifier: I20110127-2034 I need to call the memory browser's performGo() method from my debugger plugin. The problem is that I need to get the selected memory space to pass to performGo() and there is no public method to get that information. Reproducible: Always
Created attachment 190996 [details] Added a public getMemorySpace() method
Accessing that class from a non-CDT plugin is not ideal. That's an implementation class, not a public interface. Unfortunately, there was no attempt to distinguish between internal and public code when that plugin was written. (In fact, I believe every method of every class in every plugin is qualified as public, giving new meaning to the term "Open Source"). Let me look at providing an API for letting other features tell the browser to go to a new address.
(In reply to comment #2) > (In fact, I believe every method of every class in every plugin is > qualified as public, giving new meaning to the term "Open Source"). Scratch that. I need a mid morning cup of coffee.
Created attachment 191009 [details] Fix I need to do some more testing, but this is what I've got. Norman, can you verify that this meets your needs and works in your environment? In addition to introducing a public interface, this allows the user to specify the memory space to be either (a) n/a or (b) whatever memory space is currently selected. There is a big difference between the two. Also, we want to update the UI controls (address bar and the memory selector) otherwise the view ends up in a misleading state. Programatically telling the browser to go to a location should have the same end result as if the user had done it from the GUI. Unfortunately, API freeze has to happen by M6, and the M6 build is going to happen 10 minutes from now. So the timing of this request is unfortunate. This will have to go in post-Indigo.
John, thanks for looking into this problem. I tried your patch and the go() method works great, but I still need a public API to get the selected memory space. I guess I should have mentioned this earlier but we get the selected memory space first and then let the user pick from a list of symbols in the selected memory space. After the user picks a symbol to go to, we call the go() method. Also, since you're working on a public API, any chance you could add selectRendering() from bug #339289 to the API? Our users want to be able to change the rendering of an existing tab, and would rather not have to create a new tab to see a new rendering.
(In reply to comment #5) > I tried your patch and the go() method works great, but I still need a public > API to get the selected memory space. I guess I should have mentioned this > earlier but we get the selected memory space first and then let the user pick > from a list of symbols in the selected memory space. After the user picks a > symbol to go to, we call the go() method. Hm. Are you enhancing your copy of the Memory Browser or is this activity happening external to the view? > Also, since you're working on a public API, any chance you could add > selectRendering() from bug #339289 to the API? Our users want to be able to > change the rendering of an existing tab, and would rather not have to create a > new tab to see a new rendering. I'll take a look at the bug and comment there.
(In reply to comment #6) > Hm. Are you enhancing your copy of the Memory Browser or is this activity > happening external to the view? The latter. We're adding toolbar buttons and context menus from our debugger plugin.
Created attachment 191023 [details] fix
I tried the latest patch and it looks good. Thanks!
*** Bug 355431 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > I tried the latest patch and it looks good. Thanks! Norman & John, Did you test it when the Memory Browser is not yet opened? I invoked IWorkbenchWindow.getActivePage().showView to open Memory Browser and then call memoryBorwser.go() immediately. There is a chance that the updateTab() is not completely done when go() is running. When fStackLayout.topControl is still not a tabFolder, performGo() will not do anything. This is just a timing issue. Also, do we allow people to call Go() from a non-UI thread?
(In reply to comment #11) > Norman & John, > > Did you test it when the Memory Browser is not yet opened? I invoked > IWorkbenchWindow.getActivePage().showView to open Memory Browser and then call > memoryBorwser.go() immediately. There is a chance that the updateTab() is not > completely done when go() is running. When fStackLayout.topControl is still not > a tabFolder, performGo() will not do anything. This is just a timing issue. In my patch for bug 317749, I call showView() to open the memory browser and then I call go() from the UI thread. I didn't test the case in which you call showView() and then call go() immediately. I assume you're doing both from the UI thread? > Also, do we allow people to call Go() from a non-UI thread? go() updates the memory browser UI so I think it should be called from the UI thread.
(In reply to comment #12) > (In reply to comment #11) > > Norman & John, > > > > Did you test it when the Memory Browser is not yet opened? I invoked > > IWorkbenchWindow.getActivePage().showView to open Memory Browser and then call > > memoryBorwser.go() immediately. There is a chance that the updateTab() is not > > completely done when go() is running. When fStackLayout.topControl is still not > > a tabFolder, performGo() will not do anything. This is just a timing issue. > In my patch for bug 317749, I call showView() to open the memory browser and > then I call go() from the UI thread. I didn't test the case in which you call > showView() and then call go() immediately. I assume you're doing both from the > UI thread? This is what happened in my test: 1. Ensure that Memory Browser is not opened. Call showView() in the UI thread and then call go() immediately in the UI thread as well. 2. When Memory Browser starts, MemoryBrowser.createPartControl() calls handleDebugContextChanged() to get the IMemorySpaceAwareMemoryBlockRetrieval from another thread. When this thread is done, it calls updateTab to do a lot of things in the UI thread including setting fStackLayout.topControl to a tabFolder. If go() is invoked before all of these are done, it is possible that fStackLayout.topControl is set to null and then performGo() will exit without doing anything. This is a timing issue.
(In reply to comment #9) > I tried the latest patch and it looks good. Thanks! John, will this be applied soon? Please also check the timing issue I mentioned.
Sorry. I've been out of pocket for a while, but am returning to the front line shortly. I'll return to this issue early next week.
Created attachment 204911 [details] fix Adds new method for getting the active memory retrieval object. Can be used to solve the timing issue noted in comment # 11
(In reply to comment #14) > (In reply to comment #9) > > I tried the latest patch and it looks good. Thanks! > > John, will this be applied soon? Please also check the timing issue I > mentioned. Lee, trying to do a go() immediately after opening the view programatically will indeed require some special logic. As you noted, the view cannot fully initialize itself synchronously during the creation of the part. We need to find out what memory spaces are available before we can populate the memory space selector; in a DSF session, that's an async operation. However, I've done two things that will support your scenario. First, I've added a new method to the proposed IMemoryBrowser interface for getting the active memory retrieval object. Secondly, I've documented the go() method to reflect that it's a no-op if there is no active memory retrieval object. You thus can write logic that can spin until the browser has an active retrieval object (hopefully not in the GUI thread, and hopefully not without some minimal sleep to allow other threads to breath, and hopefully not without some timeout). I coded an example action that opens the view and sets the expression and its working well for me. It's non-trivial in that the IMemoryBrowser methods must be called on the GUI thread (this was documented in my first path, BTW), but you don't want to spin on the GUI thread. That said, it's not rocket science nor a ton of code.
(In reply to comment #17) > Lee, trying to do a go() immediately after opening the view programatically > will indeed require some special logic. As you noted, the view cannot fully > initialize itself synchronously during the creation of the part. We need to > find out what memory spaces are available before we can populate the memory > space selector; in a DSF session, that's an async operation. > However, I've done two things that will support your scenario. First, I've > added a new method to the proposed IMemoryBrowser interface for getting the > active memory retrieval object. Secondly, I've documented the go() method to > reflect that it's a no-op if there is no active memory retrieval object. You > thus can write logic that can spin until the browser has an active retrieval > object (hopefully not in the GUI thread, and hopefully not without some minimal > sleep to allow other threads to breath, and hopefully not without some > timeout). I coded an example action that opens the view and sets the expression > and its working well for me. It's non-trivial in that the IMemoryBrowser > methods must be called on the GUI thread (this was documented in my first path, > BTW), but you don't want to spin on the GUI thread. That said, it's not rocket > science nor a ton of code. This looks good to me. Could you apply this to the head so it can be picked up in the next update?
(In reply to comment #18) > This looks good to me. Could you apply this to the head so it can be picked up > in the next update? Will do very soon.
Created attachment 205240 [details] fix Last patch was missing new file
*** cdt git genie on behalf of U-bobgato\cortell *** Bug 339708 - [Memory Browser] Need a public method for getting selected memory space [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=e453c2257d80c878c00729d7f17aad0b7280ed1f
John It looks like you did all this work, but did not complete the bugzilla record keeping. Am I correct. If so I can take care of it. Randy
(In reply to Randy Rohrbach from comment #22) > John > > It looks like you did all this work, but did not complete the bugzilla > record keeping. Am I correct. If so I can take care of it. > > Randy Looks like this was fixed a while back.
