File browser

The Filebrowser (and probably other 3rd party tools) is still using a
RichTextEdit workspace, but when it is opened, the #applyOptions method
is called which is trying to do 'scintilla-things' like applying text
styles.

Ted

Ted wrote:
> The Filebrowser (and probably other 3rd party tools) is still using a
> RichTextEdit workspace, but when it is opened, the #applyOptions method
> is called which is trying to do 'scintilla-things' like applying text
> styles.
>
> Ted

When I try to open the debugger I get the same error; RichTextEdit dnu
#textStyles:. When I try to debug that .... I get - see above :-)

Ignoring all that (resume a couple of times) actually crashes the image!

I tried to trace this problem, but can't find any reference to the
RichTextEdit control from the debugger/workspace presenters. Can it be
that by first opening the file browser a RichTextEdit view is created
for the Workspace presenter class and from there your image is basically
  snookered?

I started a new fresh image and did not try to open the file browser
this time and managed to use the debugger no problem.

Ted

Ted,

> The Filebrowser (and probably other 3rd party tools) is still using a
> RichTextEdit workspace, but when it is opened, the #applyOptions method is
> called which is trying to do 'scintilla-things' like applying text styles.

I've modified the File Browser so that it uses a MultilineTextEdit instead
of a RichTextEdit.  It means that I've had to remove the macro facility that
it had but I notice that Scintilla appears to have some sort of macro
capability so I'll investigate that (later).

I've got initial working versions of most of my goodies now, if anyone wants
one urgently then let me know.  As I mentioned earlier installing any of my
updated goodies will involve uninstalling all of the current ones from the
image so I won't upload the new ones to my web site until they are all
available.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ted, Andy,

>> The Filebrowser (and probably other 3rd party tools) is still using a
>> RichTextEdit workspace, but when it is opened, the #applyOptions
>> method is called which is trying to do 'scintilla-things' like
>> applying text styles.
>
> When I try to open the debugger I get the same error; RichTextEdit dnu
> #textStyles:. When I try to debug that .... I get - see above :-)
>
> Ignoring all that (resume a couple of times) actually crashes the image!

FWIW, I've seen this too with QuickCode.  Do we have a way to fix it?
Is this something that D6 will fix by translating the incoming view
resources, or will packages need to be prepared in D5?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:[hidden email]...
D6 will not be auto-converting view resources that use an RTE that is then
connected up to a SmalltalkWorkspace. The decision was made to abandon
compatibility with RTEs as an acceptable view type for a workspace - only
ScintillaViews are now supported. Auto-conversion would be difficult given
that the incompatibility is between the presenter and the view, a connection
that is not made until run-time. If you've used a reference to one of the
SmalltalkWorkspace resources, then you probably won't need to do anything,
except perhaps address any issues there might be in your tool code due to it
assuming that the view would be an RTE (unlikely, since in that case you'd
probably have used a RichTextPresenter anyway). You can mutate these after
loading the package. There shouldn't be any issues until you actually
attempt to show the offending presenter, i.e. you should be able to edit the
view in D6.

Regards

Blair