I previously posted about a ComboBox not displaying on one client's
computer, but displaying on all other computers. I wrote some code to log all message sends to the FramingConstraints object. I am posting a text file that contains the results of the program running on my machine where it displays properly, and the client's machine where the ComboBox does not display. The obvious issue seems to be where a fractional value becomes a zero. For orientation purposes the logging starts in FramingLayout<<layoutContainer: and then goes into various methods in FramingConstraints. The log file can be downloaded here (~2.9k) http://www.mitchellscientific.com/smalltalk/temp/FramingComboProblem.txt I wonder how the fraction is becoming zero, only on this one machine. I wonder if something odd is happening in STB or if something about this machine is causing it to not handle fractions well. I don't think it should have to do any parsing of them to load from STB. Any ideas? I will try making the fraction a Float. However it would be nice to have an understanding of the real problem. Chris |
"Christopher J. Demers" <[hidden email]> wrote in
message news:bh942b$v55kh$[hidden email]... > I previously posted about a ComboBox not displaying on one client's > computer, but displaying on all other computers. I wrote some code to log > all message sends to the FramingConstraints object. I am posting a text > file that contains the results of the program running on my machine where it > displays properly, and the client's machine where the ComboBox does not > display. The obvious issue seems to be where a fractional value becomes a > zero. > > For orientation purposes the logging starts in > FramingLayout<<layoutContainer: and then goes into various methods in > FramingConstraints. > > The log file can be downloaded here (~2.9k) > http://www.mitchellscientific.com/smalltalk/temp/FramingComboProblem.txt > > I wonder how the fraction is becoming zero, only on this one machine. I > wonder if something odd is happening in STB or if something about this > machine is causing it to not handle fractions well. I don't think it > have to do any parsing of them to load from STB. I suspect it is something far more simple (and less dark) than that. The bottomOffset of a #relativeParentHeight framing constraint is scaled to the screen resolution when the window is loaded. You can see this calc. in FramingConstraints>>resolutionScaledBy:. Now since the bottomOffset: is truncated, if the screen resolution of source and target are the same (and hence the scale is 1), then the result will always be zero if the bottomOffset is any value less than 1, right? Of course the code won't get run if the resolutions of source and target are the same (which is why it works on your system), but it will get run if the resolutions differ at all. I believe the scale is the target resolution divided by the source, so I think you will be able to see pretty quickly how this would go wrong. Ironically then, this does seem to come back to Andy's original suggestion of investigating the use of Large Fonts (which does change the screen resolution). It looks like a bug in the resolution scaling code to me, which is apparently assuming an integral value (as described in the method comment for #bottomOffset:, but contrary to the class comment's description of the offset settings for the parent relative constraints). Hope this helps Blair |
Chris,
> Ironically then, this does seem to come back to Andy's original suggestion > of investigating the use of Large Fonts (which does change the screen > resolution). Just to clarify this point, we are talking here about the Windows System Font size as set in the Appearence tab of the Display Properties dialog (nothing to do with the font size chosen in the Dolphin view composer). Does the errant system have anything other than a Font Size of "Normal". Or rather, does it have a different font size from the machine on which the Dolphin was running when the combo box was designed? Best Regards, Andy Bower Dolphin Support http://www.object-arts.com --- Are you trying too hard? http://www.object-arts.com/Relax.htm --- |
In reply to this post by Blair McGlashan-2
"Blair McGlashan" <blair@no spam object-arts.com> wrote in message
news:3f392074$[hidden email]... > "Christopher J. Demers" <[hidden email]> wrote in > message news:bh942b$v55kh$[hidden email]... > > I previously posted about a ComboBox not displaying on one client's > > computer, but displaying on all other computers. I wrote some code to log > > all message sends to the FramingConstraints object. I am posting a text > > file that contains the results of the program running on my machine where > it > > displays properly, and the client's machine where the ComboBox does not > > display. The obvious issue seems to be where a fractional value becomes a > > zero. ... > I suspect it is something far more simple (and less dark) than that. The > bottomOffset of a #relativeParentHeight framing constraint is scaled to the > screen resolution when the window is loaded. You can see this calc. in > FramingConstraints>>resolutionScaledBy:. Now since the bottomOffset: is > truncated, if the screen resolution of source and target are the same (and > hence the scale is 1), then the result will always be zero if the > bottomOffset is any value less than 1, right? That is the problem. Apparently that message send was happening before I actuated my message logging. I changed the DPI of my system and was able to reproduce the problem. When I removed the truncation I was able to see the combo box, however it overlapped some other text a little. > Of course the code won't get run if the resolutions of source and target are > the same (which is why it works on your system), but it will get run if the > resolutions differ at all. I believe the scale is the target resolution > divided by the source, so I think you will be able to see pretty quickly how > this would go wrong. > > Ironically then, this does seem to come back to Andy's original suggestion > of investigating the use of Large Fonts (which does change the screen > resolution). Interestingly when I set my computer to use Large Fonts, and it did not cause the problem. However when I went into the advanced properties of the display and changed the resolution from 96 dpi to 120 dpi that caused the problem. That setting implies that the fonts will be larger as well. I guess there are two ways to enlarge the fonts. This is all on Windows XP. > It looks like a bug in the resolution scaling code to me, which is > apparently assuming an integral value (as described in the method comment > for #bottomOffset:, but contrary to the class comment's description of the > offset settings for the parent relative constraints). > > Hope this helps Yes, thanks for the pointers. Removing the truncation seems to be a fix. I now just have to look into the overlapping. I guess I am going to have to test my GUI at different dpi resolutions (oh joy!). My end user did not seem to know anything about having turned on large fonts, so I assumed she hadn't. Perhaps her system came configured that way. As always thanks for the great help. Something should probably be done in the base image. Removing the truncation seems to be one possible fix. Chris |
In reply to this post by Andy Bower-2
"Andy Bower" <[hidden email]> wrote in message
news:3f39455e$[hidden email]... > Chris, > > > Ironically then, this does seem to come back to Andy's original suggestion > > of investigating the use of Large Fonts (which does change the screen > > resolution). > > Just to clarify this point, we are talking here about the Windows System > Font size as set in the Appearence tab of the Display Properties dialog > (nothing to do with the font size chosen in the Dolphin view composer). Does > the errant system have anything other than a Font Size of "Normal". Or > rather, does it have a different font size from the machine on which the > Dolphin was running when the combo box was designed? Actually the use Large Font size does not seem to change the resolution as reported by DesktopView current resolution for me on Windows XP. There is however an advanced display option that allows me to change the resolution from 96 dpi to 120 dpi, and that demonstrates the problem. Possibly this varies by the version of Windows. The 120 dpi setting will also cause the fonts to appear larger. Thanks for the assistance, as always it is much appreciated, Chris |
In reply to this post by Christopher J. Demers
"Christopher J. Demers" <[hidden email]> wrote in
message news:bhbl8f$10e5kd$[hidden email]... > .... > Interestingly when I set my computer to use Large Fonts, and it did not > cause the problem. However when I went into the advanced properties of the > display and changed the resolution from 96 dpi to 120 dpi that caused the > problem. That setting implies that the fonts will be larger as well. I > guess there are two ways to enlarge the fonts. This is all on Windows XP. Sorry for the confusion. It used to be the case that Microsoft "simplified" the concept of changing the display DPI with the Small/Large Fonts setting. Its not something we ever change, so we hadn't really noticed it was different in XP. > > It looks like a bug in the resolution scaling code to me, which is > > apparently assuming an integral value (as described in the method comment > > for #bottomOffset:, but contrary to the class comment's description of the > > offset settings for the parent relative constraints). > >... >...Removing the truncation seems to be a fix. I > now just have to look into the overlapping. I guess I am going to have to > test my GUI at different dpi resolutions (oh joy!). My end user did not > seem to know anything about having turned on large fonts, so I assumed she > hadn't. Perhaps her system came configured that way. > > As always thanks for the great help. Something should probably be done in > the base image. Removing the truncation seems to be one possible fix. Closer examination of the FramingConstraints>>resolutionScaledBy: method reveals the problem, and it is a simple typo (or more probably a "cut & paste coding" error). The offsets are only supposed to be scaled when the constraint for that edge is NOT parent relative. The guard for the bottomOffset erroneously tests the topFraming constraint, and so goes ahead and "scales" the fractional value. The fix is simple (see below). Regards Blair -------------------- !FramingConstraints methodsFor! resolutionScaledBy: aPoint leftFraming == #relativeParentWidth ifFalse: [leftOffset := (leftOffset * aPoint x) truncated]. rightFraming == #relativeParentWidth ifFalse: [rightOffset := (rightOffset * aPoint x) truncated]. topFraming == #relativeParentHeight ifFalse: [topOffset := (topOffset * aPoint y) truncated]. bottomFraming == #relativeParentHeight ifFalse: [bottomOffset := (bottomOffset * aPoint y) truncated]! ! !FramingConstraints categoriesFor: #resolutionScaledBy:!geometry!private! ! |
Blair,
In addition to illustrating your excellent support, this also reminds me that since you changed servers, I'm having trouble getting to patches. LiveUpdate appears to be able to see them, but the bug tracking reports are either gone or the server is unwilling to allow access to them. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
In reply to this post by Blair McGlashan
"Blair McGlashan" <[hidden email]> wrote in message
news:bhdbnt$11dq6t$[hidden email]... ... > > As always thanks for the great help. Something should probably be done in > > the base image. Removing the truncation seems to be one possible fix. > > Closer examination of the FramingConstraints>>resolutionScaledBy: method > reveals the problem, and it is a simple typo (or more probably a "cut & > paste coding" error). The offsets are only supposed to be scaled when the > constraint for that edge is NOT parent relative. The guard for the > bottomOffset erroneously tests the topFraming constraint, and so goes ahead > and "scales" the fractional value. The fix is simple (see below). Your fix works perfectly. I should have noticed that. I guess I was too busy looking at the trees to see the forest. ;) Chris |
In reply to this post by Bill Schwab-2
"Bill Schwab" <[hidden email]> wrote in message
news:bhdeaf$11682n$[hidden email]... > > In addition to illustrating your excellent support, this also reminds me > that since you changed servers, I'm having trouble getting to patches. > LiveUpdate appears to be able to see them, but the bug tracking reports are > either gone or the server is unwilling to allow access to them. The individual 5.1 PL1 patches have been pulled since the full 5.1 PL1 has been made available. Likewise the release notes, etc. These can be downloaded in full from: http://www.object-arts.com/lib/update/dolphin/5.1/<version>/PL1.st http://www.object-arts.com/lib/update/dolphin/5.1/<version>/PL1.htm (or via Live Update). Substitute one of the following product names for <version>: Value Edition Standard Edition Professional The higher edition patches include those from lower editions, so the Professional patches have everything: http://www.object-arts.com/lib/update/dolphin/5.1/Professional/PL1.st http://www.object-arts.com/lib/update/dolphin/5.1/Professional/PL1.htm If you want to apply only individual patches (obviously we don't recommend this as there may be dependencies between patches), then you'll have to extract them from the full patch file. The individual patches can be located by searching for the defect number comment that precedes each in the .st file. The list of patches that are available for the incomplete PL2 is available from: http://www.object-arts.com/lib/update/dolphin/5.1/51PL2List.htm Applying the individual PL2 patches can be done on a hotfix basis, but caution should be exercised as they may be of an experimental nature. To download a particular patch, form up the URL as follows: http://www.object-arts.com/lib/update/dolphin/5.1/NNNN.st where NNNN is the defect number from the above list. A list of outstanding bugs/enhancements that will _probably_ be in PL2 is also available: http://www.object-arts.com/lib/update/dolphin/5.1/51PL2ToDo.htm With regard to defect 1258, the fix for this requires downloading a new In-proc Dll stub: http://www.object-arts.com/lib/update/dolphin/5.1/IPDolphinToGo.zip #1259 requires a new compiler DLL, and this is not currently available for separate download since this is a cosmetic issue. Regards Blair |
Free forum by Nabble | Edit this page |