ComboBox non-display followup (with message log)...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

ComboBox non-display followup (with message log)...

Christopher J. Demers
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


Reply | Threaded
Open this post in threaded view
|

Re: ComboBox non-display followup (with message log)...

Blair McGlashan-2
"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
should
> 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


Reply | Threaded
Open this post in threaded view
|

Re: ComboBox non-display followup (with message log)...

Andy Bower-2
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
---


Reply | Threaded
Open this post in threaded view
|

Re: ComboBox non-display followup (with message log)...

Christopher J. Demers
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


Reply | Threaded
Open this post in threaded view
|

Re: ComboBox non-display followup (with message log)...

Christopher J. Demers
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


Reply | Threaded
Open this post in threaded view
|

Re: ComboBox non-display followup (with message log)...

Blair McGlashan
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! !


Reply | Threaded
Open this post in threaded view
|

Re: ComboBox non-display followup (with message log)...

Bill Schwab-2
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]


Reply | Threaded
Open this post in threaded view
|

Re: ComboBox non-display followup (with message log)...

Christopher J. Demers
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


Reply | Threaded
Open this post in threaded view
|

5.1 Patch availability

Blair McGlashan
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