Bug list

Andy/Blair,

Is the current unfixed bug list still available online?

I just noticed that the PackageBrowser still has a duplicate key binding
(Ctrl-S) and wondered if the previous reports had been missed (it's not
particularly important after all :-) )

--
Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:EM2rb.5781$[hidden email]...
> Andy/Blair,
>
> Is the current unfixed bug list still available online?
>

I've refreshed it. See:

http://object-arts.com/Lib/Update/Dolphin/5.1/AllOutstanding.htm
http://object-arts.com/Lib/Update/Dolphin/5.1/PL3.htm
http://object-arts.com/Lib/Update/Dolphin/5.1/PL3ToDo.htm

As usual hotfix patches for the issues listed as solved in the PL3 release
notes can be downloaded by forming a URL as follows:

http://www.object-arts.com/Lib/Update/Dolphin/5.1/NNNN.st

Where NNNN is the issue number.

There is also an untested hotfix for #1378, and a partial workaround for the
RichTextEdit bug behind the longstanding Transcript issue, #149. I suspect
the only real solution to this problem may be to stop using the RTE as the
Transcript output window, and we may very well change this in the next
release.

> I just noticed that the PackageBrowser still has a duplicate key binding
> (Ctrl-S) and wondered if the previous reports had been missed (it's not
> particularly important after all :-) )

Sorry Ian, this has been repeatedly overlooked.

Ctrl+S is bound to both 'Save Package Changes', and 'Accept' (for the
package comment pane). For consistency with other browsers I think that the
latter binding should be retained. I'm not sure that the former operation is
appropriate for a accelerator key, it not being something one typically does
quite that often. I suppose that this would depend on one's mode of working
though. So we could just remove the binding for save changes, or add another
such as 'Ctrl+Shift+S'. Any strong feelings one way or another?

Thanks for your persistence,

Blair

Blair,

> I've refreshed it. See:

Thanks.  I've added it to my favourites (?) list so I won't forget it
again.

> There is also an untested hotfix for #1378, and a partial workaround
> for the RichTextEdit bug behind the longstanding Transcript issue,
> #149. I suspect the only real solution to this problem may be to stop
> using the RTE as the Transcript output window, and we may very well
> change this in the next release.

As you now can't actually do any editing in the Transcript it does make
sense to use something other than the RTE if it cures the problem. If
you decide to use a MultilineTextEdit it might be helpful to add a
configurable option to set the Transcripts text limit though - the
default of 30000 is a bit low if you use it as a text dump.

> would depend on one's mode of working though. So we could just remove
> the binding for save changes, or add another such as 'Ctrl+Shift+S'.
> Any strong feelings one way or another?

My vote would be to just remove it altogether.  The equivalent operation
in the SystemBrowser doesn't have a hotkey and it is also an operation
that you probably don't want to perform by accident (big fingers
accidentally hitting shift as well as control in your other suggestion
:-) )

--
Ian

When experimenting with RichTexts recently, I possibly found a solution to
the problem with the Transcript. I used Bob Jarvis'
MultilineTextEditExtensions goodie and simply scrolled the RichTextEdit's
text up once and down twice. Add the code below to
TranscriptShell>>nextPutAll:

self sendMessage: EM_SCROLL wParam: SB_LINEUP lParam: 0;
    sendMessage: EM_SCROLL wParam: SB_LINEDOWN lParam: 0;
    sendMessage: EM_SCROLL wParam: SB_LINEDOWN lParam: 0;


It might not be a very beautiful solution, but it works for the RichTextEdit
in other circumstances, so I suspect that it should work for the Transcript
also.

Best regards,

Mikael Svane

"Mikael Svane" <[hidden email]> wrote in message
news:boofq2$1fltur$[hidden email]...
> When experimenting with RichTexts recently, I possibly found a solution to
> the problem with the Transcript. I used Bob Jarvis'
> MultilineTextEditExtensions goodie and simply scrolled the RichTextEdit's
> text up once and down twice. Add the code below to
> TranscriptShell>>nextPutAll:
>
> self sendMessage: EM_SCROLL wParam: SB_LINEUP lParam: 0;
>     sendMessage: EM_SCROLL wParam: SB_LINEDOWN lParam: 0;
>     sendMessage: EM_SCROLL wParam: SB_LINEDOWN lParam: 0;
...

This looks like a good idea (I have not tried it yet, but it sounds like
what I have to do manually).  However I don't think you need to put it in
the nextPutAll: method.  I _think_ the Transcript refresh problem only
occurs when it is hidden and then made visible, unless I am mistaken.  So
there may be an event one could do this in response to.

Chris

"Ian Bartholomew" <[hidden email]> wrote in message
news:boil07$1emaoq$[hidden email]...

[Re: Transcript refresh bug #149]

>
> As you now can't actually do any editing in the Transcript it does make
> sense to use something other than the RTE if it cures the problem. If
> you decide to use a MultilineTextEdit it might be helpful to add a
> configurable option to set the Transcripts text limit though - the
> default of 30000 is a bit low if you use it as a text dump.

We did try use the MultilineTextEdit and it doesn't exhibit the bug.
Unfortunately though it is not really satisfactory on Win9x because the
maximum text limit one can set is 65535 (i.e. a 16-bit limitation).

It is quite likely that we will replace the use of the RTE in the Transcript
with an instance of the Scintilla control in D6, since the latter is used
for all workspaces in that release.

I'd done the opposite, but on reflection I agree with you. The accelerator
will be dropped altogether. The command can still be actioned from the
keyboard by using menu shortcut keys of course.

Regards

Blair

> It is quite likely that we will replace the use of the RTE in the
Transcript
> with an instance of the Scintilla control in D6, since the latter is used
> for all workspaces in that release.

Cool! So I do not have to do the adaption myself someday ;-)

Ciao

...Jochen

"Mikael Svane" <[hidden email]> wrote in message
news:boofq2$1fltur$[hidden email]...
Well done Mikael. This does seem to do the trick, though it need only be
done when the view is restored from being minimised (see below).

> It might not be a very beautiful solution, but it works for the
RichTextEdit
> in other circumstances, so I suspect that it should work for the
Transcript
> also.

It is certainly a "bodge" fix, but sometimes these are necessary to
workaround bugs in the control. I don't think it any worse than my attempt
at fixing it by resizing the control and then resizing it back again,
especially since that only partially solved the problem.

Regards

Blair

-------------------------------------------------------
Win32Constants at: 'EM_SCROLL' put: 16rB5!

!TranscriptShell methodsFor!

onViewRestored: aSizeEvent
 "#149: In order to workaround the problem of a restored Transcript not
displaying any output
 sent when it was closed, we have to perturb it a bit. This seems to be a
bug in the RichEdit
 control , since this workaround is not necessary when using a multi-line
text edit. Thanks
 to Mikael Svane for this fix."

 outputWindow
  sendMessage: EM_SCROLL wParam: SB_LINEUP;
  sendMessage: EM_SCROLL wParam: SB_LINEDOWN.
 ^super onViewRestored: aSizeEvent! !
!TranscriptShell categoriesFor: #onViewRestored:!event handling!public! !

Blair,

>
> Well done Mikael. This does seem to do the trick, though it need only be
> done when the view is restored from being minimised (see below).
>

Thanks. It is what I have done manually with the Transcript since it started
using the RTE to show the text but only a few weeks ago did I think of
automating the process. A small comment on the code that I wrote: almost
always only one scrolldown is necessary, but in some cases (I was unable to
find any pattern, but it _might_ include showing newlines in the
RichTextEdit and then showing additional text afterwards) the last line of
text will not be shown unless there are two scrolldowns. I haven't seen this
behaviour in the Transcript, only in other RichTextEdits, so it might not be
an issue here.

Best regards,

Mikael Svane