"toggleLocalHierarchy" button?

Hi,


I know it's a silly question. I didn't know I would have to write this
one here.  Also very ashamed of.  :-(

CHB of DX6 doesn't seem to have a "menu command or button" for
ClassBrowserShell>>toggleLocalHierarchy , which is presented a icon
button of white circle with horizontal strike in CHB of D4.01.


Actually I was expecting reference search "toggleLocalHierarchy" would
lead me to a View Resource Method, but it didn't. Maybe they don't
store symbols in those methods.   :-(


Best Regards
Howard Oh

Howard Oh wrote:

> CHB of DX6 doesn't seem to have a "menu command or button" for
> ClassBrowserShell>>toggleLocalHierarchy , which is presented a icon
> button of white circle with horizontal strike in CHB of D4.01.

For some reason OA have decided to ignore requests from their customers and
remove that functionality completely from the GUI.  Fortunately, and very
sensibly, they haven't removed the implementation, so it's not too difficult to
re-add it as a menu item or as a toolbar command.

Still a pain to have to do, though, and one of the several reasons I haven't
made the switch to D6 yet.

    -- chris

>For some reason OA have decided to ignore requests from their customers and
remove that functionality completely from the GUI.

Oh!! Really?  I thought I was very stupid not to find a button that
couldn't be missing.  Thanks.


>Still a pain to have to do, though, and one of the several reasons I haven't
made the switch to D6 yet.


You too?

I nice to know someone like me. :-)

I'm staying at D4. Although D5 attracts me a lot these days.  Sadly OA
doesn't seem to sell them any more.



Best Regards

Howard,

> I'm staying at D4. Although D5 attracts me a lot these days.  Sadly OA
> doesn't seem to sell them any more.

Hmm.. I can see why you might want to stay with a current version but
why would you want to move to D5 rather than go to D6? Apart from the
"toggle Local Hierarchy" button, what does D5 have that D6 does not?


Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,


My local friend ChanHongKim bought D6 and uses it.
Though I use D4 since 1999, I taste D6 by using D6CE from time to time.
ChanHongKim and I are Koreans.

ChanHongKim has reported a serious problem of D6 workspace in this
newsgroup. ; "Multibyte character."
http://groups.google.co.kr/group/comp.lang.smalltalk.dolphin/browse_thread/thread/74c4b01e5536026b/b94668788e2ce900?q=ChanHong+Kim&rnum=9#b94668788e2ce900

That the reason I dislike D6.  Sum of all the conveniences of D6
features can match with inconveniences single bug is making.


Below is an example what happens.(I wander if it shows correctly
through nonkorean web browser)

If I type a korean text in a D6 workspace

한글입니다.

which means, "This is korean text."
D6 workspace will produce a broken text as below.

한±UAO´I´U ¿O±uAu±i¿a?

This is just one example.  You may as well think every korean text goes
like this.


ChanHong and I run a SUG community site
(http://cafe.naver.com/smalltalk.cafe), to communitcate thoughts, there
is always a need to post source code segments pretty often.  Many
educational users(potential customers) of D6CE here are experiencing
this inconveniences everytime they try to run example codes having
korean strings.  These educational users are not students.  They are
professional C++ and Java based developers(and a few of Ruby , Python)
who is interested in Smalltalk for a hoby.


I decided to not to move up to D6 for a while.  ChanHong figured out a
bypass method.
He file out codes and load it on D5(a real fan of OA he is to have
purchased all the versions!!) and they copy paste to Web.

The reason I'm attracted to D5 is that it has many features without
above problem.

The time when D5 was firstly announced, I wasn't very aware of what XP
is and how important refactoring was.  So I looked it as a fancier
version has no big difference than D4.

Now I am a heavy refactoror and tester.
But, all I have is old D4 and unusable D6.


Best Regards
Howard

Howard, Andy,

This problem /ought/ to be curable -- at least to the extent that D6 will work
as well as or better than D5 when used for multi-byte-character-sets (mbcs).  I
don't have a complete solution, but we should be able to get closer...

The main difficulty is that there are two possible problems, and (from here)
it's hard to see which is causing this.

Howard, can you try adding the following to your Dolphin (D5 or D6, or even --
I suppose -- D4) as an instance-side method of KernelLibrary:

====================
getACP
    "Retrieves the current ANSI code-page identifier for the system."
    <stdcall: dword GetACP>
    ^self invalidCall
====================

and then try evaluating:

    KernelLibrary default getACP.

I suspect it will answer 949, if not (and it doesn't answer one of the
variant's of code-page 949) then that might the source of your problem.

If it does, then I suspect the problem may lie in Scintilla.  Scintilla has the
ability to handle full Unicode, and also mbcs such as cp-949.  To see it
handling Unicode correctly, try this (in D6):

    bytes := #[
                        16rED 16r95 16r9C
                        16rEA 16rB8 16r80
                        16rEC 16r9E 16r85
                        16rEB 16r8B 16r88
                        16rEB 16r8B 16rA4
                ].
    tm := bytes asString asValue.
    tp := TextPresenter show: 'Scintilla view' on: tm.
    sci := tp view.
    sci codePage: #utf8.

That sets 'bytes' to the UTF-8 representation of the Korean text you posted,
starts an instance of Scintilla, and then tells it that the binary data it has
been given should be interpreted as UTF-8.  On my machine that (seems to) work
correctly.  If it also works for you then that's a good start.

Unfortunately (and I don't know why this is) there doesn't seem to be a way to
tell Windows to use UTF-8 as the "local" mbcs (for apps which are not Unicode
aware -- like Dolphin).  So the next step is to try to persuade Scintilla to
work properly with your machine's mbcs code page.

Now let's try displaying text which is encoded using code page 949, which is
similar to the above test, but with different byes.  If I evaluate this:

    bytes :=  #[16rC7 16rD1 16rB1 16rDB 16rC0 16rD4 16rB4 16rCF 16rB4 16rD9].
    tm := bytes asString asValue.
    tp := TextPresenter show: 'Scintilla view' on: tm.
    sci := tp view.

then Scintilla doesn't display the text properly.  But that's because
Scintilla and/or the Dolphin wrapper set up the Scintilla control with a "code
page" of 0 -- which means just "leave it to Windows", and my own machine isn't
set up to display Korean.  That ought to work properly on /your/ machine, but
if it hasn't displayed properly (and I expect that it won't or you wouldn't
have had problems in the first place) then can you check what the answer to:

    sci sciGetCodePage.

is.  If it answers 0, then Scintilla is just leaving the formatting to Windows,
which /should/ get it right -- if that's the case then I have no idea what's
going wrong because from the look of the Scintilla code, it should work
properly.

Whatever it answers, try evaluating:

    sci sciSetCodePage: 949.

My guess is that that will have no effect at all -- even though it /should/
make the display correct.  That's because of a simple bug in Scintilla (which I
plan to send back to the Scintilla people if I ever work out how to submit
fixes)
which ignores the requested code page entirely on NT/W2K/XP systems.

In case you fancy trying it (and I wouldn't blame you a bit if you /didn't/
want to try it), I've put a temporary link to a "fixed" version of SciLexer.dll
at:
    http://ephemera.metagnostic.org/code/SciLexer.zip
With that installed as a /temporary/ replacement for the SciLexer.dll in the
Dolphin folder, the above example works correctly.

Blair, if you are reading, I'll send you the patched source if you'd like.

    -- chris

Chris,

Thanks for the effort you've put into this. If Howard can answer those
questions maybe we will get closer to solving the problem. I must admit
that I was assuming that this issue was simply caused by Scintilla
simply not being able to handle the multibyte code pages but, from what
you say, it seems likely that this is not the case.

> Blair, if you are reading, I'll send you the patched source if you'd
> like.

I'm sure Blair would like to see the changes that you made. Out of
interest, what did you do?

Best Regards

--
Andy Bower
Dolphin Support
www.object-arts.com

Howard,

> ChanHongKim has reported a serious problem of D6 workspace in this
> newsgroup. ; "Multibyte character."
> http://groups.google.co.kr/group/comp.lang.smalltalk.dolphin/browse_th
> read/thread/74c4b01e5536026b/b94668788e2ce900?q=ChanHong+Kim&rnum=9#b9
> 4668788e2ce900
>
> That the reason I dislike D6.  Sum of all the conveniences of D6
> features can match with inconveniences single bug is making.

Ok fair enough, that is a good reason from your perspective.

We are intending to do a "special" shortly which will allow Dolphin 4
users to upgrade to Dolphin 6 at a reduced price. If you take advantage
of this upgrade offer then I'd be happy to send you the appropriate
serial numbers for Dolphin 5 as well.

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> I'm sure Blair would like to see the changes that you made. Out of
> interest, what did you do?

I've sent the changed file to Blair (blaming you -- of course ;-)

The change is simple: the existing Scintilla logic (in several places) was:

==================
If we in are UTF-8 mode:
    Then handle that by converting to UTF16 and using the Windows
    "wide" APIs.

Else if    we are running on NT (or better)
or           we are using code-page 0
or           the system code page is the same as the set code page:
    Then let Windows interpret the bytes of text how it likes.

Otherwise
    Explicitly handle the code page by converting to UTF16 and
    using the Windows "wide" APIs.
==================

Which doesn't do what it's obviously intended to do -- the author seems to have
forgotten that just because you are on WinNT doesn't mean that you don't want
to interpret data according to some code page other than the system one (e.g.
me displaying Korean text expressed in code-page 949).

So I made a small change to remove the is-NT test.  I haven't tested it much,
and not at all on W9x systems -- I haven't got any anymore (hurrah!) -- but it
/seems/ to work.

    -- chris

Chris,

Sorry to have you wait so long.
I followed your systematic test cases.

Here goes the report.

- All tests here is run on D6.
- Order of the results is same as Chris's test codes.

TEST ONE:  getACP

It answers 949.


TEST TWO:  Scintilla  TextPresenter & codePage: #utf8

1. Copy & Paste from it or to it is working correctly.
2. Deleting korean letters by hitting backspace key works correctly.
3. Typing keyboards to write korean string causes this walkback.

오전 2:21:08, 2006년 5월 2일 화요일: 'Index 54621 is out of
bounds'
String(Object)>>errorSubscriptBounds:
String(Object)>>errorAt:
String>>at:
Character class>>value:
Character class>>codePoint:
SCNotification>>character
ScintillaView>>scnCharAdded:
ScintillaView>>nmNotify:
ShellView(View)>>wmNotify:wParam:lParam:
ShellView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
ScintillaView(ControlView)>>defaultWindowProcessing:wParam:lParam:
ScintillaView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
InputState>>pumpMessage:
InputState>>loopWhile:
InputState>>mainLoop
[] in InputState>>forkMain
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in BlockClosure>>newProcess

I think scintilla view is tring to access characters in the string by
counting keyboard hits.  But each korean letter is composed by 2~5
keyboard hits, so the view will access out side of the string.






TEST THREE:  Scintilla  TextPresenter

1. Copy & Paste from it or to it is working correctly.
2. Deleting korean letters by hitting backspace key breaks korean
letters to half.
3. Typing keyboards to write korean string works correctly.




TEST FOUR:  Scintilla  TextPresenter  &  sciSetCodePage: 949

1. Copy & Paste from it or to it is working correctly.
2. Deleting korean letters by hitting backspace key works correctly.
3. Typing keyboards to write korean string works correctly.




Result of test four looks quite usable to me.  But, it still D4 is a
little better in  korean typing.  We can discuss on this later to keep
the good mood. :-)


What do we do now?  :-)

Best Regards
Howard

Howard Oh wrote:

I think this is a general problem in Dolphin because double byte
characters are not supported. So if you have a Unicode string and want
to get a character at a certain index you will get an error for every
character with unicode value greater than 255.

The problem could be solved by either changing the implementation of the
method Character>>#value: or changing initialization of the CharacterSet
  class variable to support double byte characters.

---
value: anInteger
        "Answer the character with ascii value, anInteger. If anInteger is not
in the range 0..255,
        then #at: primitive will fail"

        ^CharacterSet at: anInteger + 1

---

As it is now it is impossible to represent double byte characters as
instances of class Character in Dolphin so Unicode strings are not
really supported. I have the same problem in WikiDoc where asian
characters can not be used simply because I can not create and store an
instance of UnicodeString from HTTP request because after parsing HTTP
request with Unicode character values I can not create an instance of a
double byte character which would be used to construct a Unicode string.

Best regards,

David Gorisek

I'm very interested in that offer.

Best Regards

"Chris Uppal" <[hidden email]> wrote in message
news:4451e474$3$651$[hidden email]...
It's really not fair to say that we ignored requests from our customers, in
this regard anyway. The balance of feedback on this issue was that the
majority did not find the local hierarchy functionality that useful (if
indeed they used it at all), and that customers preferred that the toolbar
button to hide/show inherited methods. Obviously you don't agree with this,
but you are not our only customer Chris.

I think it is unfortunate that we didn't notice that removing the toolbar
button removed the only appearance of that command in the UI, but I don't
recall that being pointed that out at the time and certainly we hadn't
noticed. In fact I didn't know this until Howard pointed it out. It
certainly was not intentional that the command be removed in some kind of
deliberate action to ignore certain customers - if that had been the case
we'd have removed the implementation :-).

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:4455fbdf$0$658$[hidden email]...
The way to submit a bug report and fix is via the sourceforge bugtracker for
Scintilla (follow the link on
http://scintilla.sourceforge.net/ScintillaToDo.html). If you submit a
reasonable bug report, and especially if you include a fix, you'll probably
find Neil quite receptive. Bear in mind, though, that there is a fairly high
volume of, ahem, poor quality bug reports going through on Scintilla, so one
faces the usual problem of standing out from the crap. Expect to have to
defend your suggestion.

Regards

Blair

Blair,

> It's really not fair to say that we ignored requests from our customers,
> in this regard anyway. The balance of feedback on this issue was that the
> majority did not find the local hierarchy functionality that useful (if
> indeed they used it at all), and that customers preferred that the toolbar
> button to hide/show inherited methods.

I hope I don't seem too petty, but this is an issue I care about.  (Not only
the function itself, but how and whether you do listen to your customers.)

To the best of my memory, backed by a quick scan of my archive of the D6 beta
list, /nobody/ supported removing toggle-local-hierarchy.  At least two people
(Louis and myself) asked for it, specifically, back when it (and the other
useful buttons) were missing from the first beta.

It did come back ;-)  But then you removed it again (in the final version, not
in any beta).  Perhaps other people would have objected if you'd ever made it
plain that you intended to do so.

The nearest was Andy's post:

> In this particular case, I think it may be worth changing the meaning
> of the + toolbar icon to actually mean "Show Inherited Methods". I
> think this is probably a more common requirement than the Show Local
> Hierarchy.

Which got just one supporting message, but -- please note -- that was support
for making show-inherited-methods available directly from the toolbar again
(rather than only via a menu), /not/ for removing the toggle-local-hierarchy
button.

Maybe I'm alone (with Howard) in missing it.  Maybe not.  But I don't think
that you've had any feedback from your customers to suggest so.

    -- chris

David,

> The problem could be solved by either changing the implementation of the
> method Character>>#value: or changing initialization of the CharacterSet
>   class variable to support double byte characters.

Remember that Unicode code points are /not/ 16-bit quantities.

It is -- as I've said before -- unfortunate that UnicodeString is so named.  It
does not represent a string of Unicode characters, but the UTF-16 encoding of
Unicode data as a sequence of unsigned 16-bit values.  Really, it shouldn't
"contain" instances of Character at all, but Integers.

Ideally, Character would be able to represent any Unicode character (presumably
using a table of "fixed" instances for the common ones (the first 256, or the
first 65564, or something), and creating others on demand (like the difference
between SmallInteger and LargeInteger).  That would certainly be necessary to
communicate with Scintilla in UTF-8 mode.

BTW, I've been working (on and off) on a Unicode implementation for Dolphin for
some time (it's still incomplete).  I've found it impossible to fit real
Unicode into the existing String framework -- there are just too many
incompatibilities.  For instance Strings, as SequenceableCollections, assume
constant-time access, which is not possible for any representation of Unicode
data except as UTF-32 or simple Arrays of UnicodeCharacters (either of which
takes too much space for most real purposes).  Similar problem occur with
mutable Strings -- changing a character in the middle of a UTF-8 or UTF-16
encoded string is /expensive/ so it's best for Unicode strings to be immutable;
but then that requires a completely different approach to creating them...

    -- chris

Blair,

> The way to submit a bug report and fix is via the sourceforge bugtracker
> for Scintilla (follow the link on
> http://scintilla.sourceforge.net/ScintillaToDo.html). If you submit a
> reasonable bug report, and especially if you include a fix, you'll
> probably find Neil quite receptive.

Thanks.


> Bear in mind, though, that there is a
> fairly high volume of, ahem, poor quality bug reports going through on
> Scintilla, so one faces the usual problem of standing out from the crap.
> Expect to have to defend your suggestion.

And for the warning ;-)

I'll wait a bit and see if this is a change that you want to make to the
Scintilla version shipped with Dolphin -- it is is then that might give me a
little extra clout...

    -- chris

Howard,

That's encouraging ;-)

Can you say whether test four was using the version of SciLexer.dll which comes
with Dolphin, or my modified version, please ?  Or did you try both and they
both behaved the same ?

Also can you confirm that in test three, executing
    sci sciGetCodePage
answers 0.

And one last question: what version of Windows did you try this on ?

    -- chris

Comes with Dolphin 6 that is.  I've not tried your version yet.

sci sciGetCodePage   answers 0.

Microsoft Windows XP
Professional
Version 2002
Service Pack 2

It's like Doctor & Patient conversation.  "Why is he asking that for?"
:-)

Best Regards
Howard

Blair,

In D4, toggleLocalHierachy is very useful, since it does not have a
refactoring browser.
While the refactorings related to hierarchies like: "Move the field
up", "Move the field down", "Move the method up", "Move the method
down"...
It really helps a lot.

And even for non-refactoring cases, snipping sibling classes can help
focusing on the class that I'm working with.

Maybe it's too late say these, but ....

Best Regards,
Howard