GNOME Bugzilla – Bug 524602
numbers go missing when you press '='
Last modified: 2008-07-22 15:59:28 UTC
Please describe the problem: If you add a lot of numbers together, the calculator will display a scroll bar in the 'output' field. If you press enter, the scrollbar vanishes, but the numbers will not display correctly - it looks as if the window is still scrolled. You can fix it by resizing the program Steps to reproduce: 1. type: 23+45+234+234+342+453+453+34534+345+345 - make sure that this goes past the boundary of the 'output' field 2. press '=' Actual results: Numbers vanish or are displayed off to the right of the field. This can be dangerous it can appear to be functioning correctly but be missing digits. Expected results: nothing unusual Does this happen every time? every Other information:
Confirmed. A workaround (albeit an ugly one) is to maximize the gcalctool window before entering calculations. I also wonder whether this is related to bug #482688
*** Bug 527768 has been marked as a duplicate of this bug. ***
We were scrolling further than maximum by not taking into account page size: http://library.gnome.org/devel/gtk/2.12/GtkAdjustment.html#gtk-adjustment-set-value Fixed in 2.22.2: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2076
Robert, I just pulled a fresh copy of gcalctool from trunk and can still reproduce this problem. Any idea what I'm doing wrong? Thanks!
Joan, what version of GTK+ do you have? Check the change is present in your local copy (see below) and if it still occurs after a make clean can you attach a screenshot please. I won't be back at my dev box for a few days but I'll have a look then. Confirmed the change is also on the trunk: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2077
Created attachment 109320 [details] screenshot request by Robert (In reply to comment #5) > what version of GTK+ do you have? Because I use Ubuntu Hardy (fully up-to-date), it was version 2.12.9. However, because I thought there might be a difference were I to very latest from trunk, it's now version 2.13.1. No difference. > Check the change is present in your local copy (see below) jd@gumby:~/gcalctool$ svn update At revision 2077. > and if it still occurs after a make clean Yup, still does. And not just after a make clean; I completely deleted my gcalctool svn dir and pulled a fresh copy of trunk just to be darned sure there weren't any old files mucking with things. > can you attach a screenshot please. Done. Three actually. The top screenshot was taken just before I pressed =. The middle was taken immediately after I pressed =. The bottom was taken after I enlarged the gcalctool window just a smidge. > I won't be back at my dev box for a few days but I'll have a look then. I do appreciate it. Now that I know the workaround (and have recovered from my last-minute-tax-pre-prep "where'd all my numbers go?!?" heart attack *grin*), I'm in no hurry. :-) Thanks Robert!
Hmmm, I can't reproduce this but I'm using GTK+ 2.12.0-1ubuntu3 (Ubuntu Gutsy). Reopening pending investigation in newer GTK+.
Upgraded to Hardy the other day and can reproduce also. The exact case is: 1) enter '123456789+123456789+123456789+123456789+123456789' 2) press enter The display is empty. Again it seems to be a GTK+ problem as if I change the justification to left justify there is no problem.
Created attachment 112695 [details] [review] Hack to prevent this happening. This really is an ugly bug. I found that by commenting out a section of code in ui_set_display() that I prevented the problem from happening. I'm not exactly sure what side-effect doing this has (it all looked the same to me), but if it's not too big a deal, I suggest making this change (or something similar) for the next gcalctool release on Monday.
> This really is an ugly bug. "ugly" is an understatement when you're doing last-minute preparation for your visit to your tax preparer and 12 months of figures disappear. ;-) I haven't used your patch long enough to comment on whether or not it's side-effect free, but it certainly does solve the reported problem. Thanks!
Thanks Joanie. Robert, note that I just #ifdef'ed out the code. If there really is no side-effect to this "fix", I suggest just removing the code. I also *strongly* suggest back-porting it to the last remaining gcalctool that's allowed for the GNOME 2.22.X series: 2.22.3 (due on 30th June). Thanks.
Unfortunately that code is required as this allows you to edit the display from the middle... To see type a number and then put the cursor in the middle and try and insert numbers. I've done some more work on GTK+ bug #482688 and can confirm this is a GTK+ problem. I have come up with a workaround though: http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2111 http://svn.gnome.org/viewvc/gcalctool?view=revision&revision=2112 Rich, Joan: Can you confirm this removes the problem for you? Note that we still get the right-hand digit not correctly aligned.
Ugh! :-) But it does seem to work nicely. Thanks for looking at this.
Released in 5.23.4, will be released in 5.22.3
*** Bug 538765 has been marked as a duplicate of this bug. ***
*** Bug 544142 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > Released in 5.23.4, will be released in 5.22.3 > I now have 2.23.4.1 installed and the bulk of the digits are hidden to the right. Thus a result of "259259256" is displayed as "25" with half of the 5 cut off.