Community
Participate
Working Groups
Build Identifier: 3.6 I20100608-0911 This is a regression from 3.4.2 to 3.6. It persists in 3.6.1. If the user has hidden the Memory view, or the view is not open, when he "monitors memory" the view does not show the new memory monitor in the tree. You can select the memory from the "Switch memory monitor" drop-down button. But even after you do that, it still won't show up in the tree. If you hid the Memory view, and open it again, the new monitor will be shown in the tree, but not selected. This behaviour is very confusing to users. Expected behaviour: Behaviour of the Memory view when a memory monitor is added, should be the same regardless of whether the view is visible, hidden, or closed. The behaviour when it is visible, is correct. Reproducible: Always Steps to Reproduce: 1. Hide or close the Memory view 2. add a new monitor
I enhanced the PDA example debugger with an action to add a memory block, and it works for me when the view is hidden, closed, or visible. I'm calling org.eclipse.debug.core.IMemoryBlockManager.addMemoryBlocks(IMemoryBlock[]). What API is your action using to register the memory block?
we are also calling: org.eclipse.debug.core.IMemoryBlockManager.addMemoryBlocks(IMemoryBlock[]) then we create a rendering, initialize it and call: org.eclipse.debug.ui.memory.IMemoryRenderingContainer.addMemoryRendering(IMemoryRendering)
This also works for me. Perhaps Samantha can shed more light on the API used to create/add a rendering. I was able to create and show a rendering using the following code - but I don't recall how one is supposed to obtain a rendering container (and know which one it is). I noticed that the memory monitor tree implements the IMemoryRenderingContainer, but it does nothing with renderings. My sample code does this: IMemoryBlock block = target.getMemoryBlock(0, 1024); DebugPlugin.getDefault().getMemoryBlockManager().addMemoryBlocks(new IMemoryBlock[]{block}); IViewPart view = DebugUIPlugin.getDefault().getWorkbench().getActiveWorkbenchWindow().getActivePage().findView(IDebugUIConstants.ID_MEMORY_VIEW); if (view != null) { if (view instanceof IMemoryRenderingSite) { IMemoryRenderingManager manager = DebugUITools.getMemoryRenderingManager(); IMemoryRenderingType[] types = manager.getDefaultRenderingTypes(block); IMemoryRendering rendering; try { rendering = types[0].createRendering(); IMemoryRenderingSite site = (IMemoryRenderingSite) view; IMemoryRenderingContainer[] containers = site.getMemoryRenderingContainers(); rendering.init(containers[2], block); containers[2].addMemoryRendering(rendering); } catch (CoreException e) { e.printStackTrace(); } } }
our code works fine too when we do a: org.eclipse.ui.IWorkbenchPage.findView(String) to get the Memory view, add the monitor, then do a: org.eclipse.ui.IWorkbenchPage.showView(String) with 3.4, it worked fine when we just did the org.eclipse.ui.IWorkbenchPage.showView(String) first, then added the monitor and rendering to that we use showView, because findView returns null when the view is closed and then we have to do showView anyway (which demonstrates the same problem) though I do notice that you're doing the findView after addMemoryBlocks we were doing that before then ... yes - if I add the block before getting the view it works is that how it should always be done? were we just getting lucky with 3.4?
The signature of org.eclipse.debug.internal.ui.viewers.model.ModelContentProvider.updateNodes(IModelDelta[], int) changed in 3.6 - the "int" (mask) parameter was added to the method, and the subclass MemoryViewTreeModelContentProvider was not updated. Thus, it's implementation of updateNodes(IModelDelta[] nodes) was not being called.
Created attachment 179663 [details] patch
Released to 3.6.2. Fixed.
Tested with CDt and it seems kosher now.
