Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 312098

Summary: [Memory Browser] do not create a rendering automatically when Memory Browser is opened
Product: [Tools] CDT Reporter: Alain Lee <a-lee>
Component: cdt-memoryAssignee: Randy Rohrbach <Randy.Rohrbach>
Status: RESOLVED FIXED QA Contact: Ted Williams <ted>
Severity: normal    
Priority: P3 CC: john.cortell, Randy.Rohrbach, teodor.madan
Version: 7.0Flags: john.cortell: review+
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Proposed fix
none
Snapshot with initial state of MemoryBrowser
none
Invalid expression decoration
none
Updated patch which recreates Teodors original patch on top of John Cortel's changes
none
Fix regression to memory space support.
john.cortell: iplog-
Externalize String fix
john.cortell: iplog-
Took Teodor patch and cleaned it up a little. none

Description Alain Lee CLA 2010-05-07 12:28:41 EDT
When a valid debug context is selected, Memory Browser automatically creates a rendering and display data from address 0x00. Could we disable this? Based on our experience when testing with our TI specific products, this could hang the device when memory for certain addresses are inaccessible. Could we also disable the New Tab button until an expression is entered or until there is at least one tab item there?
Comment 1 Teodor Madan CLA 2010-05-10 06:15:30 EDT
Created attachment 167679 [details]
Proposed fix

The attached patch addresses the following issues:
- Do not create rendering to any default address (including "0x0"). 
- User is required to enter an expression before rendering is created

Other improvements is to add text field decorators to:
  * suggest to user to enter an expression in order to position the rendering
  * add error decoration when entered expression is invalid
Comment 2 Teodor Madan CLA 2010-05-10 06:21:38 EDT
Also another change is to disable "Go" and "New Tab" for empty expression. 

I have attached screen shots with the new decoration reflecting different states of MemoryBrowser
Comment 3 Teodor Madan CLA 2010-05-10 06:25:25 EDT
Created attachment 167680 [details]
Snapshot with initial state of MemoryBrowser
Comment 4 Teodor Madan CLA 2010-05-10 06:26:04 EDT
Created attachment 167681 [details]
Invalid expression decoration
Comment 5 Alain Lee CLA 2010-05-10 15:16:22 EDT
The proposed fix should be able to fulfill our requirement.
Comment 6 Randy Rohrbach CLA 2010-05-11 11:41:48 EDT
I have tried this patch out and I really like it. We have reported issues when bringing up the memory browser trying to access illegal memory ( 0 is not always real ).

This makes this work better. We have also seen issues in our product when disconnecting, when there are no longer valid connections the view would still be trying to access 0 and fail. Generating failed request which are logged.

Unless I find something, I intend to apply this patch to MAIN and perhaps to the 6.0.x branch for our older products.

Randy
Comment 7 Randy Rohrbach CLA 2010-05-11 11:42:34 EDT
I have tried this patch out and I really like it. We have reported issues when bringing up the memory browser trying to access illegal memory ( 0 is not always real ).

This makes this work better. We have also seen issues in our product when disconnecting, when there are no longer valid connections the view would still be trying to access 0 and fail. Generating failed request which are logged.

Unless I find something, I intend to apply this patch to MAIN and perhaps to the 6.0.x branch for our older products.

Randy
Comment 8 Randy Rohrbach CLA 2010-05-15 23:18:09 EDT
Created attachment 168643 [details]
Updated patch which recreates Teodors original patch on top of John Cortel's changes

I reapplied by hand the edits from teodor's original patch on top of John Cortel's changes ( which were massive and in many of the same areas ).

Randy
Comment 9 Randy Rohrbach CLA 2010-05-15 23:19:50 EDT
I have tested the reapplied changes from Teodor's patch and it seems as stable as before.

So I am going to apply it.

Randy
Comment 10 Randy Rohrbach CLA 2010-05-15 23:21:53 EDT
I applied the re-edited patch. 

John please review.

Thanks

Randy
Comment 11 John Cortell CLA 2010-05-17 14:53:30 EDT
Cool improvement. Some monitor comments...

1. Why is the DEC_REQUIRED center-left but the DEC_ERROR top-left? It would be nice if they were consistently placed given they're mutually exclusive.

2. The description text for DEC_REQUIRED should come from a properties file, not hard-coded in the code.

3. I think the DEC_REQUIRED messages should just be "Enter an expression". The "to position renderings" seems at best unnecessary, but more likely outright confusing.

4. Formatting in the code needs some improvement. The following is both ugly and unorthodox.

   fieldDecoration = FieldDecorationRegistry.getDefault()
   .getFieldDecoration(FieldDecorationRegistry.DEC_ERROR);

If you split a line like this, the second part should be indented (preferably by two tabs).

5. The value of clearError() is questionable. I think the code would be clearer if it just called fWrongExpression.hide()
Comment 12 John Cortell CLA 2010-05-17 16:00:27 EDT
Created attachment 168813 [details]
Fix regression to memory space support.

I gave the latest changes a run with the memory space support active, and found out the new logic broke the memory space support. Basically, the comobox for selecting the memory spaces isn't show up. It was easy to fix, though. Also, I fixed the fact that the goto field showed up indented even when the memory spaces widget was hidden.

Committed to HEAD. Randy, feel free to review this if you like, but it's really just an adjustment to the code I added via bug # 309032.
Comment 13 Teodor Madan CLA 2010-05-18 13:30:22 EDT
Created attachment 168975 [details]
Externalize String fix

Patch addresses:
1)code formatting
2)non-externalization string and the suggested message for DEC_REQUIRED
Comment 14 Teodor Madan CLA 2010-05-18 13:35:58 EDT
(In reply to comment #11)
> Cool improvement. Some monitor comments...
> 
> 1. Why is the DEC_REQUIRED center-left but the DEC_ERROR top-left? It would be
> nice if they were consistently placed given they're mutually exclusive.

Though the decorators are mutually exclusive, these are the places I would expect to see them. i.e. for a hint of mandatory field to enter usually the decorator is position in the middle of the field. Also the errors are usually placed on top corner. 

> 
> 5. The value of clearError() is questionable. I think the code would be clearer
> if it just called fWrongExpression.hide()

The idea was that clearing of error is done from multiple places (e.g. when user starts typing), this would localize eventual changes to decide the error presentation changes.
Comment 15 John Cortell CLA 2010-05-28 11:32:14 EDT
> > 5. The value of clearError() is questionable. I think the code would be clearer
> > if it just called fWrongExpression.hide()
> 
> The idea was that clearing of error is done from multiple places (e.g. when
> user starts typing), this would localize eventual changes to decide the error
> presentation changes.

Then you would equally want to abstract the *setting* of the error. Basically, the following method is awkward given that clearError() simply manipulates fWrongExpression. One can go either way with this...remove clearError() or add a setError(...) method. It doesn't matter to me which. I'm just hoping for consistency.

   public void handleExpressionStatus(final IStatus message) {
      if (message.isOK()) {
         clearError();
      } else {
         fWrongExpression.setDescriptionText(message.getMessage());
         fWrongExpression.show();
      }
   }
Comment 16 John Cortell CLA 2010-05-28 11:39:20 EDT
Randy, you have not responded to or addressed the issues I brought up.
Comment 17 Randy Rohrbach CLA 2010-06-01 15:57:30 EDT
OK, I updated the code to be consistent.

I took out the clearError() routine. That is the style I like better.

Randy
Comment 18 John Cortell CLA 2010-06-01 16:13:47 EDT
(In reply to comment #17)
> OK, I updated the code to be consistent.
> 
> I took out the clearError() routine. That is the style I like better.
> 
> Randy

That addresses issue 5 only. 2, 3 and 4 are still relevant (Teo provided a justification for 1).
Comment 19 Randy Rohrbach CLA 2010-06-01 17:01:50 EDT
John

  OK, Sorry for going to fast. I'll look at the other issues.

Randy
Comment 20 Randy Rohrbach CLA 2010-06-01 18:30:05 EDT
Created attachment 170720 [details]
Took Teodor patch and cleaned it up a little.
Comment 21 Randy Rohrbach CLA 2010-06-01 18:31:15 EDT
John

   I have applied the patches/changes from Teodor and myself. I think
   this addresses all of the issues you had.

Randy
Comment 22 John Cortell CLA 2010-06-01 18:37:56 EDT
(In reply to comment #21)
>    I have applied the patches/changes from Teodor and myself. I think
>    this addresses all of the issues you had.

Yep. It does. Thanks!
Comment 23 CDT Genie CLA 2010-07-28 15:27:54 EDT
*** cdt cvs genie on behalf of jcortell ***
Bug 312098: do not create a rendering automatically when Memory Browser is opened (fixed regression to memory space support)

[*] MemoryBrowser.java 1.23 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/memory/org.eclipse.cdt.debug.ui.memory.memorybrowser/src/org/eclipse/cdt/debug/ui/memory/memorybrowser/MemoryBrowser.java?root=Tools_Project&r1=1.22&r2=1.23