Community
Participate
Working Groups
I've received the following enhancement request from one of our users... In the memory view, the address row (first row) is fixed. Scrolling up/down keeps this row as the first. The same functionality should occur with the address column. That is, scrolling left/right should keep the address column as the first column. Also the address column should have a solid background to distinguish it from the actual data. With this improvement the specific address for a memory cell is easier to determine.
Assigning to Samantha for consideration.
The Memory View makes use of the Table SWT widget to display a memory block. The table widget does not currently support for row headers. I cannot implement this enhancement until the table widget implement this feature. This is the enhancement request in SWT: https://bugs.eclipse.org/bugs/show_bug.cgi?id=79727 I will monitor this swt bug and will implement this feature once I get the proper support.
As you might imagine, it is easy to get disoriented in the table renderings once the address column is scrolled out of view, which is usual when addressable units are larger than 8-bits. Perhaps, while we wait for support from the SWT folk to implement the locking columns, we could the display the address in hover text. BTW, is there currently (in Eclipse 3.1) any way to extend the built-in table renderings to provide hover text? That is, can I do it myself as a plug-in developer?
Hi Ken - That's a good idea, having a hover shows the address of a cell. In 3.1, there is no easy way for a plugin developer to create hover support in a table rendering without referencing to internal classes. AbstractTableRendering does not have any API for clients to figure out where a mouse point is located from a hover event. As a result, if you want to provide hover support for this, you would have to reference to internal classes and calculate where the mouse is located when hover happens. I am going to add an enhancement request to support hover for 3.2. In the meantime, if you really want to provide hover support, try the following: 1. subclass from AbstractTableRendering 2. override createControl 3. After the control is created, create the hover control on the table. 4. To pop up the hover control on the table, your code needs to listen for mouseTrack events on the table control. (#table.addMouseTrackListener(...) 5. Then your mouse track listener needs to handle the hover event. The tricky part is to figure out where the mouse is located when the hover event happens. The event will provide you with the Table widget and the point location of the hover. From the point location, you need to go through the table and find the correct table element. From the table element, you can call #TableItem.getData() to get to TableRenderingLine (This is an internal class, and I do not recommend you referencing to it as it may change in the future. :) From the TableRenderingLine, you can find the row address. Then, you can use that to calculate the address of the cell using your mouse point. Hope this helps... Samantha
Reopen for 3.2.
Hi Ken - I have added hover support for 3.2. Please let me know if it is sufficient in solving your problem. https://bugs.eclipse.org/bugs/show_bug.cgi?id=106567 If you still require header column, I will have to defer until the table widget provides the support. Thanks... Samantha
I still think a header column would be the ideal solution, but I also understand how difficult it would be to implement without support in the SWT components. So I'd say your solution to Bug 106567 is a reasonable and welcome compromise for the time being. Perhaps we should add Bug 79727, the SWT enhancement, to the 'depends on' list and wait for the SWT folks to decide what they are going to do.
Sounds good, will do. In the meantime, I will defer this bug. Thanks... Samantha
reopening
Unable to implement without proper SWT support.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
