20060711 test build uploaded

Sorry, I forgot to write something about that. I've updated the

> automated build scripts to be able to either build just the Unicode
> version or both ANSI and Unicode. The eventual goal is to just build
> and distribute the Unicode version and I thought that the 2.7 series
> might be a good time to at least make it possible. It also reduces the
> full build time by a few hours, so it is especially nice for the preview
> builds.

I was a little bit jittering when I read this. In the last times I toyed
a lot with with the unicode version. I had no too much problems with the
unicode version if I except the StyledTextCtrl which is, in my mind, really
the bottleneck.
I attempted to write a new class, a derived class of the StyledTextCtrl,
which is agnostic in respect to the unicode/ansi version, and failed.
If it is possible to overwrite some methods, some other methods like
GetCharAt() are impossible to handle. More or less, all the methods
related to the caret position or the char position are difficult to
handle.

I have updated the regulex application, see the screenshot,
Pages Persos Chez.com .
Porting such an application to the unicode version is practically
impossible.

Just out of curiosity, have you any idea about the number of unicode/ansi downloaded versions or users ?

From the changes.html doc, I was very pleased to read this:

wx.DC.BeginDrawing and EndDrawing have been deprecated in the C++ code, so since they never really did anything before they are now just empty stubs in wxPython.

I always dropped these from my code and I never had any problems. :slight_smile:

Regards.
Jean-Michel Fauth, Switzerland.

jmf wrote:

> Sorry, I forgot to write something about that. I've updated the
> automated build scripts to be able to either build just the Unicode
> version or both ANSI and Unicode. The eventual goal is to just build
> and distribute the Unicode version and I thought that the 2.7 series
> might be a good time to at least make it possible. It also reduces the
> full build time by a few hours, so it is especially nice for the preview
> builds.

I was a little bit jittering when I read this. In the last times I toyed
a lot with with the unicode version. I had no too much problems with the
unicode version if I except the StyledTextCtrl which is, in my mind, really
the bottleneck.
I attempted to write a new class, a derived class of the StyledTextCtrl,
which is agnostic in respect to the unicode/ansi version, and failed.
If it is possible to overwrite some methods, some other methods like
GetCharAt() are impossible to handle. More or less, all the methods
related to the caret position or the char position are difficult to
handle.

I have updated the regulex application, see the screenshot,
Pages Persos Chez.com .
Porting such an application to the unicode version is practically
impossible.

What exactly is the problem? Is it that the character positions don't line up with the internal document because of using utf-8 internally? We should be able to come up with a way to either fix that or workaround it.

BTW, a year or so back I added methods to the STC class to get and set text as utf-8? Does that help?

Just out of curiosity, have you any idea about the number of unicode/ansi downloaded versions or users ?

It depends on the platform. Some are about 50/50, and are close enough that it leads me to believe that it is due to most people downloading both versions so they would probably be okay having just one as long as the apps they are using would work. For other platforms it is about a 3-1 unicode-ansi ratio. Also, nearly all of the linux distros that I know of that provide wxPython packages already are only offering the unicode build.

From the changes.html doc, I was very pleased to read this:

wx.DC.BeginDrawing and EndDrawing have been deprecated in the C++ code, so since they never really did anything before they are now just empty stubs in wxPython.

I always dropped these from my code and I never had any problems. :slight_smile:

Personally I think it is unfortunate they were dropped. It would have been a great way to implement double buffering for only those platforms and DC types where it makes sense and let the drawing go strait through in other situations (like on OSX or in wx.PrinterDC for example.)

ยทยทยท

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!