[ANN] Dolphin Smalltalk 5.1 Patch Level 4

Folks,

A new Live Update is available for Dolphin Smalltalk XP 5.1 to bring it up
to Patch Level 4 (5.1.4). This patch level contains 53 bug fixes and
enhancements for the Value Edition, 57 for Standard Edition and 59 for
Professional. These are listed here in the release notes:

http://www.object-arts.com/Lib/Update/Dolphin/5.1/Value%20Edition/PL4.htm
http://www.object-arts.com/Lib/Update/Dolphin/5.1/Standard%20Edition/PL4.htm
http://www.object-arts.com/Lib/Update/Dolphin/5.1/Professional/PL4.htm

The patches are free updates that can be applied to any Dolphin 5.1 image by
double-clicking the Dolphin Live Update icon in the System Folder.  You'll
need to be connected to the Internet at the time and Dolphin will then
access our web site to download the available patches. If you have not
previously downloaded patch level 1, 2, or 3, then those will be downloaded
at the same time. You can then select and apply the patches. Any lower level
patches than the one you select will be automatically installed first.

The patches for issues #1461 and #1509 install new versions of the Dolphin
compiler and VM dlls, respectively. In order to complete the installation
process on 2k, XP and 2k3 systems you will have to reboot in order to copy
over files that are in use during the live update. Remember to save the
image before rebooting. It is not necessary to reboot immediately, however,
as you can continue using the system with the original DLLs. On Win98 and Me
it is necessary to perform some manual copying to move the DLLs to their
eventual destination. Messages are written to the Transcript explaining what
needs to be done. Note that if you run the installation's repair function,
then it may replace these DLLs, in which case you will need to reapply that
patch.

The patch files are protected by a DolphinSure signature so you need to
acknowledge the Object Art certificate when it is presented (please note
that it may take a few seconds for this to appear while the patches are
downloaded and assembled).

Although you can apply the patch to your current working image we do not
recommend this since you may already have made incompatible changes to it.
If you do choose to patch your working image *please* make sure you have a
backup of it first.

Ideally, we would advise you start from a fresh image (you can get one using
the Fresh Install icon on the Dolphin start menu) and apply the patches to
that. Obviously, if you do this you should first save your current work in
package files so that they can later be reinstalled into the patched image.
Once you have patched an image, you should save it to disk as this is not
done automatically.

Note that there is no point in downloading a complete new installer from the
website since the installers have not been changed.

Lastly if you want to download the patches manually for off-line
installation then they can be found at these URLs:

http://www.object-arts.com/Lib/Update/Dolphin/5.1/Value%20Edition/PL3.st
http://www.object-arts.com/Lib/Update/Dolphin/5.1/Standard%20Edition/PL3.st
http://www.object-arts.com/Lib/Update/Dolphin/5.1/Professional/PL3.st

If you attempt to file-in these patches without first installing PL1, PL2
and PL3 then you will get an error. The patches must be installed in order.

Regards,

Blair McGlashan
http://www.object-arts.com

"Blair McGlashan" <[hidden email]> wrote in message
news:c3a54c$230kit$[hidden email]...
> A new Live Update is available for Dolphin Smalltalk XP 5.1 to bring it up
> to Patch Level 4 (5.1.4). This patch level contains 53 bug fixes and
> enhancements for the Value Edition, 57 for Standard Edition and 59 for
> Professional. These are listed here in the release notes:
...

This is not a big deal, but I thought I should mention it.  The
layoutManager aspect of ScrollingDecorator was not exposed, so
shouldStretchToFit aspect of ScrollingDecoratorLayout is still not available
from the view composer.  Additionally the release notes use the original
aspect name, not the should* version.

...
> Note that there is no point in downloading a complete new installer from
the
> website since the installers have not been changed.
...

Why is that?  I don't plan to reinstall Dolphin, but I would think that you
would want to provide the most current version to new users right off the
bat.  If MSI makes this unnecessarily difficult to do you might have a look
at InnoSetup ( http://www.innosetup.com ).  Additionally if you update the
setup program you may want it to point to the Dolphin 4 documentation by
default.

Chris

"Blair McGlashan" <[hidden email]> wrote in message
news:c3a54c$230kit$[hidden email]...
> A new Live Update is available for Dolphin Smalltalk XP 5.1 to bring it up
> to Patch Level 4 (5.1.4). This patch level contains 53 bug fixes and
> enhancements for the Value Edition, 57 for Standard Edition and 59 for
> Professional. These are listed here in the release notes:

I was just working on a tool (will be a forth coming goody) to migrate
existing views to use the new smaller text control sizes.  While doing this
I realized that ComboBoxes should also be reduced in size (that was not part
of the pl4).  I figured that I could just do it my self.  The problem is
that ComboBox<<extent: only allows the size to be set for simple mode
comboboxes.  I don't think that restriction is necessary.  Since extent
seems to return the extent of the text portion of a dropdown ComboBox I
don't see why it should not be able to set to the same thing.  I have
memories of ComboBox size problems a few years ago, and I think this
limitation might be a leftover from that.  You can find a unit test included
bellow.

I tried the obvious workarounds, and nothing worked.  Then I found
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/comboboxes/comboboxreference/comboboxmessages/cb_setitemheight.asp .

After some fiddling I got it to work!
================
cb sendMessage: (Win32Constants at: 'CB_SETITEMHEIGHT') wParam: -1 lParam:
19 - 6 .
================
But I do not understand why wParam had to be -1.  According to MSDN it
should be 1 to set the height of the selection field.  Either the MSDN is
wrong, or Dolphin is doing more than I am expecting in passing the
arguments.  Then I have to subtract 6 from the actual height I want.  Maybe
some of that has to do with borders or some such thing.

I would propose changing the ComboBox<<extent: method to use
CB_SETITEMHEIGHT to set the height, and super extent: to set the width, for
non #simple controls.  Does this sound reasonable?

I am sorry that I opened up a bit of a can of worms with this default height
stuff.  I hadn't thought about comboboxes.  However I do think the smaller
heights look better.  To make up for that I will release my automatic text
view resizer and alignment goody.  ;)

Here is the unit test.
==================
"Filed out from Dolphin Smalltalk XP"!

TestCase subclass: #ForOAComboBoxTest
 instanceVariableNames: 'cb'
 classVariableNames: ''
 poolDictionaries: ''
 classInstanceVariableNames: ''!
ForOAComboBoxTest guid: (GUID fromString:
'{CC00B3B2-DD83-43A1-B50A-4FB41E5C8D69}')!
ForOAComboBoxTest comment: ''!
!ForOAComboBoxTest categoriesForClass!Unclassified! !
!ForOAComboBoxTest methodsFor!

setUp

 cb := ComboBox show.
!

tearDown

 cb topShell close.!

testResize

 | newExtent |
 cb mode." = #dropDown"
 cb extent. "= 125@21"
 newExtent := 125@19.
 cb extent: newExtent.
 self assert: cb extent = newExtent.
! !
!ForOAComboBoxTest categoriesFor: #setUp!public! !
!ForOAComboBoxTest categoriesFor: #tearDown!public! !
!ForOAComboBoxTest categoriesFor: #testResize!public! !
========================

"Christopher J. Demers" <[hidden email]> wrote in
message news:c3at1j$261tfp$[hidden email]...
>
> I am sorry that I opened up a bit of a can of worms with this default
height
> stuff.

You might want to test when the system is using large fonts.

Hi Blair.

> Lastly if you want to download the patches manually for off-line
> installation then they can be found at these URLs:
>
> http://www.object-arts.com/Lib/Update/Dolphin/5.1/Value%20Edition/PL3.st
>
http://www.object-arts.com/Lib/Update/Dolphin/5.1/Standard%20Edition/PL3.st
> http://www.object-arts.com/Lib/Update/Dolphin/5.1/Professional/PL3.st
>
> If you attempt to file-in these patches without first installing PL1, PL2
> and PL3 then you will get an error. The patches must be installed in
order.

  I guess you meant PL4 in these links here... :-)))

  Best regards,
    Jurko

Hi Blair.

"Blair McGlashan" <[hidden email]> wrote in message
news:c3a54c$230kit$[hidden email]...
> A new Live Update is available for Dolphin Smalltalk XP 5.1 to
> bring it up to Patch Level 4 (5.1.4).

  I applied the new patch and found potential new 'Cosmetic' bug :-)

  In patch #1437 you moved the 'MonthView class>>
>>publishedAspectsOfInstances' method into the 'Standard Edition
Tools'  package. However, doing that caused the 'Standard Edition
Tools' package to become dependant on the 'Month View' package
which, on some systems, doesn't work at all as it depends on a .dll
that isn't (and can not be thanks to M$) distributed with Dolphin and
is not distributed directly with any of the M$'s operating systems.

  This causes the 'Resource library mscomct2.ocx could not be
opened ('mscomct2.ocx' (16r2: The system cannot find the file
specified.))' message to be displayed in my Transcript. And I like
having no such 'warning' messages which I have to ignore - makes
it to easy to ignore something important later on. :-)

  I believe the quick-fix of moving the 'MonthView class>>
>>publishedAspectsOfInstances' method into the 'Standard Edition
Tools'  package might have been a wrong move, and should have
instead been moved into a new 'Month View - development'
package or something similar which wouldn't have a problem with
being dependent on the 'Development System' package.

  Before I just removed the 'Month View' package as a part of my
standard Dolphin 5.1. environment setup (as suggested on these
newsgroups) which can now no longer be done. At the moment,
I'll just have to set up my setup script so that it deletes the culprit
method before uninstalling the packages, which will solve the
immediate problem but will hopefully not be neccessary with D6.
:-)))

  Hope this helps,
    Jurko

P.S.
  Btw, any hints on when D6 is coming out? :-)) April? May? :-)
Come on... I'm drooling here.. >:-)))

"Christopher J. Demers" <[hidden email]> wrote in
message news:c3at1j$261tfp$[hidden email]...
> "Blair McGlashan" <[hidden email]> wrote in message
> news:c3a54c$230kit$[hidden email]...
> > A new Live Update is available for Dolphin Smalltalk XP 5.1 to bring it
up
> > to Patch Level 4 (5.1.4). This patch level contains 53 bug fixes and
> > enhancements for the Value Edition, 57 for Standard Edition and 59 for
> > Professional. These are listed here in the release notes:
>
> I was just working on a tool (will be a forth coming goody) to migrate
> existing views to use the new smaller text control sizes.  While doing
this
> I realized that ComboBoxes should also be reduced in size (that was not
part
> of the pl4).

I did notice that when searching for all the resources that needed to be
changed., but...

>...  The problem is
> that ComboBox<<extent: only allows the size to be set for simple mode
> comboboxes.

Which is why PL4 does not change it. The height patch snook in after the PL4
deadline only because it was not a code change. Allowing the height of a
dropdown mode combobox to be changed does require a code change.

>...I don't think that restriction is necessary.  Since extent
> seems to return the extent of the text portion of a dropdown ComboBox I
> don't see why it should not be able to set to the same thing.  I have
> memories of ComboBox size problems a few years ago, and I think this
> limitation might be a leftover from that. ....

Yes, it was because of a couple of issues (#68, #267 and #1098), all patched
in 5.0 PL2
(http://www.object-arts.com/Lib/Update/Dolphin/5.0/Professional/PL2.htm).

>    .... You can find a unit test included
> bellow.
>
> I tried the obvious workarounds, and nothing worked.  Then I found
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/comboboxes/comboboxreference/comboboxmessages/cb_setitemheight.asp . Maybe
> some of that has to do with borders or some such thing.

Yes. In one of your previous posts you mention that the calculated height
for a static text field is 13 (given the default font), and 19 for a text
edit field, hence +6.

>
> I would propose changing the ComboBox<<extent: method to use
> CB_SETITEMHEIGHT to set the height, and super extent: to set the width,
for
> non #simple controls.  Does this sound reasonable?

Yes, I think its a good idea (#1519). Thanks for the suggestion and the
test.

Regards

Blair

A small bug: Base64Codec class is unpackaged after applying patch.

--
Dmitry Zamotkin

"Dmitry Zamotkin" <[hidden email]> wrote in message
news:c3cfff$1ags$[hidden email]...
> A small bug: Base64Codec class is unpackaged after applying patch.

Curses! No test for unpackaged classes.

Thanks Dmitry, the patch has been updated to correct this. Anyone that has
already applied it can just execute:

    Base64Codec owningPackage: Object owningPackage

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:c3c16n$25p7mr$[hidden email]...
> "Christopher J. Demers" <[hidden email]> wrote in
> message news:c3at1j$261tfp$[hidden email]...
[... snip...]
> > I would propose changing the ComboBox<<extent: method to use
> > CB_SETITEMHEIGHT to set the height, and super extent: to set the width,
> for
> > non #simple controls.  Does this sound reasonable?
>
> Yes, I think its a good idea (#1519). Thanks for the suggestion and the
> test.
>

On further investigation I'm afraid I've changed my mind, and I think I was
probably a bit hasty with resizing all the default text fields. I think they
should indeed be resized down, but 19 is not the right size, it should be 21
pixels for the default font.

The reason I say this is because 21 pixels is the height the Combobox wants
to be for the default font - although it is possible to coerce it into
adopting a different height by using a mechanism which contradicts what the
documentation says should happen, the Combobox really doesn't like it and
immediately snaps back to its preferred size when perturbed by a new
placement request. Although it may be possible to make the size stick by
resetting it at appropriate points, I had only partial success with this by
modifying the obvious places. It really is swimming against the tide to
attempt to subvert the default behaviour of Windows controls when they don't
want to cooperate.

Andy is right (though hopefully I said that quietly enough for him not to
notice :-)). The real problem is that the static text fields one uses for
labelling have different behaviour in respect of margins/borders than other
text controls. This is annoying, but the solution is not really to shrink
the controls below their natural size, but to make the grid alignment more
intelligent. Obviously this is a non-trivial enhancement.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:c3c16n$25p7mr$[hidden email]...
> "Christopher J. Demers" <[hidden email]> wrote in
...
>>  Then I found
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/comboboxes/comboboxreference/comboboxmessages/cb_setitemheight.asp .
> >
> > After some fiddling I got it to work!
> > ================
> > cb sendMessage: (Win32Constants at: 'CB_SETITEMHEIGHT') wParam: -1
lParam:
> > 19 - 6 .
> > ================
> > But I do not understand why wParam had to be -1.  According to MSDN it
> > should be 1 to set the height of the selection field.  Either the MSDN
is
> > wrong, or Dolphin is doing more than I am expecting in passing the
> > arguments.  Then I have to subtract 6 from the actual height I want.
> Maybe
> > some of that has to do with borders or some such thing.
>
> Yes. In one of your previous posts you mention that the calculated height
> for a static text field is 13 (given the default font), and 19 for a text
> edit field, hence +6.

That make sense.  However why did I have to pass a wParam of -1 when the
MSDN said it should be 1?  Should I have manually coerced 1 to some wrapper
for passing?  When I tried that call with 1 nothing happened, but it worked
with -1.  I am just wondering.

Chris

"Blair McGlashan" <[hidden email]> wrote in message
news:c3cvp0$276q22$[hidden email]...
> On further investigation I'm afraid I've changed my mind, and I think I
was
> probably a bit hasty with resizing all the default text fields. I think
they
> should indeed be resized down, but 19 is not the right size, it should be
21
> pixels for the default font.
>
> The reason I say this is because 21 pixels is the height the Combobox
wants
> to be for the default font - although it is possible to coerce it into
> adopting a different height by using a mechanism which contradicts what
the
> documentation says should happen, the Combobox really doesn't like it and
> immediately snaps back to its preferred size when perturbed by a new
> placement request. Although it may be possible to make the size stick by
...

I think you are right.  Trying to resize the ComboBox is a bad idea.  I am
going to use 21 as my default TextEdit (and etc...) height.  I did not
realize that the ComboBoxes resized themselves based on the font.  I had
some in my views that had a font set, it must have been a legacy thing.
Setting the font aspect to nil made it use the default and it then had a
height of 21.

> Andy is right (though hopefully I said that quietly enough for him not to
> notice :-)). The real problem is that the static text fields one uses for
> labelling have different behaviour in respect of margins/borders than
other
> text controls. This is annoying, but the solution is not really to shrink
> the controls below their natural size, but to make the grid alignment more
> intelligent. Obviously this is a non-trivial enhancement.

While what you propose may eventually be the best solution I think I can
take a shortcut for the time being.  If the TextEdits have a height of 21
and the StaticTexts have a height of 14 they can be aligned with the middle
of the TextEdits.  Once that is done the text lines up very well.  My goodie
will do this automatically.  StaticTexts seem to be perfectly happy with a
height of 14, they are much more polite than the grumpy ComboBoxes. ;)  I
have my goodie adding a menu to the ViewComposer so I can use it on a
regular basis.  What I will do is create my edit boxes and labels with a
rough layout, and the run my goodie on the view.  It seems to do a good job
guessing what StaticText goes with what TextEdit, and aligns them quite
well.  I hope to post an announcement about it in a few days.

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:c3dset$24l6lv$[hidden email]...
> >[Blair wrote]
> > Yes. In one of your previous posts you mention that the calculated
height
> > for a static text field is 13 (given the default font), and 19 for a
text
> > edit field, hence +6.
>
> That make sense.  However why did I have to pass a wParam of -1 when the
> MSDN said it should be 1?  Should I have manually coerced 1 to some
wrapper
> for passing?  When I tried that call with 1 nothing happened, but it
worked
> with -1.  I am just wondering.

No, you were right to try 1 based on the documentation, which would seem to
be either wrong or incomplete. Thinking about it, it would make sense that
it be -1, rather than 1, since when the control is in owner draw mode that
argument is used as the index of the item in the list who's height is to be
set. If 1 were also used to set the height of the edit box, then there would
be an overlap.

Regards

Blair