Phil, thanks for your response.. Thanks Misi & Pat for your responses so far too..
@ Phil: Interesting.. I’ll look through.. Is it a bug that needs to be addressed by MS on IE or is it a ‘feature’ on IE that needs to be addressed from the MT application side? @ Pat: I haven’t had the time enough to test it on other browsers, but I do intend to when I have a little more time. The null pointer happens on the last row only which actually should not have been there if the refresh happened correctly. On rows below the modified record, the pointer moved one row down meaning if record n was clicked, record n+1 would actually open. Like in the example below, if record 3 was clicked after the modification of record 3, 4 would open instead of 3. It works normally only when the fields are not resized.. Joe From: Murnane, Phil Sent: Monday, March 19, 2012 2:24 PM Newsgroups: public.remedy.arsystem.general To: arslist@ARSLIST.ORG Subject: Re: Extremely strange bug related to table field refresh.. ** Joe: IIRC, Doug Mueller mentioned that IE9 had a quirk or two and that some help could be had by editing a .properties(?) or a .css(?) file. Maybe search a bit through the archives? --Phil From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of patchsk Sent: Monday, March 19, 2012 14:10 To: arslist@ARSLIST.ORG Subject: Re: Extremely strange bug related to table field refresh.. ** I just tested on firefox 11 and IE 8, could not reproduce the defect even after resizing the columns. It just worked as supposed to. Upon refresh it just cleared that row. Without refresh if I double click on the ticket once resolved it just opened incident screen without null pointer. On Monday, March 19, 2012 11:37:09 AM UTC-5, Joe Martin D'Souza wrote: ** I am on ARS 7.6.03. And I just found what got to be one of the most bizarre bugs I have uncovered in the past few days.. There may not be a short way to describe this problem so here goes.. I have tested this bug on the Overview Console, of the ITSM applications (7.6.03 again), so that table field would be the ideal candidate if you want to reproduce it. I have only tested this on the Mid-Tier client. Lets say for example sake, there are 4 entries displayed on the table field on the Overview Console.. INC000000000001 INC000000000002 INC000000000003 INC000000000004 Lets say I double click on INC000000000003 to open it and mark that incident as Resolved. And when I get back to that overview console, I either right click on that table field and select Refresh OR I press the Refresh button on top of the overview console table to refresh the table field.. Expected Results: The table field refreshes and now you are left with INC000000000001 INC000000000002 INC000000000004 Great.. works as expected. The Bug: UNLESS, prior to double clicking on INC000000000003, the columns on the table field are resized.. I had resized almost all the columns from the mid-tier client, and then double clicked on INC000000000003 to open it. I then marked that incident as Resolved and closed that window after saving it. And then refreshed the table field on the Overview Console. All the previous 4 entries are still displayed as below.. INC000000000001 INC000000000002 INC000000000003 INC000000000004 HOWEVER, now when I double click on INC000000000003, the details of INC000000000004 is displayed on the new opened window.. AND if I click on INC000000000004, I get a null pointer exception... This happens when I resize the table fields widths on the mid-tier client.. I haven’t tested this on the native User client but I think from past experience, it has no problems.. I’m pretty certain it works as expected on the User Client under both the circumstances described above... Joe PS: Could someone verify if this bug still exists on 7.6.04 or if it exists on earlier versions? Another PS: This could be a potentially serious bug – I nearly closed the wrong ticket in a real world scenario. It’s a good thing I saw the ticket details before closing it, else if I had mechanically gone through the motions, I may have closed a wrong ticket.. What happened was after double clicking on INC000000000003, and seeing the status still on Pending, I thought maybe I had forgotten to save. So I tried to set it on Resolved and just before committing a save, noticed that it was not INC000000000003 but INC000000000004 that was opened up.. I would have accidentally ended up closing INC000000000004 too.. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"