Friday, April 17, 2009

Another Bug Fix Part 2

This part describes my process for fixing the bug.

As I mentioned in part 1 I believed that the problem simply came down to refreshing the UI after the parts list was updated. So the questions I needed to answer were: where could I find the UI refresh method and where could I call it that would make the most sense?

Answering the first question was simple enough. After some light searching I came across the class. This class was responsible for generating the UI for the Extension Details section. In this class was a refresh() method. Perfect.

As for the answer to the second question, this was also easy enough. I simply needed to find out where the "Specify Parts" dialog was being initiated and include a call to refresh() after that.

After looking at the code for awhile trying to understand it, I came across a few lines that interested me located within a method called createButtonControl().

Button button = new Button(composite, SWT.NONE);
GridData gridData = new GridData();
gridData.heightHint = 17;
button.setData(ITEM_DATA, item);
button.setData(EDITOR_CONFIGURATION_DATA, configuration);

I thought this might be the button I was looking for (the one that opens up the Specify Parts dialog). I tested it by setting the button's text to something different and sure enough it changed, so I knew that this was the right button.

I took note of the addSelectionListener() call, as the listener that was passed was most likely what opens the dialog. The internalControlListener was an instance of the InternalControlListener class, the contents of which were actually defined inside Looking at the class, I came across a method called widgetSelected()

public void widgetSelected(SelectionEvent e)
   // for button controls we handle selection events
   Object item = e.widget.getData(EDITOR_CONFIGURATION_DATA);
   if (item == null)
      item = e.widget.getData(ITEM_DATA);
   if (item instanceof DialogNodeEditorConfiguration)
      DialogNodeEditorConfiguration dialogNodeEditorConfiguration = (DialogNodeEditorConfiguration)item;
   else if (item instanceof ExtensionItem)
      applyEdit((ExtensionItem)item, e.widget);

I took notice of the if statement that checks if the item is an instanceof DialogNodeEditorConfiguration. I suspected that it was here that the Specify Parts dialog was called. So I put a breakpoint on the invokeDialog() call and traced it. Sure enough, when I clicked on the "..." button I was stopped at this call. I stepped through it and ended up at a class called which was responsible for creating the Specify Parts UI. So I knew then for sure that this line is what started the whole process. To test my original theory I inserted a call to refresh() right below the invokeDialog() call and ran the application. As I suspected, the UI was now fixed! After updating the parts and clicking OK in the Specify Parts dialog, the text in the parts field changed without me having to change focus.

You can find my patch on Bugzilla.

Another Bug Fix Part 1

I had mentioned earlier that this bug seemed a little more complicated. As it turns out, the fix was equally as simple as the previous bug.

Since I haven't given much detail on this bug yet I'll divide this post into 2 parts. The first part will be about re-creating the bug, the second part will describe how I fixed it.

As you may recall from my previous posts, the last bug I worked on dealt with the extensions tab of the WSDL editor. This bug deals with the same area of the UI, however unlike the previous bug this one is related to the Extension Details section rather than the Extensions tree list.

The problem in this section related to one attribute known as "parts." Parts seems to be a list of objects that makes up the soap:body extension. As you can see in the image below, the soap:body of the example WSDL I created has 2 parts, "parameters" and "NewPart"

At first nothing seems wrong with this scenario. However, to find the bug we have to click on the Button next to the parts field labeled "..." which pops up the "Specify Parts" dialog.

Next, I unchecked NewPart and clicked OK. Now we can see the problem. In the image below, notice that the parts field still displays "parameters NewPart". The NewPart is still included as a part according to the UI.

Now, as you can see the focus has been lost from the soap:body extension. I re-clicked it, and the results are below.

Now the parts field simply displays "parameters". The UI is now behaving correctly. The fact that there wasn't any actual problem updating the parts list told me that the problem was simply the UI not updating after the parts list was updated. The fact that the UI fixed itself after I changed focus back to soap:body told me that the UI perhaps just needed to be refreshed. I'll describe my fix in Part 2.

Friday, April 10, 2009

Update, New Bug

It's been awhile since my last update. Unfortunately some other courses of mine have taken up much of my time and I've had to put Eclipse on the backburner.

My previous bug still hasn't been reviewed it seems, so I'm still waiting on that and I hope I get some feedback soon.

In the meantime, I figured it didn't make alot of sense to end my semester with one bug completed a few weeks early, so I decided to take a look at Bug 235381 to see if there was any work I could do on that.

Although I didn't find a lot of time to look at it in-depth, I quickly noticed that the code for the "Parts" attribute seems quite a bit more complicated than the Delete button from the previous bug. The code to populate, modify and display this list spans across a bunch of files and it was hard to determine where exactly the problem was. While at first glance it simply seems like a UI refresh problem, it might actually be more complicated than that. I will go into further detail early next week and hopefully make some sort of progress on this.