Re-2: Win32 VM 3.10.6 problem with special characters

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

Re-2: Win32 VM 3.10.6 problem with special characters

Frank Urbach
Hi Andreas,

For a stock 3.9 image the changeset UTF8Clipboard.cs didn't work in my environment(3.9 image and 3.10.6 vm on Windows XP). I slightly modified this as you can see in the attached file. Because I don't know the right way submit this modified changeset( open a new bugreport or atach the file to the old one??) Could you please review this. With the hint for the right place I will put it there.

Cheers,
  Frank

-------- Original Message --------
Subject: Re: Win32 VM 3.10.6 problem with special characters (11-Okt-2007 18:01)
From:    Andreas Raab <[hidden email]>
To:      [hidden email]

> Hi Jens -
>
> The problem you see comes from the VM now universally taking UTF-8 and
> your (3.9) image being unaware of this situation. You will have to apply
> the changes available here:
>
> http://bugs.squeak.org/view.php?id=6523
> http://bugs.squeak.org/view.php?id=6525
> http://bugs.squeak.org/view.php?id=6526
>
> Cheers,
>   - Andreas
>
> Jens Moenig wrote:
> > dear squeakers,
> >
> > I have run into two problems after switching from a 3.9.2 vm to the current
> > 3.10.6 in a deployed application using the current stable 3.9 image. The
> > main reason for switching was the new splash feature, which does help a lot
> > on slower machines. However there seems to be an issue with special
> > characters (German Umlaute, sharp s's and paragraph characters).
> >
> > The first problem is, files containing such characters (Umlaute) are shown
> > garbled in StandardFileMenu.
> >
> > Interestingly these 'garbled' file(name)s load perfectly ok from
> > StandardFileMenu as well as using Smalltalk getSystemAttribute: 3, or
> > FileStream requestDropStream: n. But it just doesn't look nice in a
> > deployed
> > application, and I don't really want to restrict users' creativity in
> > composing inventive fileNames ;-).
> >
> > The second problem is, these special characters simply get lost in the
> > clipboard.
> >
> > This is somewhat worse, because my application builds on user defined
> > strings as Dictionary keys. Whenever someone  pastes such a string from
> > another place in or outside the image using the clipboard it first has to
> > be
> > manually corrected, otherwise things don't work out.
> >
> > As I'm mostly just 'lurking' in here I'm not sure if this problem has been
> > reported before or - indeed - if it's a problem for others as well or just
> > a
> > side effect of the unicode effort aparently going on. For the moment, I
> > have
> > switched back to the 'vintage' 3.9.2 vm (which works just fine). But I
> > wouldn't want to be 'left bedind', so any help is appreciated.
> >
> > Thanks
> > -Jens
> >
> >
>
>

Edelstahlwerke Schmees GmbH
Geschäftsleitung Clemens Schmees
Sitz D-01796 Pirna
Handelsregister Dresden HRB 54
E-Mail: [hidden email]
WEB:     www.schmees.com

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
 
This e-mail may contain confidental and/or privileged information. If you are not intended recipient or have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is stictly forbidden.



UTF8Clipboard.cs (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re-2: Win32 VM 3.10.6 problem with special characters

Andreas.Raab
To be honest, I'm not sure what the right way to deal with this is
either. I'd suggest you name the change set very explicitly
(UTF8Clipboard-V39ONLY.cs or so) and attach it to the bug report, with a
comment explaining its purpose.

Cheers,
   - Andreas

[hidden email] wrote:

> Hi Andreas,
>
> For a stock 3.9 image the changeset UTF8Clipboard.cs didn't work in my environment(3.9 image and 3.10.6 vm on Windows XP). I slightly modified this as you can see in the attached file. Because I don't know the right way submit this modified changeset( open a new bugreport or atach the file to the old one??) Could you please review this. With the hint for the right place I will put it there.
>
> Cheers,
>   Frank
>
> -------- Original Message --------
> Subject: Re: Win32 VM 3.10.6 problem with special characters (11-Okt-2007 18:01)
> From:    Andreas Raab <[hidden email]>
> To:      [hidden email]
>
>> Hi Jens -
>>
>> The problem you see comes from the VM now universally taking UTF-8 and
>> your (3.9) image being unaware of this situation. You will have to apply
>> the changes available here:
>>
>> http://bugs.squeak.org/view.php?id=6523
>> http://bugs.squeak.org/view.php?id=6525
>> http://bugs.squeak.org/view.php?id=6526
>>
>> Cheers,
>>   - Andreas
>>
>> Jens Moenig wrote:
>>> dear squeakers,
>>>
>>> I have run into two problems after switching from a 3.9.2 vm to the current
>>> 3.10.6 in a deployed application using the current stable 3.9 image. The
>>> main reason for switching was the new splash feature, which does help a lot
>>> on slower machines. However there seems to be an issue with special
>>> characters (German Umlaute, sharp s's and paragraph characters).
>>>
>>> The first problem is, files containing such characters (Umlaute) are shown
>>> garbled in StandardFileMenu.
>>>
>>> Interestingly these 'garbled' file(name)s load perfectly ok from
>>> StandardFileMenu as well as using Smalltalk getSystemAttribute: 3, or
>>> FileStream requestDropStream: n. But it just doesn't look nice in a
>>> deployed
>>> application, and I don't really want to restrict users' creativity in
>>> composing inventive fileNames ;-).
>>>
>>> The second problem is, these special characters simply get lost in the
>>> clipboard.
>>>
>>> This is somewhat worse, because my application builds on user defined
>>> strings as Dictionary keys. Whenever someone  pastes such a string from
>>> another place in or outside the image using the clipboard it first has to
>>> be
>>> manually corrected, otherwise things don't work out.
>>>
>>> As I'm mostly just 'lurking' in here I'm not sure if this problem has been
>>> reported before or - indeed - if it's a problem for others as well or just
>>> a
>>> side effect of the unicode effort aparently going on. For the moment, I
>>> have
>>> switched back to the 'vintage' 3.9.2 vm (which works just fine). But I
>>> wouldn't want to be 'left bedind', so any help is appreciated.
>>>
>>> Thanks
>>> -Jens
>>>
>>>
>>
>
>
> Edelstahlwerke Schmees GmbH
> Geschäftsleitung Clemens Schmees
> Sitz D-01796 Pirna
> Handelsregister Dresden HRB 54
> E-Mail: [hidden email]
> WEB:     www.schmees.com
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
>  
> This e-mail may contain confidental and/or privileged information. If you are not intended recipient or have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is stictly forbidden.
>
>
> ------------------------------------------------------------------------
>
>